金丝雀释放策略与蓝/绿

我对 canary版本的理解是，它是对部分粘性会话已启用的生产节点的部分版本。这样，如果您最终发布了一个严重的错误，则可以控制并最大程度地减少受到影响的用户/客户的数量。

我对蓝/绿发行版的理解是，您拥有两个镜像的生产环境（“蓝”和“绿”），并且您将更改一次推送到蓝或绿的所有节点，然后使用网络魔术来控制通过DNS路由到哪些环境用户。

因此，在我开始之前，如果到目前为止我所说的话是不正确的，请先纠正我！

假设我大致上步入正轨，那么关于这两种策略的几个问题：

• 在某些情况下，金丝雀比蓝/绿优先，反之亦然吗？
• 在某些情况下，部署模型可以同时实施两种策略吗？

蓝绿色释放更简单，更快。

你可以做一个蓝绿色的版本，如果你已经测试在测试环境中的新版本，是非常肯定的是，新版本将在生产正常运行。始终使用功能切换是增加您对新版本的信心的好方法，因为在有人按下功能切换之前，新版本的功能与旧功能完全相同。将您的应用程序分解为可独立发布的小型服务是另一种方法，因为要测试的内容更少，破坏的可能性也更少。

你需要做金丝雀版本，如果你不完全肯定的是，新版本将在生产正常运行。即使您是一位全面的测试人员，Internet仍然是一个庞大而复杂的地方，并且总是会带来意想不到的挑战。即使使用功能切换，也可能无法正确实现。

部署自动化很费力，因此大多数组织都会计划每次都使用一种策略。

如果您致力于使自己充满信心的做法，那么蓝绿色部署也是如此。否则，发出金丝雀。

蓝绿色的本质是一次全部部署，而金丝雀部署的本质是增量部署，因此给定一个用户池，我无法想到我会描述为同时进行的一个过程。如果您有多个独立的用户池，例如使用不同的区域数据中心，则可以在每个数据中心内进行蓝绿色操作，并在各个数据中心之间进行金丝雀。尽管如果您不需要在数据中心内进行金丝雀部署，那么您可能在整个数据中心中都不需要它。

我在这里写了一篇关于这个主题的详细文章：http : //blog.itaysk.com/2017/11/20/deployment-strategies-defined

我认为，区别在于新的“绿色”版本是否向真实用户公开。如果是的话，那我就叫金丝雀。实施Canary的常见方法是常规的Blue / Green，并在新版本中添加了特定用户的智能路由。阅读文章以获得详细比较

蓝绿：

金丝雀：

尽管这两个术语看起来非常接近，但是它们之间存在细微的差异。一个使您对功能发布充满信心，另一个使您对发布方式充满信心。

金丝雀

1. Canary版本是一项技术，可通过将更改缓慢推广到一小部分用户，然后再推广到整个基础架构来降低在生产环境中引入新软件版本的风险。

2. 即将了解新版本的性能（与其他应用程序，CPU，内存，磁盘使用情况等集成）。

蓝绿：

1. 它更多地涉及零停机部署的可预测版本。
2. 发生故障时易于回滚。
3. 完全自动化的部署过程

这是一些内联定义-

• 蓝绿色部署 -部署新版本的应用程序时，将创建第二个环境。测试新环境后，它将取代旧版本。然后可以关闭旧环境。

   

• A / B测试 -一个应用程序的两个版本同时运行。每个请求都有一部分请求。然后，开发人员可以比较版本。  
• Canary版本 -微服务的新版本与旧版本一起启动。然后，该新版本可以接收部分请求，并且团队可以测试该新版本如何与整个系统交互。

定义的良好开端。我认为，如果将“发布”定义分为“部署”和“发布（功能）”，这也有助于您制定策略。

部署（二进制）

将产品二进制部署到（生产）系统的操作。

发布（功能）

管理（一组）用户的功能可用性的操作。

为什么？当“释放”时，您通常有（多个）两个问题：1）错误/向后兼容性/ etc 2）验证新功能的有效性/可用性

然后，在选择Canary或Blue / green或任何灰色/混合模式策略之前，先问问自己：在发布/部署新版本时，我们有什么顾虑？只有这样，如果您知道自己的担忧，便选择策略。

此外，可以执行更复杂的部署/发布策略。例如，在某些云/红外环境中，可能有多个生产服务器，并且可以按不同比例将负载中继到产品的不同服务器和版本，并在将发行/部署扩展到所有用户之前监视健全性。

功能标记

“配置”（冷或什至热）哪些功能（不）适用于哪个（组）用户的操作

如果您还执行“功能标记”之类的操作，则可以先进行部署，从向后兼容性/错误的角度衡量发布的合理性，然后逐步向不同用户发布新功能，反之亦然（按比例缩小甚至回滚功能和/或二进制文件） ）。功能标记允许将功能的可用性与二进制文件的部署分开，并提供比“部署/回滚”更精细的决策