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.客户端client及服务端server已存在稳定版本A，现准备发布灰度版本B，上线步骤：
1.QA部署版本Bserver端代码至灰度服务器
2.OP后台操作：

    (1)新增版本->填写版本B的信息：包括clientUrl, 班级白名单，分流服务ip+port
    (2)点击·上线 ·按钮，此时版本B client端状态为上线，且ip+port注册到分流服务

2.假设版本B灰度顺利，准备修改为全量上线
1.OP后台操作: 点击版本B的.全量.按钮，此时版本B类型变更为全量,删除白名单
2.QA部署代码至稳定版服务器集群
3.OP后台操作：点击版本B的.上线.按钮，此时删除分流服务中的ip+port映射，默认走default配置，即指向稳定服务器集群

3.假设版本B灰度不顺利，准备下线
1.OP后台操作：点击版本B的下线按钮，此时版本B状态变更下线，删除白名单，删除分流服务ip+port

七.总结
    1.灰度发布必须做好版本管理，一旦错乱将导致一些版本无法回收更新。

    2.数据的统计，收集，分析，没有一个好的数据平台就没有办法体现灰度发布所起到的作用，随之该功能就失去了意义。