18 | 蓝绿红黑灰度发布：这些五颜六色的发布到底怎么用？

你觉得金丝雀发布可以用在移动端应用或者桌面应用上吗？如果可以的话，大概要怎么实现呢？ 首先，我们目前一般都在采用红黑部署的模式，对于不重要的更新，偶尔会尝试灰度部署。灰度部署可能对于互联网类型的大流量高并发的应用更有意义，因为它们会涉及到更多的资源，灰度发布会更节省资源。 我理解金丝雀发布这种方式并不会和某种应用类型绑定，之所以在Web应用中流行，是因为对于用户来说，Web类型的应用，只需要在用户端安装浏览器即可，不需要有额外的配置，所有的安装部署全部在服务器端进行，更容易控制。 如果在移动端或者桌面端实施这一部署方式，需要1. 筛选种子用户，发送版本更新消息，并提供更新途径。2. 用户更新版本后，收集用户使用情况，评估新版本是否达到预期目标。3. 根据评估结果，决定是否升级版本或者回滚。 种子用户的维护比较重要，一般会先从内部用户开始逐渐扩展。 无论哪种类型的应用，采用金丝雀的方式进行部署，都会对监控提出更高的要求。

中午知道蓝绿红黑灰的使用场景和定义，非常受用

我们通过 A/B Test 框架来实现移动端应用的金丝雀发布。具体的方式就是，A/B 的流量划分模块指引逻辑的路由，不同流量背后的实验定义完全参数化，这样就有办法通过后端的配置来控制前端行为。这种思想对于： - 待上线新功能进行内部 dog-food、线下试运营、灰度发布 - 对有特殊情况的真实用户，调整系统的业务处理逻辑 - 在并行自动化测试中，隔离其他测试用例或设置的影响 - 生产环境回归测试 都可以用到。

在生产环境下做集成测试提到了两个方法对于写用例的成本太高了，尤其是测试同学来写集成用例，因为涉及到和被测系统的联动，比如识别测试标签，识别后可能会根据测试点需要做不同的处理，感觉很难落地，facebook在这块落地上有遇到什么困难，怎么解决的，可以详细说说么？

文中提到发布阶段的监控很重要，那老师之前说很多大公司的发布流程可以做到分钟级别，想咨询下他们的监控环节是怎么处理的？按理说这么短的时间也监控不到有效的信息，比如监控的波形图也不会有明显的变化

这篇是这个专栏里的精品文章，写的很好，优秀。