主要参考了：
一、概述
所谓的灰度发布，在行业内叫做A/B Test，所以可以搜索一些这方面的关键词
下面是某公司的灰度发布流程，仅供参考。
一）经典总结1：
1）web页面灰度。按照ip或者用户id切流啊。具有随机性，可以控制比例
2）服务端灰度。考验主系分能力了，可以做逻辑切换开关，按照义务相关属性逐渐切流
3）app。一般按照用户逐渐推送包，主要是安卓。iso内部大规模内测
没有不能灰度的业务，只有不能灰度的设计
作者：无名气
链接：https://www.zhihu.com/question/28296375/answer/61894553
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
2）经典总结2：
web 区分区域、时间端、人群做灰度
iOS 对比模块同时存在，云端控制模块的关闭和开启
Android，云端控制升级弹窗
PC client 粉丝群、论坛、不同的下发渠道做灰度
二、安卓很适合做灰度发布
1）从服务器端下手
Android平台做灰度再合适不过了。
找单一渠道投放特别版本出去是一个思路。另一个是做升级平台的改造，允许针对部分用户推送升级通知甚至版本强制升级。
无论哪种方法都需要做好版本管理工作，分配特别的版本号以示区别。
当然，既然是做灰度，数据监控（常规数据、新特性数据、主要业务数据）还是要做到位，该打的数据桩要打。
还有，灰度版最好有收回的能力，一般就是强制升级下一个正式版。
作者：张瑞
链接：https://www.zhihu.com/question/21714205/answer/19080164
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
2）从客户端下手
自己做产品时也有类似的需求，下边是我的方案:)
基本的逻辑是两个版本的代码都打到app包里，然后在app端植入测试框架，用来控制显示哪个版本。
测试框架负责与服务器端api通信，由服务器端控制app上A/B版本的分布，可以实现指定的一组用户看到A版本，其它用户看到B版本。
服务端会有相应的报表来显示A/B版本的数量和效果对比。
最后可以由服务端的后台来控制，全部用户在线切换到A或者B版本~
所以这个也可以用来做灰度发布 :)
另外由于打进去两个版本的代码，app的包体积会大一点(这和功能变化多少有关)
作者：且歌
链接：https://www.zhihu.com/question/21714205/answer/19080265
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
3）典型案例
MIUI的控制上，存在体验版、开发版、正式版三个版本。
包括Chrome也有canary、dev、stable三个版本。
对于Android应用，可以使用Google的分阶段发布。
Google开发者后台可以设置灰度发布的百分比，5%，10%，20%，50%，100%。
4）应该有完善的工具可以看到各种统计分析的数据，比如淘宝就有；
三、iOS版本不好做灰度发布
iOS上只能好好测试了，或者发布越狱版本（但越狱版本有时候本身也是一种问题）
iOS比较麻烦，由于审核机制以及iOS本身对权限的控制，我们通常是选择越狱版本渠道来进行灰度，然后才是正式版本灰度。
iOS：官方的测试平台有Testflight，已经被苹果收购，但是整个内测用户邀请的方法流程还是没有打通，邀请用户成本比较高，是通过添加用户邮箱的方式，收到邀请邮件后还需要用户按步骤下载tf，下载应用等，没有一套教学视频普通用户还是难以接受。但非常适合在新产品发布前使用一些运营手段去建立这个用户群。用户一旦完成第一次操作，以后更新就像appstore一样简单。对开发者来说，操作也是和appstore一样的。比较方便。
且一个公司有多款产品的话，使用这个成本也会稍低一些，不过最大的问题还是灰度的用户量，和后期用户的消亡管理和扩充
还有一个是如果有打不同的iOS渠道包（除了appstore还有其他越狱渠道）或者其他tag的话，也可以通过升级配置来指定灰度发布。
作者：AlwaysAT
链接：https://www.zhihu.com/question/28296375/answer/61898109
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。