一、本质定义
| 维度 | 内容 |
|---|---|
| CI | Continuous Integration（持续集成） |
| CD | Continuous Delivery（持续交付） 或 Continuous Deployment（持续部署） |
| 本质 | 不是工具，是一套自动化流水线 + 质量门禁 + 发布策略 |
| 核心目标 | 每次代码变更都能安全、快速、可重复地走完"构建→测试→发布"全流程 |
| 一句话 | 让"代码提交"到"上线生产"这件事，不再靠人、不再靠运气 |
| 对立面 | 手动打包 → 手动测试 → 手动部署 → 出事甩锅 |
| 概念 | 英文 | 触发时机 | 人工干预 |
|---|---|---|---|
| CI | Continuous Integration | 代码 Push / Merge | ❌ 全自动 |
| 持续交付 | Continuous Delivery | CI 通过后 | ✅ 需人工点"发布" |
| 持续部署 | Continuous Deployment | CI 通过后 | ❌ 全自动上生产 |
关键区分：持续交付 = 自动到预发，人工上生产；持续部署 = 自动到生产，无人工。
二、CI/CD 核心流水线
| 阶段 | 做什么 | 典型耗时 | 核心工具 |
|---|---|---|---|
| Commit | 开发者提交代码到分支 | 秒级 | Git |
| Build | 编译、下载依赖、打包 | 1-5 分钟 | Maven / Gradle / npm / Go |
| Test | 单元测试 → 集成测试 → 安全扫描 | 2-15 分钟 | JUnit / Selenium / SonarQube / Trivy |
| Package | 打包成 Docker 镜像 / JAR / Helm Chart | 1-3 分钟 | Docker / Jib / Helm |
| Push | 推送镜像到仓库 | 1-2 分钟 | Harbor / ECR / ACR / Docker Hub |
| Deploy | 部署到 Dev → Staging → Prod | 1-10 分钟 | K8s / ArgoCD / Terraform |
| Verify | 冒烟测试、健康检查 | 1-3 分钟 | Smoke Test / Health Check |
| Monitor | 监控指标、告警 | 持续 | Prometheus / Grafana |
| 流水线总耗时 | 级别 | 说明 |
|---|---|---|
| < 10 分钟 | 🟢 优秀 | 精英团队标准 |
| 10-30 分钟 | 🟡 良好 | 大部分团队可达 |
| 30-60 分钟 | 🟠 一般 | 有优化空间 |
| > 60 分钟 | 🔴 差 | 严重影响开发效率 |
三、三种触发方式对比
| 触发方式 | 触发条件 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| Push 触发 | 代码 Push 到分支 | 日常开发 | 即时反馈、最常用 | 每次 Push 都跑，资源消耗大 |
| PR/MR 触发 | 发起合并请求时 | 代码评审流程 | 只跑变更部分、省资源 | 反馈有延迟 |
| 定时触发 | Cron 定时（如每天凌晨） | 全量回归测试 | 覆盖全量、发现隐性问题 | 反馈慢、问题定位难 |
| 手动触发 | 人点击按钮 | 发布到生产 | 可控、有人把关 | 慢、依赖人 |
| 触发方式 | 推荐场景 | 频率 |
|---|---|---|
| Push | 功能开发、Bug 修复 | 每次提交 |
| PR/MR | 代码合并前 | 每次 MR |
| 定时 | 夜间全量测试 | 每天/每周 |
| 手动 | 生产发布 | 每次发布 |
四、质量门禁（Quality Gate）
| 门禁 | 检查内容 | 不通过会怎样 | 工具示例 |
|---|---|---|---|
| 代码质量 | 代码规范、重复率、复杂度 | ❌ 流水线阻断 | SonarQube / ESLint |
| 单元测试 | 覆盖率 ≥ 80% | ❌ 流水线阻断 | JaCoCo / Istanbul |
| 安全扫描 | 依赖漏洞、镜像漏洞 | ❌ 流水线阻断 | Trivy / Snyk / Dependabot |
| 集成测试 | 接口联调通过 | ❌ 流水线阻断 | Postman / TestContainers |
| 性能测试 | 响应时间 ≤ 阈值 | ⚠️ 告警但不阻断 | JMeter / k6 |
| 许可证检查 | 无 GPL 等污染许可证 | ❌ 流水线阻断 | FOSSA / Black Duck |
| 门禁级别 | 阻断方式 | 适用 |
|---|---|---|
| 🔴 硬性门禁 | 不通过则流水线失败，无法合并 | 安全漏洞、测试覆盖率 |
| 🟡 软性门禁 | 不通过则告警，可人工 override | 性能、代码风格 |
| 🟢 建议门禁 | 仅展示结果，不影响流程 | 代码复杂度、注释率 |
五、发布策略对比
| 策略 | 做法 | 风险 | 回滚速度 | 适用场景 |
|---|---|---|---|---|
| 蓝绿部署 | 两套环境，切流量 | 低 | 秒级（切回） | 传统应用、数据库迁移 |
| 金丝雀发布 | 先放 5% 流量，逐步放大 | 中 | 分钟级 | 微服务、高流量应用 |
| 滚动更新 | 逐台替换旧实例 | 中 | 分钟级 | K8s 原生应用 |
| A/B 测试 | 同时跑两个版本对比 | 低 | 即时切换 | 前端、产品实验 |
| 影子发布 | 新版本接收真实流量但不返回 | 极低 | 无需回滚 | 核心系统验证 |
| 策略 | 流量切换方式 | 观测期 | 推荐度 |
|---|---|---|---|
| 蓝绿 | 一键切 DNS/LB | 短 | ⭐⭐⭐⭐ |
| 金丝雀 | 渐进式（5%→20%→50%→100%） | 长 | ⭐⭐⭐⭐⭐ |
| 滚动 | 逐台替换 | 中 | ⭐⭐⭐ |
| A/B | 随机分组 | 长 | ⭐⭐⭐⭐ |
| 影子 | 只收不发 | 长 | ⭐⭐⭐ |
六、主流 CI/CD 工具对比
| 工具 | 类型 | 优势 | 劣势 | 适合场景 |
|---|---|---|---|---|
| GitHub Actions | 云端 | 生态丰富、与 GitHub 无缝集成 | 深度定制受限 | GitHub 用户、开源项目 |
| GitLab CI | 原生集成 | 代码+CI+CD 一体、.gitlab-ci.yml |
高级功能需付费 | 中小团队、GitLab 用户 |
| Jenkins | 自托管 | 插件最多、最灵活 | 维护成本高、界面老旧 | 传统企业、深度定制 |
| ArgoCD | GitOps | 声明式、自动同步、回滚方便 | 仅 K8s | K8s 重度用户 |
| Tekton | 云端原生 | K8s 原生、可扩展 | 较新、学习曲线陡 | 云端原生团队 |
| Spinnaker | 多云部署 | 多云统一部署 | 复杂、重 | Netflix 级别多云 |
| 选型决策 | 推荐 |
|---|---|
| 小型团队、GitHub 为主 | GitHub Actions ✅ |
| 中型团队、GitLab 为主 | GitLab CI ✅ |
| 传统企业、深度定制 | Jenkins ✅ |
| K8s 重度用户、追求 GitOps | ArgoCD ✅ |
| 多云复杂部署 | Spinnaker ✅ |
七、CI/CD 最佳实践
| 实践 | 说明 | 收益 |
|---|---|---|
| 提交即构建 | 每次 Push 触发 CI，5 分钟内出结果 | 快速发现集成问题 |
| 分支策略配合 | Feature Branch + PR 触发 CI | 主干永远干净 |
| 缓存依赖 | 缓存 node_modules / .m2 / Docker 层 | 构建速度提升 50%+ |
| 并行执行 | 测试、扫描、构建并行跑 | 流水线时间减半 |
| 失败快速 | 最先跑最可能失败的步骤（如编译） | 节省资源和时间 |
| 环境一致 | Dev = Staging = Prod（容器化） | 消除"在我机器上能跑" |
| 制品不可变 | 镜像打 tag 后不修改，重新部署用新 tag | 可追溯、可回滚 |
| 秘密管理 | 密码/Key 走 Vault，不写在代码里 | 安全合规 |
| 实践 | 难度 | 优先级 |
|---|---|---|
| 提交即构建 | ⭐ | 🔴 必须 |
| 并行执行 | ⭐⭐ | 🔴 必须 |
| 缓存依赖 | ⭐ | 🔴 必须 |
| 分支策略 | ⭐⭐ | 🔴 必须 |
| 失败快速 | ⭐⭐ | 🟡 强烈推荐 |
| 环境一致 | ⭐⭐⭐ | 🟡 强烈推荐 |
| 制品不可变 | ⭐⭐ | 🟡 强烈推荐 |
| 秘密管理 | ⭐⭐ | 🟡 强烈推荐 |
八、常见误区
| 误区 | 真相 |
|---|---|
| ❌ CI/CD = 买个 Jenkins 就行 | ✅ 工具只是载体，流水线设计 + 质量门禁才是核心 |
| ❌ CI 跑得越快越好 | ✅ 快很重要，但不能跳过测试，否则快了也白搭 |
| ❌ 持续部署 = 不需要测试 | ✅ 持续部署的前提是测试覆盖率极高 + 自动化回滚 |
| ❌ 一个流水线走天下 | ✅ 应该按场景拆分：PR 验证流水线 vs 生产发布流水线 |
| ❌ CI/CD 只对开发有用 | ✅ 运维、测试、安全都受益，全员可见 |
| ❌ 上了 CI/CD 就不会出故障 | ✅ CI/CD 降低故障概率，但不能消除故障，还需可观测 + 混沌工程 |
九、实施路线图
| 阶段 | 目标 | 关键动作 | 周期 |
|---|---|---|---|
| 第1步：CI 基础 | 代码提交自动构建+测试 | 搭 GitHub Actions/GitLab CI + 单元测试 | 1-2周 |
| 第2步：质量门禁 | 不合格代码进不了主干 | 加 SonarQube + 安全扫描 + 覆盖率门禁 | 2-4周 |
| 第3步：CD 自动化 | 构建通过自动部署到预发 | 搭 CD 流水线 + Docker 镜像推送 | 2-4周 |
| 第4步：发布策略 | 安全上线，可回滚 | 蓝绿/金丝雀 + 健康检查 | 2-4周 |
| 第5步：GitOps | Git 驱动一切部署 | ArgoCD/FluxCD 接管发布 | 4-8周 |
| 第6步：优化 | 流水线 < 10 分钟 | 缓存、并行、失败快速 | 持续 |
| 阶段 | DORA 等级 | 典型表现 |
|---|---|---|
| 第1-2步 | 待改进 → 良好 | 每天能部署，有基本质量门禁 |
| 第3-4步 | 良好 | 自动化到预发，有发布策略 |
| 第5-6步 | 精英 | 每天多次部署，全自动回滚 |
十、一句话总结
| CI/CD | |
|---|---|
| 本质 | 自动化流水线 + 质量门禁 + 发布策略 |
| 核心价值 | 每次变更都能安全、快速、可重复地走完全流程 |
| 终极目标 | 提交代码 → 自动构建 → 自动测试 → 自动上线 → 出事自动回滚 |
| 衡量标准 | DORA 四指标：部署频率↑、前置时间↓、失败率↓、MTTR↓ |