2. CI/CD 基础回顾：持续集成与持续部署的核心概念、流水线阶段划分
在深入认证授权平台的接口契约自动校验架构之前，必须夯实 CI/CD 基础。持续集成与持续部署是现代 DevOps 实践的基石，它们将软件交付从手动、低效、高风险的操作转变为自动化、可重复、可审计的工程流程。本章将系统梳理 CI/CD 的核心概念，并详细拆解一条标准流水线的阶段划分。
2.1 核心概念辨析
持续集成、持续交付与持续部署三者常被混用，但其边界与自动化程度存在明确差异。下表从触发时机、人工介入、风险等级三个维度进行对比：
| 概念 | 触发时机 | 人工介入 | 风险等级 | 典型产出 |
|---|---|---|---|---|
| 持续集成 (CI) | 代码提交至共享分支 | 无（自动构建+自动测试） | 低 | 构建产物 + 测试报告 |
| 持续交付 (CD) | CI 通过后 | 需手动确认部署 | 中 | 可部署的制品 + 发布审批单 |
| 持续部署 (CD) | CI 通过后 | 无（全自动部署至生产） | 高 | 生产环境运行实例 |
关键认知： 本课程涉及的“接口契约自动校验”主要作用于 CI 阶段，在代码合并前阻断不兼容的 API 变更。持续部署则依赖 CI 阶段产出的可信制品，两者形成前后依赖关系。
2.2 流水线阶段划分
一条成熟的 CI/CD 流水线通常包含 6 个核心阶段。每个阶段都有明确的输入、输出与质量门禁。下图展示了标准流水线的阶段流转关系：
2.3 各阶段详细职责与质量门禁
每个阶段都承担特定的质量保障职责，并设置明确的“门禁”条件。只有通过当前阶段，流水线才能继续向下游推进。
- 代码提交阶段： 触发流水线执行。门禁：提交信息规范、分支命名合规、无合并冲突。
- 静态分析阶段： 检查代码风格、安全漏洞、潜在缺陷。门禁：无 P0/P1 级别告警。
- 构建与单元测试阶段： 编译代码、运行单元测试。门禁：编译通过、单元测试覆盖率 ≥ 80%、全部用例通过。
- 契约校验阶段： 验证 API 接口变更是否向后兼容。门禁：无破坏性变更、新接口注册成功。
- 集成测试阶段： 部署至测试环境，执行端到端流程。门禁：核心业务场景通过率 100%。
- 部署阶段： 将制品发布至预发布或生产环境。门禁：人工审批（持续交付）或自动灰度策略（持续部署）。
2.4 流水线执行策略对比
不同的团队规模和项目复杂度，需要选择不同的流水线执行策略。下表对比了三种常见模式：
| 策略 | 触发方式 | 并行度 | 适用场景 | 典型工具 |
|---|---|---|---|---|
| 线性流水线 | 串行执行 | 低 | 小型项目、单体应用 | Jenkins Pipeline |
| 并行阶段流水线 | 阶段内并行 | 中 | 中型项目、多模块 | GitLab CI / GitHub Actions |
| 矩阵构建流水线 | 多维度并行 | 高 | 大型项目、多语言/多平台 | Jenkins Matrix / CircleCI |
实践建议： 对于认证授权平台这类涉及多服务、多协议（OAuth2.0、SAML、JWT）的复杂系统，推荐采用“并行阶段流水线”策略，将契约校验、安全扫描、单元测试等无依赖任务并行执行，以缩短整体流水线耗时。
2.5 流水线产物管理
流水线每个阶段都会产生关键产物，这些产物需要被妥善存储、版本化并传递至下游阶段。以下是标准产物清单：
- 构建产物： JAR/WAR 包、Docker 镜像、NPM 包。
- 测试产物： 单元测试报告、覆盖率报告、契约校验报告（含差异对比）。
- 安全产物： SAST 扫描报告、依赖漏洞清单。
- 部署产物： Helm Chart、Kubernetes 部署清单、环境变量配置。
常见陷阱： 产物管理不当会导致“构建一次、部署多次”原则失效。务必为每个构建产物生成唯一版本号（如 Git Commit SHA + 构建序号），并上传至制品仓库（如 Nexus、Harbor、Artifactory），避免在流水线节点间直接传递文件。