金丝雀发布（Canary releas）是一种降低在生产中引入新软件版本的风险的技术，方法是在将更改推广到整个基础架构并使其可供所有人使用之前，缓慢地将更改推广到一小部分用户。
与（蓝-绿部署）BlueGreenDeployment类似，您首先将软件的新版本部署到基础架构的子集，没有用户被路由到该子集。
当您对新版本感到满意时，您可以开始将一些选定的用户路由到它。选择哪些用户会看到新版本有不同的策略：一个简单的策略是使用随机样本；一些公司选择将新版本发布给内部用户和员工，然后再发布给全世界；另一种更复杂的方法是根据用户的个人资料和其他人口统计数据来选择用户。
随着您对新版本越来越有信心，您可以开始将其发布到基础架构中的更多服务器并将更多用户路由到它。推出新版本的一个好做法是使用PhoenixServers重新调整现有基础架构的用途，或者使用ImmutableServers配置新的基础架构并停用旧的基础架构。
Canary 版本是ParallelChange的一个应用程序，迁移阶段一直持续到所有用户都被路由到新版本。届时，您可以停用旧的基础设施。如果您发现新版本有任何问题，回滚策略只是将用户重新路由回旧版本，直到您解决了问题。
使用金丝雀版本的一个好处是，如果发现问题，可以在生产环境中使用安全回滚策略对新版本进行容量测试。通过缓慢增加负载，您可以监控和捕获有关新版本如何影响生产环境的指标。这是创建完全独立的容量测试环境的另一种方法，因为该环境将尽可能地类似于生产环境。
尽管这种技术的名称可能并不熟悉[1]，但金丝雀发布的做法已经被采用了一段时间。有时它被称为分阶段推出或增量推出。
在大型分布式场景中，不是使用路由器来决定哪些用户将被重定向到新版本，而是使用不同的分区策略也很常见。例如：如果您有地理分布的用户，您可以先将新版本推出到一个区域或特定位置；如果你有多个品牌，你可以先推广到一个品牌，等等。Facebook 选择使用多个金丝雀的策略，第一个只对其内部员工可见，并且所有的FeatureToggles都打开，这样他们就可以检测新的问题特征早。
由于技术实现的相似性，Canary 版本可以用作实现 A/B 测试的一种方式。但是，最好避免将这两个问题混为一谈：虽然金丝雀版本是检测问题和回归的好方法，但 A/B 测试是一种使用变体实现来测试假设的方法。如果您使用 canary监控业务指标以检测回归，那么也将其用于 A/B 测试可能会干扰结果。在更实际的情况下，可能需要几天时间才能收集足够的数据来证明 A/B 测试的统计意义，而您可能希望在几分钟或几小时内完成金丝雀部署。
使用金丝雀版本的一个缺点是您必须同时管理软件的多个版本。您甚至可以决定同时在生产中运行两个以上的版本，但是最好将并发版本的数量保持在最低限度。
另一个很难使用金丝雀版本的场景是当您分发安装在用户计算机或移动设备中的软件时。在这种情况下，您无法控制何时升级到新版本。如果分布式软件与后端通信，您可以使用ParallelChange来支持这两个版本并监控正在使用的客户端版本。一旦使用量下降到一定水平，您就可以收缩后端以仅支持新版本。
在进行金丝雀发布时，管理数据库更改也需要注意。同样，使用ParallelChange是一种缓解此问题的技术。它允许数据库在推出阶段支持应用程序的两个版本。
