CI/CD 成熟度路线图

使用方式

CI/CD 成熟度不是“用了多少工具”，而是从提交到上线能否稳定、可重复、可回滚。按“版本控制 → 持续集成 → 持续交付 → 渐进式发布 → 平台化”五个阶段评估，先补最薄弱的环节。

每一阶段都要有可度量的指标，例如构建时长、变更失败率、恢复时间、部署频率。

检查清单

阶段 1：版本控制与构建

• 代码、配置、基础设施清单都在版本控制中。
• 构建可重复，依赖锁定，产物有版本号。
• 构建缓存和并行化，主分支构建时间可控。
• 制品存到仓库，保留可追溯的元数据。
• 密钥不进入代码和构建日志。

阶段 2：持续集成

• 每次提交触发单元测试、静态检查和构建。
• 测试分层：单元、集成、契约、端到端。
• 失败构建能快速定位，日志可访问。
• 主分支保护，合并前必须通过检查。
• 测试不稳定（flaky）有治理机制。

阶段 3：持续交付

• 构建一次，多环境晋升，不重复构建。
• 环境配置与代码分离，使用 Helm/Kustomize。
• 数据库迁移有版本、回滚和审批。
• 部署自动化，手工步骤有清单和审计。
• 部署失败能自动停止并通知。

阶段 4：渐进式发布

• 支持金丝雀/蓝绿/灰度发布。
• 有自动分析指标并中止发布的机制。
• 回滚在分钟级完成，且经过演练。
• 发布窗口、冻结期和审批策略明确。
• 发布事件与监控、日志、trace 关联。

阶段 5：平台化与度量

• 自助式流水线模板，团队无需重复造轮子。
• 流水线有 SLO：成功率、时长、排队时间。
• DORA 指标（部署频率、 lead time、变更失败率、恢复时间）可观测。
• 安全扫描、合规检查内嵌到流水线。
• 成本、权限和审计集中治理。

常见误区

• 只追求流水线数量，不看变更失败率和恢复时间。
• 每个环境重新构建，导致“测的不是上线的”。
• 手工审批过多，成为瓶颈但没有降低风险。
• 测试只在流水线末尾跑，反馈太慢。
• 没有回滚演练，真出事时回滚比修复还慢。
• 把 CI/CD 当成工具项目，没有平台团队和产品化思维。

相关条目

• github-actions、gitlab-ci、jenkins、tekton
• argocd、flux、argo-rollouts
• helm、kustomize、dockerfile-cheatsheet
• trivy、cosign、gitleaks、semgrep
• build-cicd-pipeline、migrate-jenkins-to-github-actions
• sre-oncall-checklist、incident-response-playbook