金丝雀发行策略与蓝/绿
我对一个金丝雀版本的理解是，它是一个部分版本的一部分生产节点打开粘滞会话。 这样，如果您最终发布了错误的bug，您可以控制并最大限度地减less受到影响的用户/客户的数量。
我对蓝/绿发行版的理解是，你有2个镜像生产环境（“蓝”和“绿”），你可以一次将所有节点变成蓝色或绿色，然后使用networking魔法来控制哪些环境用户通过DNS路由到。
所以，在我开始之前，如果到目前为止我所说的话都是不正确的，请先纠正我！
假设我或多或less地走上了正轨，那么关于这两个策略的几个问题：
- 有金丝雀比蓝/绿偏好的情况，反之亦然？
- 有部署模型可以同时实施这两种策略吗？
蓝绿释放更简单快速。
如果您已经在testing环境中testing了新版本，并且确信新版本在生产中能够正常运行，那么您可以做一个蓝绿版本。 总是使用function切换是增加您对新版本的信心的好方法，因为新版本的function与旧版完全一样，直到有人翻转function切换。 把你的应用程序分解成小的，独立可释放的服务是另外一个，因为testingless了，可以中断的less。
如果您不完全确定新版本在生产中能够正常运行，则需要进行金丝雀版本。 即使你是一个彻底的testing者，互联网也是一个庞大复杂的地方，总是会遇到意想不到的挑战。 即使您使用function切换，也可能会错误地执行。
部署自动化需要付出努力，所以大多数组织都会计划每次使用一种策略或其他策略。
所以，如果你致力于让你有信心的做法，蓝绿色的部署。 否则，发出金丝雀。
蓝绿的本质是一次全部部署，而金丝雀部署的本质是逐步部署的，所以给定一个单一的用户池，我不能想到一个过程，我将同时描述为两个。 如果您拥有多个独立的用户池（例如使用不同的区域数据中心），则可以在每个数据中心内进行蓝绿色操作，并且可以在数据中心内进行蓝牙操作。 虽然如果您不需要在数据中心内进行金丝雀部署，您可能不需要跨数据中心。
在向更广泛的受众发布软件function之前，蓝/绿和金丝雀版本都可以解决针对目标受众testing软件的相同目的。 在金丝雀的情况下，部署可以在下面共享相同的基础设施，但是在蓝/绿的情况下，整个基础设施与路由器/ DNS / reverseproroxy在内部重复用于路由通信。
在云环境中，更容易脚本和重build基础架构，蓝/绿部署是首选，因为它允许基础架构与自动化同步。 当需要重新创build环境的能力时，这是一个很好的能力。
你可以参考下面的文章进行更详细的比较：
BlueGreen部署： http : //martinfowler.com/bliki/BlueGreenDeployment.html
金丝雀部署： http : //martinfowler.com/bliki/CanaryRelease.html
