每次变更都直接部署到生产环境可能很吓人，但不直接部署到生产环境更吓人。
这就是我在 Amazon 时采用的流程，当时我带领团队服务于数亿客户。通过我的咨询工作，我带领工程团队从每两周一次的定时发布，转变为每次合并代码就直接上线。
我们先从最显而易见的部分说起：
你一定会造成故障。这不是「会不会」的问题，而是「迟早」的问题。
再多的单元测试、集成测试、内部试用、端到端测试或者什么别的，甚至向部署之神献祭，都无法捕获所有 bug。
你一周前对功能做的测试，并没有覆盖你队友最新的改动。
你的测试是针对队友服务的预发布版本做的，而现在那个版本已经变了，里面包含了一个不向后兼容的变更。
你等得越久，堆积在一次发布里的变更就越多。万一需要回滚，你要回滚的是两周的变更，而不是 1-2 小时的量。
如果我们接受故障不可避免这个前提，那么投入大量资源来 QA 一次发布就显得没那么有意义了。相反，我们应该把资源集中在监控和观察发布上，为故障发生时做好准备。
好，接下来聊聊怎么做到：
前置条件：
CI/CD
测试的重要性远低于你的想象。测试无法证明你的变更在生产环境是安全的。没有任何东西能证明。测试真正做的是让失败变得廉价。在 CI 阶段抓到的 bug 只花费几分钟。在生产环境才抓到的 bug 则要搭上你整个晚上做回滚。
所以，在每次合并时跑完整测试套件，或者至少让它在 pipeline 中运行：单元、集成、端到端测试。bug 在 pipeline 里走得越远，解决它的成本就越高。
监控/可观测性
核心目标就是尽早发现回归。要做到这一点，你需要有出色的监控。具体体现在：
- 指标：错误率、延迟、可用性
- 带关联 ID 的日志
- 基于以上两者配置的 sev-3 和 sev-2 告警（带呼叫功能）
调校告警阈值既是一门艺术，也是一门科学。关键在于敏感性和你对真实故障的响应速度之间的平衡。你的 sev-2 告警响应时间目标应该控制在 5-10 分钟内。
一开始，你很可能会调错，也很可能过于敏感。不幸的是，这些只能靠试错来学习，所以前期你可能会有几次凌晨 2 点被叫醒的经历。
功能开关（Feature Flags）
任何有风险的变更，都应该放在功能开关/远程配置后面发布。功能开关让你能在几分钟内回滚或关闭任何变更，而不需要回滚整个部署。另外，如果你的功能开关服务支持的话（应该支持），你还可以按百分比或按群组逐步推出功能，进一步降低坏变更的影响。
这样我们就能把代码的部署与激活解耦。这个区别很微妙，但对降低风险来说是颠覆性的。
注意：你需要一套清理这些开关的流程。理想情况下，每创建一个开关就对应建一个移除工单。否则，当你的功能开关服务挂掉时（它一定会挂的），你会面临严重的回归问题。别问我怎么知道的。
自动回滚（部署时熔断器）
部署时熔断器是一种功能：当你在整个集群中逐步部署时，如果发现错误数量或比例达到阈值，它就会自动回滚部署。现在大多数云厂商都提供这个功能，勾选一个复选框就能启用。
向后兼容的变更
你本来就应该做到这一点，但每次提交都部署会逼着你落实这个实践。在滚动部署期间，旧版本和新版本会同时运行。每个变更都需要与之前的版本共存。你以前那套「半夜部署来规避这个问题」的招数不再管用了。
部署策略
有了以上这些基础，我们来看几种不同的部署策略，它们能帮助你在推出变更时降低风险。
单机部署（金丝雀）
单机部署是把你的变更部署到整个集群中的一台机器上。这样，任何坏变更的影响范围就只限于一台主机。
你部署后让它运行一段时间，接收整体流量中的一小部分。你在这台机器上配置好监控和告警，一旦出问题就会触发告警。
滚动部署
滚动部署允许你按百分比随时间逐步推出。这样，如果出现灾难性错误，你会在它影响所有机器之前发现，并可以开始回滚。
区域分批上线
随着公司发展，你最终会进行多区域部署。与其同时部署到所有区域，你可以先部署到一个特定区域（通常是流量最低的那个）。
这些策略不适用的情况
App Store
发布移动 App 并不完全适用这套方法。App Store 的审核队列会限制你的部署节奏，需要采用不同的策略。
需要认证的环境
医疗设备、航空电子、工业控制等。如果需要监管机构对构建版本进行认证，你就无法持续部署。
本地部署 / 自托管
你无法掌控升级时机。你仍然可以对自己运营的所有系统持续部署，但每个变更仍然需要版本化，由客户决定何时采用。
从哪里开始
不要想一口气全部做完。顺序很重要：
- 让 CI 保持全绿且快速。理想情况下控制在 15 分钟以内
- 为错误率、延迟和可用性配置指标和告警。这是整个过程中最重要的部分
- 把任何有风险的变更放到开关后面
- 加入单机部署 + 自动回滚
- 删掉发布日历
- 既然不用再安排发布了，想想怎么利用你多出来的时间
我合作过的大多数团队大概花一个季度就能完成这一整套。工具反而是最简单的部分。难的是组织流程，以及打破「定时发布很安全」这个幻觉。
如果你的团队还在用发布日历，并且想摆脱它，这正是我做的咨询工作。私信我。
