2. 交付流水线概述：CI/CD与GitOps流水线的区别、GitOps流水线典型阶段
在云原生与Kubernetes主导的交付时代，传统的CI/CD流水线与GitOps流水线在架构哲学、触发机制、状态管理上存在本质差异。理解这些差异是构建声明式差异检测清单的前提。本章首先对比两种流水线的核心区别，然后拆解GitOps流水线的四个典型阶段。
2.1 CI/CD与GitOps流水线的核心区别
传统CI/CD流水线以“构建-测试-部署”的管道式运行为核心，而GitOps流水线以“Git仓库作为单一事实来源”的声明式驱动为核心。下表从六个关键维度进行对比：
| 对比维度 | 传统CI/CD流水线 | GitOps流水线 |
|---|---|---|
| 触发机制 | 代码推送、定时任务、手动触发 | Git仓库变更（Pull Request / Merge） |
| 部署方式 | 流水线脚本直接执行 kubectl / 脚本推送 | Operator（如Argo CD / Flux）自动同步 |
| 状态管理 | 流水线执行状态，无持续状态修正 | 声明式期望状态，持续调谐（Reconcile） |
| 回滚策略 | 重新运行旧版本流水线或手动回滚 | Git revert 提交，Operator自动同步回旧状态 |
| 安全模型 | CI/CD工具持有集群凭证 | Operator持有凭证，开发者仅操作Git |
| 差异检测 | 通常无声明式差异检测，依赖测试 | 持续对比Git期望状态与集群实际状态 |
关键认知： GitOps将“部署”从“执行动作”转变为“状态同步”。流水线的终点不再是集群变更，而是Git仓库的声明式清单更新。差异检测成为同步前的强制关卡。
2.2 GitOps流水线典型阶段
一条完整的GitOps交付流水线通常包含四个紧密衔接的阶段。每个阶段都产生或消费声明式清单，并可能触发差异检测。
阶段一：代码提交（Code Commit）
开发者将应用源代码推送至Git仓库（如GitHub / GitLab）。此阶段触发CI流程，但尚未涉及部署清单。关键产出是源码版本号（Commit SHA / Tag）。
- 输入： 应用源代码、Dockerfile、测试脚本
- 输出： 代码提交记录、Webhook事件
- 差异检测点： 无（此时无声明式清单）
阶段二：镜像构建（Image Build）
CI工具（如Jenkins / GitHub Actions）根据Dockerfile构建容器镜像，并将镜像推送至镜像仓库（如Harbor / ECR）。镜像标签通常与代码版本关联。
- 输入： 源码、Dockerfile、构建参数
- 输出： 容器镜像（含唯一Tag）
- 差异检测点： 镜像安全扫描、构建产物校验
阶段三：配置更新（Config Update）
这是GitOps流水线的核心转折点。CI工具或自动化脚本将新镜像Tag写入Git仓库中的Kubernetes清单文件（如Deployment.yaml / Kustomize overlay）。此操作通过Pull Request完成，触发代码审查。
- 输入： 新镜像Tag、环境配置参数
- 输出： 更新后的声明式清单（提交至Git）
- 差异检测点： 清单格式校验、镜像Tag一致性检查、配置漂移检测
阶段四：同步部署（Sync Deploy）
GitOps Operator（如Argo CD / Flux）检测到Git仓库中清单变更，自动将期望状态同步至目标Kubernetes集群。同步前Operator会执行声明式差异对比，生成Diff报告。
- 输入： Git仓库中的最新声明式清单
- 输出： 集群实际状态与期望状态一致
- 差异检测点： 集群实时差异对比、资源健康状态检查、同步策略执行
实践建议： 在“配置更新”阶段引入自动化差异检测清单，可以在PR合并前发现清单错误、镜像缺失或配置冲突，避免将问题带入同步阶段。
2.3 GitOps流水线阶段关系图
下图展示了四个典型阶段的串联关系以及差异检测的介入位置：
2.4 流水线阶段与差异检测清单的映射
在后续章节中，我们将为每个阶段定义具体的检测清单项。下表预先建立阶段与清单类型的映射关系：
| 流水线阶段 | 检测清单类型 | 检测时机 | 失败处理策略 |
|---|---|---|---|
| 代码提交 | 源码合规性检查 | Push / PR时 | 阻断CI流程 |
| 镜像构建 | 镜像安全与完整性 | 构建完成后 | 阻止镜像推送 |
| 配置更新 | 声明式清单差异检测 | PR合并前 | 拒绝合并请求 |
| 同步部署 | 集群实时状态差异检测 | 同步执行前 | 暂停同步并告警 |
常见误区： 很多团队只在同步部署阶段做差异检测，忽略了配置更新阶段的清单预检。这会导致不合规的清单进入Git仓库，即使Operator同步时发现差异，也已经造成了配置污染。正确的做法是在PR合并前完成声明式清单的全面验收。