CI/CD 流水线概述
CI/CD（持续集成与持续部署/交付）是现代 DevOps 实践的基石，它将软件从代码提交到生产部署的整个过程自动化、标准化。理解 CI/CD 的核心定义、阶段划分以及持续集成与持续部署的区别，是构建可靠流水线、设定有效 SLI 的前提。
CI/CD 的核心定义
- 持续集成 (Continuous Integration, CI)：开发人员频繁地将代码变更合并到主干分支，每次合并都通过自动化构建与测试来验证，从而尽早发现集成错误。
- 持续交付 (Continuous Delivery, CD)：在 CI 的基础上，确保代码随时可以部署到生产环境，但部署动作可能需要手动触发。
- 持续部署 (Continuous Deployment, CD)：在持续交付的基础上，将通过所有自动化测试的代码变更自动部署到生产环境，无需人工干预。
关键区分：持续交付与持续部署的核心区别在于“生产部署是否自动化”。持续交付要求代码随时可部署，但保留人工审批环节；持续部署则完全自动化，适合对发布速度要求极高、且具备完善灰度与回滚能力的团队。
持续集成与持续部署的区别
| 维度 | 持续集成 (CI) | 持续部署 (CD) |
|---|---|---|
| 核心目标 | 快速发现集成错误，保证主干代码质量 | 自动化发布，缩短交付周期，降低发布风险 |
| 主要活动 | 代码合并、构建、单元测试、静态分析 | 集成测试、性能测试、环境部署、灰度发布 |
| 触发方式 | 代码 push 或 PR 合并 | CI 通过后自动触发或手动审批 |
| 产出物 | 构建产物（如 jar、docker image） | 生产环境可运行的服务实例 |
| 失败影响 | 阻塞后续合并，开发需立即修复 | 可能影响生产环境，需具备回滚能力 |
典型流水线阶段
一个完整的 CI/CD 流水线通常包含以下四个核心阶段，每个阶段都对应明确的检查点与质量门禁。
- 代码提交 (Code Commit)：开发者将代码推送至版本控制系统（如 Git），触发流水线。此阶段关注提交频率、分支策略与代码规范。
- 构建 (Build)：将源代码编译、打包为可部署的制品。此阶段关注构建成功率、构建时长与依赖缓存命中率。
- 测试 (Test)：运行单元测试、集成测试、静态代码分析等。此阶段关注测试覆盖率、测试通过率与测试执行时间。
- 部署 (Deploy)：将构建产物部署到目标环境（测试、预发、生产）。此阶段关注部署成功率、部署时长与回滚频率。
SLI 设计启示：每个阶段都可以提取关键 SLI。例如，构建阶段可关注“构建成功率 ≥ 95%”，部署阶段可关注“部署失败回滚率 ≤ 5%”。这些 SLI 将作为后续章节的案例基础。
典型 CI/CD 流水线流程
下图展示了一个包含四个核心阶段的典型 CI/CD 流水线，从代码提交到生产部署的完整路径。
流水线阶段详细说明
| 阶段 | 关键活动 | 常见工具 | 典型 SLI 示例 |
|---|---|---|---|
| 代码提交 | 代码审查、分支合并、提交信息规范检查 | Git, GitHub, GitLab | 提交频率、PR 合并时长 |
| 构建 | 编译、依赖下载、制品打包、镜像构建 | Maven, Gradle, Docker | 构建成功率、构建时长 P95 |
| 测试 | 单元测试、集成测试、代码扫描、安全检测 | JUnit, Selenium, SonarQube | 测试通过率、代码覆盖率 |
| 部署 | 环境配置、灰度发布、健康检查、回滚 | Kubernetes, Ansible, Spinnaker | 部署成功率、回滚频率 |
CI/CD 流水线架构示意
下图从架构视角展示 CI/CD 流水线中各组件之间的协作关系，包括代码仓库、构建服务器、制品仓库、测试环境与生产集群。
常见误区：很多团队将 CI/CD 简单理解为“自动构建+自动部署”，却忽略了测试阶段的质量门禁作用。没有充分测试的自动部署，只会加速故障扩散。建议在每个阶段都设置明确的 SLI 阈值，确保流水线不仅是“自动的”，更是“可靠的”。