加那利发布策略与蓝色/绿色

Question

我对金丝雀版本的理解是，它是对打开粘性会话的生产节点子集的部分发布。这样，如果您最终发布了一个错误，您就可以控制和最小化受影响的用户/客户的数量。

我对蓝色/绿色版本的理解是，您有2个镜像的生产环境(“蓝色”和“绿色”)，同时将更改推送到蓝色或绿色的所有节点，然后使用网络魔法控制用户通过DNS路由到哪个环境。

所以，在我开始之前，如果我说的是不正确的话，请从纠正我开始！

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

• 是否有金丝雀优先于蓝色/绿色的情景，反之亦然？
• 是否有部署模型可以同时实现两种策略的场景？

Answer 1

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

在我看来，区别在于新的“绿色”版本是否公开给真正的用户。如果是，那我就叫它金丝雀。实现金丝雀的一个常见方法是常规的Blue/Green，在新版本中增加了特定用户的智能路由。阅读这篇文章以获得详细的比较

蓝色/绿色：

​

金丝雀：

​

Answer 2

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

如果您已经在测试环境中测试了新版本，并且非常肯定新版本在生产中将正确运行，您可以执行蓝绿色版本。始终使用feature toggles是增强您对新版本的信心的好方法，因为新版本的功能与旧版本完全一样，直到有人翻转功能切换。将您的应用程序分解为小型、独立发布的服务是另一个原因，因为需要测试的更少，破坏的也更少。

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

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

如果你致力于让你有信心这样做的实践的话，蓝绿部署也是如此。否则，把金丝雀送出去。

蓝绿色的本质是一次性部署，而金丝雀部署的本质是增量部署，因此，考虑到一个用户池，我无法想象我所描述的同时执行这两个过程的流程。如果您有多个独立的用户池，例如使用不同的区域数据中心，您可以在每个数据中心内执行蓝绿色操作，并在数据中心执行金丝雀操作。尽管您不需要在数据中心内部署金丝雀，但是您可能不需要跨数据中心部署金丝雀。

Answer 3

虽然这两个术语看起来非常接近，但它们之间有细微的差别。一种是对你的功能发布有信心，而另一种则是你发布的方式。

金丝雀

1. 金丝雀版本是一种降低在生产中引入新软件版本的风险的技术，方法是在将更改推出到整个基础设施之前，将更改缓慢地扩展到一小部分用户。
2. 它即将了解新版本将如何执行(与其他应用程序、CPU、内存、磁盘使用等集成)。

蓝色/绿色：

1. 更多的是关于具有零停机时间部署的可预测版本。
2. 在失败的情况下容易回滚。
3. 完全自动化部署过程