1. CI/CD 基础概念：持续集成、持续交付、持续部署的定义与区别，CI/CD 流水线的核心价值

1.1 从传统部署到自动化交付的演进

在软件交付的早期阶段，开发团队通常采用“阶段式”或“瀑布式”模型：开发周期长达数周甚至数月，代码在开发环境完成后一次性提交给测试团队，测试通过后由运维手动部署到生产环境。这种模式带来的核心痛点包括：

• 集成地狱：多个开发者的代码在项目后期合并时频繁出现冲突，修复成本极高。
• 反馈延迟：从代码提交到发现缺陷，往往需要数天甚至数周，上下文切换成本巨大。
• 手动操作风险：部署依赖人工执行脚本或点击界面，极易因环境差异、配置遗漏或操作失误导致故障。
• 安全合规盲区：权限管理松散，缺乏可审计的变更记录，难以满足 SOC2、PCI-DSS 等合规要求。

CI/CD 方法论的出现，正是为了解决上述问题。它将软件交付从“人工接力”转变为“自动化流水线”，通过持续集成、持续交付和持续部署三个递进阶段，实现快速、可靠、可审计的软件发布。

1.2 核心概念定义与区别

持续集成、持续交付、持续部署是 CI/CD 体系中的三个关键实践，它们既有紧密联系，又在自动化边界上存在明确区别。下表从定义、触发时机、核心目标、自动化程度和典型输出五个维度进行对比：

维度	持续集成 (CI)	持续交付 (CD)	持续部署 (CD)
定义	开发人员频繁（每天多次）将代码合并到主干，并通过自动化构建与测试验证每次合并的正确性。	在 CI 基础上，确保代码始终处于可部署到生产环境的就绪状态，但部署动作由人工触发。	在持续交付基础上，将部署到生产环境的动作也完全自动化，无需人工干预。
触发时机	代码推送到版本控制仓库（如 git push）。	CI 阶段通过且通过验收测试后。	CD 流水线所有检查通过后自动触发。
核心目标	尽早发现集成错误，保证主干代码质量。	降低发布风险，使发布成为低压力、可重复的流程。	消除发布瓶颈，实现全自动化端到端交付。
自动化程度	构建、单元测试、代码扫描全自动。	CI 全自动 + 部署到类生产环境（如 Staging）全自动。	CI + 部署到生产环境全自动。
典型输出	构建产物（如 JAR、Docker Image）及测试报告。	可部署的制品 + 人工审批按钮。	生产环境自动更新 + 监控告警。

1.3 CI/CD 流水线的核心价值

实施 CI/CD 流水线不仅仅是引入一套自动化工具，更是对团队协作方式、质量文化和安全合规体系的系统性升级。其核心价值体现在以下四个维度：

1. 加速价值交付：从代码提交到功能上线，时间从数周缩短到分钟级或小时级。高频发布使业务能够快速响应市场变化。
2. 提升代码质量：每次提交都触发自动化测试（单元测试、集成测试、静态代码分析），缺陷在引入阶段即被捕获，修复成本降低 80% 以上。
3. 降低部署风险：通过标准化的流水线步骤和不可变制品，消除环境差异导致的“在我机器上能跑”问题。自动化回滚机制确保故障时快速恢复。
4. 强化安全合规：流水线内置安全扫描（SAST、DAST、依赖项检查）、密钥管理和权限控制，所有变更均有审计日志，满足合规审计要求。

1.4 CI/CD 流水线核心流程架构

下图展示了一条典型 CI/CD 流水线从代码提交到生产部署的核心阶段与关键节点。该架构图涵盖了 CI 阶段（代码扫描、构建、单元测试）和 CD 阶段（制品管理、环境部署、安全合规门禁），是后续章节构建 SLI 口径的基础蓝图。

1.5 流水线中的关键角色与职责

CI/CD 流水线的成功实施需要多个角色协同配合。下表梳理了各角色在流水线中的核心职责：

角色	流水线中的职责	关注的核心指标
开发工程师	编写代码、编写单元测试、处理 CI 失败反馈、参与代码审查。	构建成功率、测试覆盖率、修复时间 (MTTR)。
测试工程师	设计集成测试/端到端测试用例、维护测试环境、分析测试报告。	测试通过率、缺陷逃逸率、环境可用性。
运维/平台工程师	维护 CI/CD 基础设施、配置环境、管理密钥与凭证、监控流水线健康。	流水线执行时间、基础设施可用性、部署频率。
安全合规团队	定义安全扫描策略、配置合规门禁、审计变更记录、处理安全告警。	安全漏洞修复率、合规通过率、审计覆盖率。

1.6 常见误区与避坑指南

1.7 本章小结