38、软件发布与灾难恢复的有效策略

软件发布与灾难恢复的有效策略

在软件开发和发布过程中，我们常常会遇到各种挑战，如功能未准备好就被要求移除、灾难发生后的过度反应等。本文将探讨如何通过有效的方法控制发布范围、利用特性开关以及应对灾难恢复，以实现更安全、更可控的软件发布。

控制发布范围

曾经，Dave 被要求移除新应用的一部分功能，因为该功能还未到正式发布的时候。然而，三个月后再做这样的操作，就如同要求从咖啡中去除已加入的半奶半咖啡一样，虽可行但需要花费大量时间。

不过，如今我们的工具和软件交付方式有了很大改进。我们能更好地隐藏未准备好的新功能，使用组件或微服务解耦变化较快的应用部分，采用更简单但强大的分支策略使新功能从主线更平稳地推出。

我们可以通过部署环来控制新发布的影响范围，从内部或测试用户开始逐步向外发布，即金丝雀发布，以此观察软件在生产负载下的表现。故障转移可以通过配置切换实现，利用负载均衡和部署插槽将部分用户转移到新版本，同时保留旧版本。监控能让我们在发现严重问题时迅速切断新版本的流量。

一些发布技巧，如蓝绿发布、金丝雀发布、部署环、组件和自愈发布模式等都很出色，但我们尤其钟爱特性开关。谷歌就大量依赖特性开关来降低故障风险，Flickr 在无分支代码库中使用特性开关也取得了很好的效果。

Flickr 使用无分支代码库，所有代码都提交到主干并每天多次推送到生产环境。这对于即时修复 bug 很有效，但在开发需要数月完成的新功能时会有问题。特性开关让我们无需进行合并操作，所有代码一提交就集成，部署变得更小、更频繁，更容易发现和修复 bug。

特性开关并非新概念，开发者几十年来一直使用 if/else 语句控制发布。过去其管理和治理是