Continuous Delivery
每一次变更都被自动准备成可发布形态。最后是否真的发布到生产，仍由人来按下那个按钮。
Continuous Delivery 是 Continuous Deployment 的负责任表亲。每一次变更都走过同一条自动化的构建、测试与发布准备流水线（即 CI/CD 骨干）。出来的产物是可发布的。它是否真的发布，是一个人的判断。
多数团队停在 CD 而不进到完整 Continuous Deployment 的原因：一次糟糕发布的代价高到让环节里的一个人值这点延迟。当你的监控、测试覆盖与回滚故事都好到那个人已不再贡献信号时，再进到 Continuous Deployment。
按服务而非按公司来选，举个实际例子：同一家公司跑着一个营销站点和一个支付账本。营销站点非常适合完整的 Continuous Deployment，那里一次糟糕发布意味着一个拼写错误、回滚也很琐碎，所以每个通过的构建都能无人值守地发布。支付账本留在 Continuous Delivery、由一个人按按钮，因为那里一次糟糕发布会错误地移动钱，那个人是真正在贡献信号，而不只是延迟。把「我们要不要自动化部署」当作一个全公司统一的决定，正是那个错误；它是一个按服务的风险判断。
有一个值得点名的监管维度。在有变更控制或审计要求的领域（金融、医疗、任何在 GDPR 下触及个人数据的东西），Continuous Delivery 里那一步人工批准不只是风险管理，它往往就是审计师期望看到的那项书面控制：谁批准了这次发布、对着什么证据、在何时。这些场景里的团队不应当把完整 Continuous Deployment 当作一枚成熟度勋章去追；那道手动闸门是他们合规故事所依赖的一项特性。把直到按钮之前的一切自动化，然后把按钮留在审计链需要它的地方。
诚实的取舍：Continuous Delivery 给你近乎完整自动化的大部分速度，同时在那个不可逆的步骤上保留人的否决权，代价是当那个人慢了或不在时，否决权会成为瓶颈。毕业到它之上的前提是真实的、不是空想的：一套 TDD 支撑、团队敢在后面发布的套件、一次以分钟而非小时计的回滚，以及一个待命轮值。没有这三样，「Continuous Delivery」就是一个没人敢按的按钮，而那条流水线只是叠在一段本来健康的 SDLC 之上的装饰。