关于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.数据的统计,收集,分析,没有一个好的数据平台就没有办法体现灰度发布所起到的作用,随之该功能就失去了意义。



猜你喜欢

转载自blog.csdn.net/fdadala/article/details/79411750