【原文】： BlueGreenDeployment
【作者】：Martin Fowler
【译者】：随安居士
【时间】：2018.07.01
我和我同事的主要目标是敦促客户采用全自动化部署流程， 自动化部署有助于减少软件“完成”到上线之间的延迟。 Dave Farley和Jez Humble正在完成一本关于本话题的书籍 - 《持续交付-发布可靠软件的系统方法》。它的很多想法来自于持续集成，更关注构建软件快速交付能力。和其他未被有效利用的技术一样，蓝绿部署一节吸引了我的注意，因此我想在此对其进行简要阐述。
自动部署的一大挑战在于自我切换(cut-over itself)，将软件从最终测试阶段切换为在线产品。这一动作要快，尽可能减少系统的停机时间。蓝绿部署通过部署两套的生产环境达到该目的，这两套环境要尽可能保持一致。当准备发布新的软件(版本)时，先在绿环境完成最终测试。如果绿环境工作正常，切换Router使所有的请求路由到绿环境，蓝环境终止。
同样，蓝绿部署可以实现快速回滚：如果绿环境运行异常，切换Router重新启用蓝环境。绿环境运行阶段产生的事务丢失，这仍是一个棘手的问题。当然，这依赖于具体的设计方案，如果绿环境运行过程中，将蓝环境的数据库做为绿环境的同步备，可解决上述问题。或者，在切换前先进入只读模式，运行一段时间后再进入读写模式。这可能足以发现很多潜在的问题。
两套环境需要保持差异，但应尽可能相同。在某些情况下，可能是不同的硬件，可能是运行在相同（或不同）硬件上的不同虚拟机，也可能是同一个操作环境，通过IP地址分为两个单独的区域。
一旦绿环境上线且运行稳定，你就可以把蓝环境做为测试环境并完成最终测试。如果下一个版本准备就绪，将生产环境由绿色切换为蓝色，就之前从蓝色切换到绿色一样。 这样，绿色环境和蓝色环境将在生产版本、前一版本（用于回滚）、下一版本之间定期循环。
这种方式的一个优势在于：其原理和热备份基本相同。因此，每次版本发布相当于做了一次容灾恢复测试（发布频率应比容灾发生频率更高）。
蓝绿部署的基本想法是保持两套可以相互切换的环境，实现上可以有各种细节差异。如切换可以通过跳转Web服务器，而不是在Router上完成。另外一种变化是使用相同的数据库，蓝绿切换只在Web和领域层进行，数据库不切换。
使用该项技术的另外一项挑战来自数据库，尤其是当新版本需要更改Schema时。诀窍是将Schema更改的部署与应用程序升级分开。 因此，首先使用《数据库重构》修改Schema，使数据库同时支持新旧版本应用，部署并检查是否一切正常，此时你拥有了一个回滚点，然后再部署新版本的应用程序（当升级已经结束时，移除数据库对旧版本的支持）。
这项技术已经存在很多年了，但并没未得到应得的使用。Dan North和Jez Humble重新唤醒了它。
更多阅读
您可以在Jez Humble和Dave Farley的《持续交付-发布可靠软件的系统方法》中找到有关此技术和相关技术的更多详细信息。 我的交付指南指出了更多的资料。
致谢
Ketan Padegaonkar插图
Updates
2015-06-05: Hacker News报道后，该页面获得了更多页面流量。 所以我添加了一个关于数据库更改和更多阅读部分的段落。
