金丝雀发布策略与蓝/绿答案

【问题标题】：Canary release strategy vs. Blue/Green金丝雀发布策略与蓝/绿
【发布时间】：2014-07-07 21:40:02
【问题描述】：

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

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

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

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

是否存在金丝雀比蓝/绿更受欢迎的场景，反之亦然？
是否存在部署模型可以同时实施两种策略的场景？

【问题讨论】：

您的理解是正确的，但我不会将蓝绿策略表述为需要一次部署到所有节点。你可以随心所欲地部署它们——唯一的压力是你自己的最后期限。此外，您可以使用蓝绿色仅发布对部分节点的更改（例如，仅修改多个 API 端点池中的一个）。
很好地总结了我在各处看到的这些概念，但首先没有明确的定义！

标签： deployment production-environment release-management blue-green-deployment canary-deployment

【解决方案1】：

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

在我看来，区别在于新的“绿色”版本是否向真实用户公开。如果是，那我就叫它金丝雀。实现 Canary 的一种常见方法是常规蓝/绿，并在新版本中添加特定用户的智能路由。阅读帖子进行详细比较

蓝/绿：

金丝雀：

【讨论】：

很好的解释。但最好在金丝雀插图上显示用户负载百分比示例。
一张图抵千言！！
这真的很好，但我认为您的 Canary 的“之后”图表可以改进，这对于不阅读您文章的人来说有点误导。否则真的很好！

【解决方案2】：

蓝绿发布更简单快捷。

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

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

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

如果您致力于让您有信心这样做的做法，那么进行蓝绿部署也是如此。否则，发出金丝雀。

蓝绿部署的本质是一次部署，而金丝雀部署的本质是增量部署，所以对于一个单一的用户池，我想不出一个可以同时进行的过程.如果您有多个独立的用户池，例如使用不同的区域数据中心，您可以在每个数据中心内执行蓝绿化，跨数据中心执行金丝雀。虽然如果您不需要在数据中心内部署金丝雀，您可能也不需要跨数据中心部署。

【讨论】：

关于颜色含义的几句话： - 旧环境可能是蓝色，新环境可能是绿色。 - 在下一个版本中，旧的将是绿色的。 Wiki: > 许多语言不区分英语中所描述的“蓝色”和“绿色”，而是使用涵盖两者的封面术语 - “grue”
金丝雀并不总是比蓝/绿快。这完全取决于 CI 和 CD 工作流程！

【解决方案3】：

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

金丝雀

金丝雀版本是一种降低在生产中引入新软件版本的风险的技术，方法是在将更改推广到一小部分用户之前将其缓慢推广到整个基础架构。
即将了解新版本的性能（与其他应用程序、CPU、内存、磁盘使用情况等集成）。

蓝/绿：

更多的是关于零停机部署的可预测版本。
在发生故障时轻松回滚。
完全自动化的部署过程

【讨论】：

【解决方案4】：

这里有一些内联定义 -

蓝绿部署 - 部署新版本的应用程序，创建第二个环境。一旦新环境经过测试，它从旧版本接管。老人然后可以关闭环境。
A/B 测试 - 一个应用程序的两个版本同时运行。每个请求都有一部分。然后，开发人员可以比较这些版本。
Canary Release - 新版本的微服务与旧版本一起启动。然后，该新版本可以接收部分请求，团队可以测试该新版本如何与整个系统交互。

【讨论】：

A/B 和 Canary 都在说同样的话。

【解决方案5】：

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

部署（二进制文件）

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

发布（功能）

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

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

然后在选择 Canary 或蓝/绿或任何灰色/混合模式策略之前问问自己：在发布/部署新版本时我们有什么顾虑？只有在您了解自己的担忧之后，才能选择您的策略。

此外，还可以执行更复杂的部署/发布策略。例如，在某些云/基础设施中，可能有多个生产服务器，并将不同比例的负载中继到不同的服务器和产品版本，并在将发布/部署扩展到所有用户之前监控可靠性。

功能标记

“配置”（冷的，甚至热的）哪些功能对哪些（组）用户（不）可用的操作

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

【讨论】：