关于App灰度发布方案

一. 灰度发布定义

灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。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.数据的统计，收集，分析，没有一个好的数据平台就没有办法体现灰度发布所起到的作用，随之该功能就失去了意义。