蓝绿部署
蓝绿部署简单来讲就是在生产环境中有两套系统：一套是正在提供服务的系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。
最初，没有任何系统，没有蓝绿之分。
然后，第一套系统开发完成，直接上线，这个过程只有一个系统，也没有蓝绿之分。
后来，开发了新版本，要用新版本替换线上的旧版本，在线上的系统之外，搭建了一个使用新版本代码的全新系统。这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。
蓝色系统不对外提供服务，用来做啥？
用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。（注意，两套系统没有耦合的时候才能百分百保证不干扰）
蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统：
切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。
当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。
金丝雀发布
金丝雀发布（Canary）也是一种发布策略，和国内常说的灰度发布是同一类策略。它和蓝绿有点像，但是它更加规避风险。你可以阶段性的进行，而不用一次性从蓝色版本切换到绿色版本。
采用金丝雀部署，你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它，可以最大限度的降低影响。
如果没有错误发生，把剩余的 V1 版本全部升级为 V2 版本。如果有错误发生，则直接回退到老版本，发布失败。下图示范了金丝雀部署：
其实金丝雀发布的名称来源于一个典故。 在 17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体特别敏感，空气中哪怕有极其微量的瓦斯，金丝雀也会停止唱歌。当瓦斯含量超过一定限度时，人类毫无察觉，但金丝雀却会毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为”瓦斯检测指标“，以便在危险情况下紧急撤离。
映射到这里就是先发布一小部分来试探整体是否能够正常运行，如果能正常运行则进行完全部署的发布方式，目前仍然是不少成长型技术组织的主流发布方式。