金丝雀发布

金丝雀发布是一种降低新软件版本在生产环境中引入风险的技术，它通过先将更改缓慢地推广到一小部分用户，然后再将其推广到整个基础架构并向所有人提供。

与蓝绿部署类似，首先将新版本的软件部署到基础架构的一部分，而没有用户路由到该部分。

如果您对新版本感到满意，则可以开始将一些选定的用户路由到该版本。选择哪些用户将看到新版本有不同的策略：一个简单的策略是使用随机样本；一些公司选择先向其内部用户和员工发布新版本，然后再向全世界发布；另一种更复杂的方法是根据用户的个人资料和其他人口统计信息来选择用户。

随着您对新版本越来越有信心，您可以开始将其发布到基础架构中的更多服务器，并将更多用户路由到该版本。推广新版本的一个好做法是使用凤凰服务器重新利用现有基础架构，或者使用不可变服务器配置新基础架构并停用旧基础架构。

金丝雀发布是并行变更的一种应用，其中迁移阶段一直持续到所有用户都被路由到新版本为止。此时，您可以停用旧的基础架构。如果您发现新版本有任何问题，回滚策略只是将用户重新路由回旧版本，直到您解决问题为止。

使用金丝雀发布的好处是，如果发现问题，可以在生产环境中对新版本进行容量测试，并采用安全的回滚策略。通过缓慢增加负载，您可以监控和捕获有关新版本如何影响生产环境的指标。这是创建完全独立的容量测试环境的另一种方法，因为该环境将尽可能接近生产环境。

尽管此技术的名称可能并不陌生[1]，但金丝雀发布的做法已经采用了一段时间。有时它被称为分阶段发布或增量发布。

在大型分布式场景中，不使用路由器来决定哪些用户将被重定向到新版本，而是使用不同的分区策略也很常见。例如：如果您有地理位置分散的用户，则可以先将新版本发布到某个地区或特定位置；如果您有多个品牌，则可以先发布到单个品牌，等等。Facebook 选择使用具有多个金丝雀的策略，第一个金丝雀仅对其内部员工可见，并且所有功能标志都已打开，以便他们尽早发现新功能的问题。

由于技术实现上的相似性，金丝雀发布可以用作实现 A/B 测试的一种方式。但是，最好避免混淆这两个问题：虽然金丝雀发布是检测问题和回归的好方法，但 A/B 测试是使用变体实现来测试假设的一种方法。如果您监控业务指标以检测金丝雀的回归[2]，那么将其用于 A/B 测试也可能会干扰结果。更实际地说，从 A/B 测试中收集足够的数据以证明统计显着性可能需要几天时间，而您希望金丝雀发布在几分钟或几小时内完成。

使用金丝雀发布的一个缺点是，您必须同时管理多个版本的软件。您甚至可以决定在生产环境中同时运行两个以上的版本，但是最好将并发版本的数量保持在最低限度。

使用金丝雀发布很困难的另一种情况是，当您分发的软件安装在用户的计算机或移动设备上时。在这种情况下，您对何时升级到新版本的控制较少。如果分布式软件与后端通信，则可以使用并行变更来支持这两个版本并监控正在使用哪个客户端版本。一旦使用量下降到一定水平，您就可以收缩后端以仅支持新版本。

在进行金丝雀发布时，管理数据库更改也需要注意。同样，使用并行变更是缓解此问题的一种技术。它允许数据库在推出阶段支持应用程序的两个版本。