1. 先把名词说清楚：Deploy、Release、Delivery 的边界
你会经常听到“我们已经有 CD 了（因为能部署）”。这句话通常只对了一半。
- Deploy（部署）：把制品放到某个环境并运行起来（可手动、可脚本）。
- Release（发布）：让用户开始接触到变化（可能是 1% 流量，也可能是全量）。
- Delivery（交付）：一个端到端系统，保证“从制品到用户”过程可重复、可回滚、可审计，并且能用数据做止损。
一个判断题：如果生产环境出了问题，你只能“再发一次试试”，而不是“回滚到上一个已知好版本”，那你有部署自动化，但 CD 系统还不完整。
2. CD 的骨架：制品晋级（Promotion）
把“交付”做稳，最关键的一步是：同一份制品沿环境晋级。否则每个环境重新构建，相当于每次都在投骰子：你交付的究竟是哪个版本？
2.1 为什么晋级很重要？
- 可重现：staging 验证过的，就是 prod 会拿到的。
- 可追溯：制品 digest / SBOM / provenance 一路跟随。
- 可回滚：回滚不需要重新构建，只需要切换引用。
2.2 晋级需要的“门”
- 质量门：测试、扫描、制品签名验证、策略校验。
- 变更门：审批、变更窗口、紧急通道。
- 数据门：发布后指标是否健康？（这会在后续“渐进交付”深入）
图 1：CD 的骨架是“制品晋级”。构建一次，跨环境推进；每一步都有门禁与证据链，才能做到可回滚、可审计。
3. 环境不是“几套机器”，而是风险模型
许多团队的环境设计是“历史自然长出来的”：dev、test、pre、prod……名字很多，但边界不清。 在 CD 里，环境设计的核心是：把风险拆开，把权限拆开，把变量钉死。
3.1 环境要回答的三个问题
- 这套环境验证什么？（功能、性能、安全、兼容、回归、容量……）
- 它与生产有多像？（数据、依赖、网络策略、配额、拓扑）
- 谁能改它？（权限边界、审批、审计、紧急通道）
实用经验：staging 不必“完全等于生产”，但它必须在“会出问题的维度”上足够像生产，例如同样的依赖、同样的网络出口、同样的限流/鉴权策略。
4. CD 的“变量管理”：config vs secret vs feature flag
CD 经常失败不是因为“部署脚本写错”，而是因为变量混在一起：配置、机密、开关、版本兼容没有被系统化管理。 一旦它们搅在一起，你就会遇到典型灾难：回滚镜像但配置没回滚、开关开错导致事故、机密泄露无法追溯。
- config：可公开/非敏感的运行参数（应版本化、可回滚、可审计）。
- secret：敏感凭证（应最小权限、短期化、轮换、审计）。
- feature flag：控制“功能是否对用户生效”的开关（应可灰度、可快速关闭、可审计）。
图 2：变量交付矩阵。CD 里真正难的是“让变量可控”：版本化、审计、回滚/吊销与快速止损各有方法。
5. 发布策略与门禁：把风险拆开，而不是赌运气
CD 的“策略”是把一次大的风险，拆成很多个小风险，并且每一步都能观测、能止损。你会在后续章节深入蓝绿/金丝雀/灰度， 这里先把发布策略放在一张“控制面”视角上理解。
- 门禁（Gate）：审批、策略校验、变更窗口。
- 分批（Batching）：按时间、按人群、按区域逐步扩大。
- 判定（Judgment）：指标阈值、错误预算、健康检查。
- 止损（Mitigation）：自动回滚、降级、冻结发布。
图 3：CD 控制面视角。门禁让“谁能发”可控，观测让“发得怎么样”可见，止损让“出事怎么收”自动化。
6. CD 的最小成熟度模型（从 0 到 1 的路线）
- Level 0：能手动部署（但不可回滚/不可追溯）。
- Level 1：部署自动化 + 制品可追溯（tag/digest/版本号）。
- Level 2：制品晋级 + 门禁 + 审计（审批、策略、变更窗口）。
- Level 3：渐进发布 + 指标判定 + 自动止损（回滚/冻结/降级）。
- Level 4：GitOps/声明式交付 + 策略即代码 + 多团队治理（规模化）。
现实建议：不要一上来就追求“最炫的工具”。先把“制品晋级 + 可回滚 + 可审计”做到稳定，这三件事能显著抬升交付上限。