方法

Continuous Delivery

每一次变更都被自动准备成可发布形态。最后是否真的发布到生产，仍由人来按下那个按钮。

最近审阅: 2026-05-24 审阅人Kevin Riedl wiki ↗

Continuous Delivery 是 Continuous Deployment 的负责任版本。每一次变更都走相同的自动化构建、测试与发布准备流水线，最终产物是可发布的；但「是否真的发布」仍由人来决定。

多数团队停在 CD 而不进到 Continuous Deployment 的原因：一次糟糕发布的代价足够高，让保留一个人在环节里值得这点延迟。当你的监控、测试覆盖与回滚故事都足够好，「人」已经不再贡献信号时，再考虑进到 Continuous Deployment。

// FAQ

常见问题

常见问题

看一次糟糕发布的代价。代价高（金融交易、医疗、面向消费者的关键路径），保留 CD 让人审批最后一步。代价低、监控扎实、回滚故事完整，再进到 Continuous Deployment。前者是负责任的默认，后者是奖励。
当那个按按钮的人已经不再贡献信号时。如果他只是看 CI 全绿就批准，那这一步已经是仪式。把仪式去掉，把工程精力放在让监控更准、回滚更快上，比让人继续按按钮更有价值。
不是。多数生产系统应该停在 CD。Continuous Deployment 在搜索引擎、内容平台、SaaS 工具里普及，是因为它们容错域大。一笔错的支付、一次错的医疗下单，不在那个容错域里。形态匹配业务风险，不是匹配 Twitter 上的趋势。