4. CI/CD 流水线基础：持续集成、持续部署、持续交付的区别与联系
在构建事件驱动流水线与 Helm 自动化部署方案之前，必须厘清 CI/CD 体系中三个核心概念：持续集成（CI）、持续交付（CD） 与 持续部署（CD）。三者共同构成了现代云原生应用从代码提交到生产上线的自动化通道，但各自的职责边界、触发时机与自动化程度存在本质差异。
4.1 概念定义与核心职责
| 概念 | 英文全称 | 核心职责 | 自动化终点 |
|---|---|---|---|
| 持续集成 | Continuous Integration | 频繁合并代码 → 自动构建 → 自动测试 | 生成可验证的构建产物（如容器镜像） |
| 持续交付 | Continuous Delivery | CI 产物 → 自动部署到类生产环境 → 人工审批上线 | 生产环境就绪的发布包，等待一键部署 |
| 持续部署 | Continuous Deployment | CI 产物 → 全自动部署到生产环境 | 生产环境直接生效，无需人工干预 |
关键区分：持续交付与持续部署的英文缩写均为 "CD"，但前者强调"随时可发布"，后者强调"自动发布"。在 Helm 场景中，持续交付通常将 Chart 推送至 OCI 仓库等待审批，持续部署则直接执行
helm upgrade --install 到生产集群。
4.2 三者的流程关系与自动化边界
下图展示了从代码提交到生产部署的完整流水线，清晰标出 CI、持续交付、持续部署各自覆盖的阶段与决策点。
4.3 核心区别对比
| 对比维度 | 持续集成（CI） | 持续交付（Continuous Delivery） | 持续部署（Continuous Deployment） |
|---|---|---|---|
| 触发频率 | 每次代码推送 | CI 通过后自动触发 | 持续交付审批后自动触发 |
| 人工介入 | 无（仅修复构建失败） | 需要生产发布审批 | 无（全自动） |
| 部署目标 | 开发/测试环境 | 类生产/预发环境 | 生产环境 |
| 失败影响 | 阻塞后续代码合并 | 阻塞发布版本 | 可能直接影响线上服务 |
| Helm 场景 | Chart 语法校验 + 模板渲染测试 | Chart 推送至 OCI 仓库 + 预发集群安装 | 自动执行 helm upgrade 到生产集群 |
4.4 三者之间的内在联系
CI、持续交付、持续部署并非独立工具链，而是同一流水线的递进阶段：
- CI 是基础：没有可靠的持续集成，后续的交付与部署将建立在不可信的制品之上。每次代码合并必须通过编译、单元测试、代码扫描与容器镜像构建。
- 持续交付是质量门禁：在 CI 产物的基础上，增加集成测试、安全扫描、性能基准测试等环节，确保制品达到生产标准。持续交付的终点是"可发布的候选版本"。
- 持续部署是自动化终点：当持续交付流水线验证通过后，持续部署自动将制品推送到生产环境。在 Helm 场景中，这意味着自动执行
helm upgrade --install --atomic并监控发布状态。
实践要点：大多数团队从 CI + 持续交付起步，保留生产发布的人工审批环节。只有具备完善的监控、回滚与灰度能力后，才建议升级到全自动持续部署。在事件驱动流水线中，CI 阶段通常由 Git 事件触发，持续交付/持续部署阶段则由制品仓库事件或调度器事件驱动。
4.5 在 Helm 自动化部署中的映射关系
将上述概念映射到 Helm 与 Kubernetes 场景，可以得到清晰的职责划分：
| 流水线阶段 | Helm 相关操作 | 典型工具 |
|---|---|---|
| CI | helm lint、helm template --validate、helm unittest |
GitLab CI / GitHub Actions + chart-testing |
| 持续交付 | helm package、helm push 到 OCI 仓库、预发集群 helm install |
Harbor / ECR + Argo CD / Flux |
| 持续部署 | helm upgrade --install --atomic --timeout 到生产集群 |
Argo CD / Flux + 事件驱动触发器 |