第 8 章 · 01 持续集成与持续交付
文档摘要
第 8 章 · 01 持续集成与持续交付 CI/CD 三个字母经常被连读，但"集成、交付、部署"是三级不同的自动化阶梯：CI 管"能不能合"，Delivery 管"随时能发"，Deployment 管"自动发"。本节先把阶梯分清楚，再拆解流水线的通用要素——以 GitHub Actions 为标本，最后给出质量门禁与 KPI 度量体系。 学习目标 说清 CI、持续交付、持续部署的区别与触发时机 理解 Workflow/Runner/Job/Step/Action 的层级关系 掌握 jobs 的并行默认与 needs 依赖 知道流水线存放位置的四种方案与取舍 用 KPI 度量 CI/CD 质量 一、三级阶梯：CI、Delivery、Deployment
第 8 章 · 01 持续集成与持续交付
CI/CD 三个字母经常被连读，但"集成、交付、部署"是三级不同的自动化阶梯：CI 管"能不能合"，Delivery 管"随时能发"，Deployment 管"自动发"。本节先把阶梯分清楚，再拆解流水线的通用要素——以 GitHub Actions 为标本，最后给出质量门禁与 KPI 度量体系。
学习目标
- 说清 CI、持续交付、持续部署的区别与触发时机
- 理解 Workflow/Runner/Job/Step/Action 的层级关系
- 掌握 jobs 的并行默认与 needs 依赖
- 知道流水线存放位置的四种方案与取舍
- 用 KPI 度量 CI/CD 质量
一、三级阶梯：CI、Delivery、Deployment
持续集成（CI）：开发者频繁将代码集成到共享仓库的开发实践（每天几次到大规模场景每小时几次）。每次代码变更都要被验证——现代常见做法是用自动化构建跑测试（可单构建多层级测试，也可多构建组合门禁），通过才允许合并。CI 回答的问题是"能不能合"。
持续交付（Continuous Delivery）：频繁将代码交付给 QA 和运维测试。需要一个接近生产特性的 staging 环境，变更经过人工审核后才能进入生产。由于人工参与，发布与审核之间存在时间差——比持续部署更慢、更易错，但保留人工把关。Delivery 回答"随时能发"。
持续部署（Continuous Deployment）：任何代码提交都必须通过自动化测试阶段，通过即自动发布到生产，消除人工干预。前提：生产就绪的流水线 + 对已部署资产的实时监控与报告；生产出问题时应能轻松回滚。Deployment 回答"自动发"。
| 维度 | CI | Delivery | Deployment |
|---|---|---|---|
| 目标 | 频繁合并 + 自动验证 | 代码始终可发布 | 通过测试即上线 |
| 自动化 | 构建/测试 | 部署前人工审批 | 全自动 |
| 发布触发 | 每次提交 | 人工批准/时间约束 | 每次通过测试的变更 |
CI/CD 的好处：快速反馈（提交后立刻得到结果）、低风险小批量发布（小变更出问题范围小）、自动化可审计（流水线即代码）、快速回滚（Git 有版本记录）、一致的交付路径。
二、一次完整的 CI/CD 流程
典型路径（PR 驱动）：
- 开发者提交 PR；
- 触发两个 Job：一个跑 lint；另一个构建包含该变更的包并跑 API/场景测试；
- 测试全部通过 + 维护者批准 → 合并进仓库；有测试失败则禁止合并。
推送驱动路径：push 代码 → 构建容器镜像并推送 registry → 更新 K8s manifest → 集群应用新变更。一次 CI/CD 过程可能包含的阶段：Compile（编译）→ Build（构建）→ Install（安装）→ Configure（配置）→ Update（更新）→ Test（测试）。
三、流水线要素：以 GitHub Actions 为标本
Workflow：放在仓库里的 YAML 文件，定义在特定事件（event）上执行的自动化指令。
Runner：Workflow 实际执行的环境（自建主机或 GitHub 托管主机）。
Job：在同一 Runner 上执行的一系列步骤；一个 Workflow 至少一个 Job。默认并行执行——这是最容易记反的点。
Step：Job 内顺序执行的最小命令单元。
Action：工作流中的最小可复用单元。
Job 间依赖用 needs 关键字（上游成功后才运行下游）：
on: [push, pull_request] # 触发事件 jobs: lint: test: needs: lint # lint 成功完成后 test 才运行
四、流水线存放位置
四种方案：
- 应用仓库：流水线与应用代码同仓——最流行，变更与代码一起走 PR 评审；
- 中心仓库：所有流水线放一个独立仓库——多团队、流水线很多时的最佳选择；
- 每应用一个 CI 仓库：CI 与业务代码分离但不集中——维护成本最高，最差；
- 执行平台本身：如 Tekton/OpenShift Pipelines 存在 K8s 集群内。
五、质量门禁与 KPI
质量门禁（Quality Gates）：lint 检查、SonarQube 静态分析（复杂度、重复代码、覆盖率）、多层级测试（单元、功能、API、场景）——全部通过才允许合并/发布。构建产物不通过则禁止 merge。
度量 CI/CD 质量的 KPI：
| 指标 | 含义 | 好方向 |
|---|---|---|
| Build Success Rate | 成功构建占比 | 高 = 流水线稳定 |
| Build/Deployment Time | 提交到生产耗时 | 短 = 反馈回路短 |
| Deployment Frequency | 单位时间部署次数 | 高 = 发布周期短 |
| MTTD | 平均发现缺陷时间 | 低 = 发现快 |
| MTTR | 平均恢复时间 | 低 = 停机少 |
| Feedback Loop Time | 反馈耗时 | 快 = 迭代快 |
小结
本节立起了 CI/CD 的三级阶梯与通用骨架：CI 验证可合并、Delivery 保留人工把关、Deployment 全自动上线；Workflow/Job/Step 层级与 needs 依赖构成流水线的骨架；存放位置与质量门禁决定工程治理；KPI 让流水线本身可度量。下一节用 Jenkins 把骨架落到具体工具，重点是其概念体系与两类 Pipeline 语法。
下一节预告
第 8 章第 2 节《Jenkins与流水线实践》将讲解 Job/Build/Node/Executor 概念、声明式与脚本式 Pipeline 的取舍、多节点并行与失败通知，以及 CI/CD 最佳实践清单。