一. 灰度发布定义
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面 来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
二. 灰度发布的作用
1.及早获得用户的意见反馈，完善产品功能，提升产品质量
2.让用户参与产品测试，加强与用户互动
3.降低产品升级所影响的用户范围
4.规避一定的发布风险
5.避免停服发布给用户带来不便
6.具有容灾能力
三.具体的实现步骤
1）、定义目标
2）、选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
3）、筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
4）、部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
5）、发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
6）、产品完善
7）、新一轮灰度发布或完整发布
四.需求涉及流程
方案一.服务端控制
许针对部分用户推送升级通知甚至版本强制升级。
无论哪种方法都需要做好版本管理工作，分配特别的版本号以示区别。
当然，既然是做灰度，数据监控（常规数据、新特性数据、主要业务数据）还是要做到位，该打的数据桩要打。
还有，灰度版最好有收回的能力，一般就是强制升级下一个正式版。
方案二.客服端+服务端控制
客户端在打包的时候，将A功能B功能都打进同一个版本的Apk包里，然后在代码层写控制显示逻辑。后台接口控制当前版本显示APK上的A/B版本的分布，可以做到指定一部分用户使用A功能，一部分用户使用B功能。
服务器端应该有相应的报表来显示A/B版本的数量和使用效果对比，根据实时数据体现，再由服务器端接口控制用户全部切换到A版本或者B版本。
五.具体操作流程。
一.根据MallId进行更新
服务端：
服务端插入规则，指定mallId和版本号，最新稳定版本号（万一发生重大bug的备用版本），是否强制更新
客户端：
检测：使用mallId传到服务器，提示升级（并非强制），
监测：使用友盟和bugly监测效果（数据统计平台必须完善）
回滚：如果效果不好，修改服务端规则，进行强制更新，客户端再次进入的时候，需要把当前的版本号和MallId传上去，进行强制更新即可
二.设备Id（尾号是2的去更新），当前的版本号，规则和上面一样
三.根据不同的发布渠道进行更新
六.总结
1.灰度发布必须做好版本管理，一旦错乱将导致一些版本无法回收更新。2.数据的统计，收集，分析，没有一个好的数据平台就没有办法体现灰度发布所起到的作用，随之该功能就失去了意义。