金丝雀释放策略与蓝/绿

Question

我对金丝雀版本的理解是它在打开粘性会话的情况下部分发布到生产节点的子集。这样，如果您最终发布了错误的错误，您可以控制并最大限度地减少受影响的用户/客户数量。

蓝色/绿色版本的理解是您有2个镜像生产环境（＆＃34;蓝色＆＃34;和＆＃34;绿色＆＃34;），并推送更改一次到蓝色或绿色的所有节点，然后使用网络魔术来控制用户通过DNS路由到哪个环境。

所以，在我开始之前，如果我到目前为止所说的任何内容都不正确，请先纠正我！

假设我或多或少走上正轨，那么关于这两种策略的几个问题：

• 是否存在金丝雀优于蓝/绿的情况，反之亦然？
• 是否存在部署模型可以同时实施这两种策略的情况？

Answer 1

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

如果您已经在测试环境中测试了新版本并且非常确定新版本在生产中正常运行，则可以执行蓝绿色版本。始终使用feature toggles是提高您对新版本的信心的好方法，因为新版本的功能与旧版本的功能完全相同，直到有人翻转功能切换为止。将您的应用程序分解为可以独立发布的小型服务是另一种选择，因为测试的次数越少，可以破解的越少。

如果您不完全确定新版本在生产中正常运行，则需要执行金丝雀发布。即使你是一个彻底的测试人员，互联网也是一个庞大而复杂的地方，总是会遇到意想不到的挑战。即使您使用功能切换，也可能会错误地实现。

部署自动化需要付出努力，因此大多数组织都计划每次都使用一种策略。

如果您致力于让您对此有信心的实践，那么进行蓝绿色部署。否则，发出金丝雀。

蓝绿色的本质是一次性部署，并且canary部署的本质是逐步部署，所以给定一个用户池，我不能想到一个我将描述为在同时。如果您有多个独立的用户池，例如使用不同的区域数据中心，您可以在每个数据中心内进行蓝绿色，并在数据中心内进行金丝雀绿化。虽然如果您不需要在数据中心内部进行金丝雀部署，但您可能并不需要跨数据中心进行部署。

Answer 2

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

在我看来，区别在于新的“绿色”版本是否暴露给真实用户。如果是，那我就称之为金丝雀。实施Canary的常用方法是定期使用Blue / Green，并在特定用户的新版本中添加智能路由。阅读帖子进行详细比较

蓝/绿：

金丝雀：

Answer 3

蓝色/绿色和金丝雀版本在向更广泛的受众发布软件功能之前，解决了针对目标受众测试软件的相同目的。 对于金丝雀，部署可以在下面共享相同的基础设施，但是在蓝/绿的情况下，整个基础设施与前面的路由器/ DNS / reverseeproxy重复，以便路由流量。

在云环境中，脚本和脚本更容易重新创建基础架构，蓝/绿部署是首选，因为它允许基础架构与自动化同步。当需要重建环境的能力时，这是一个很好的能力。

您可以参考以下文章进行更详细的比较：

BlueGreen部署：http://martinfowler.com/bliki/BlueGreenDeployment.html

金丝雀部署： http://martinfowler.com/bliki/CanaryRelease.html

Answer 4

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

金丝雀

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

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

蓝色/绿色：

1. 更多有关零停机部署的可预测版本。
2. 在发生故障的情况下轻松回滚。
3. 完全自动化的部署过程

Answer 5

以下是一些内联定义-

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

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