灰度发布
| 文档状态 | [ ] 草稿 [ ] 正式发布 [ √ ]正在修改 |
|---|---|
| 文档版本号 | v1.1 |
| 文档密级 | 内部资料 |
| 归属部门 | 武汉极目未来数据科技有限公司 |
| 产品名 | 极目农业植保运营系统 |
| 子系统名 | 地面站 |
更新日志：
| 日期 | 版本 | 变更记录 | 作者 |
|---|---|---|---|
| 2018/05/30 | v1.0 | 编写初版 | 余明旭 |
| 2018/05/31 | v1.1 | 调整服务单实施流程 | 余明旭 |
| 2018/08/21 | v1.2 | 完善服务端、地面站实现流程 | 余明旭 |
| 2018/08/22 | v1.3 | 完善新增接口 | 余明旭 |
| 2018/08/22 | v1.4 | 1、灰度发布身份识别userId变更为IMEI 2、灰度版本直接由后台控制，无需告知用户 3、取消版本分布表创建 4、新增版本更新流程图 | 余明旭 |
一、定义
按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的反馈以及对新版本功能、性能、稳定性等指标进行评估，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。
二、目的
1）规避一定的发布风险，降低产品迭代升级所影响的范围。
2）根据反馈结果，做到查漏补缺
3）快速验证产品功能稳定性
4）发现重大问题，可回滚“旧版本”
三、实现步骤
3.1、定义目标
a. 产品一般都会有明确的产品目标，灰度发布的过程通常把产品关键数据走势是否有利于既定目标的达成作为进一步进行放量的重要参考，
b. 如果灰度产品在目标数值超过未灰度用户，且产品在性能指标方面趋于稳定，例如崩溃率控制在一个合理范围，用户访问速度也在预计范围，则考虑继续放量。
3.2、制订发布策略
包括用户规模、发布频率、功能覆盖度、风险评估与回滚策略、运营策略、新旧系统部署策略等。
简单说，就是我们要分几个批次进行用户覆盖，多长时间覆盖完成，每次间隔多长时间，评估每次发布有可能面临的风险。
如果产品发生重大问题，是否能迅速回滚到上一个版本。
3.3、选定用户
包括用户特征、用户数量、用户常用功能、用户范围等。
一般的灰度用户选择都是从本公司内测开始，其次是高级别高忠诚度的用户，然后是高活跃用户，最后再到普通用户。
3.4、系统部署
部署新系统、设定分流规则、运营数据分析、分流规则微调等。
这里的运营数据部署，建议进行实时数据统计与报表展示，便于及时观测产品数据变化，快速发现问题解决问题。
3.5、反馈收集与发布分析
用户行为分析报告、错误统计反馈情况等可形成下次灰度发布的功能改进列表。
用户的反馈，从产品自带的反馈提交获取，无论是哪个渠道，都要考量这些反馈建议的代表性。用户反馈建议的收集整理输出，每天至少一次，灰度期间的主要观测数据报告需按天发出。
3.6、产品迭代
灰度过程是推动产品快速优化的有效手段，产品经理必须客观的对待用户的反馈，分析产品目标数据、用户行为数据等，拿出合理的优化方案，推动优化开发，再进行下一轮灰度或者完整发布。
四、需求涉及流程
方案一.服务端控制
许针对部分用户推送升级通知甚至版本强制升级。
无论哪种方法都需要做好版本管理工作，分配特别的版本号以示区别。
当然，既然是做灰度，数据监控（常规数据、新特性数据、主要业务数据）
还有，灰度版最好有收回的能力，一般就是强制升级下一个正式版。
方案二.客服端+服务端控制
客户端在打包的时候，将A功能B功能都打进同一个版本的Apk包里，然后在代码层写控制显示逻辑。后台接口控制当前版本显示APK上的A/B版本的分布，可以做到指定一部分用户使用A功能，一部分用户使用B功能。
服务器端应该有相应的报表来显示A/B版本的数量和使用效果对比，根据实时数据体现，再由服务器端接口控制用户全部切换到A版本或者B版本。
五、实施流程
5.1、服务端实现
1）新增数据表
内测白名单表：在确定人员后会从后台获取相关人员信息，将userid、username、imei录入到白名单表中.。（人员组成包括测试人员、开发人员、内定协商用户三种角色。）
2）新增检查版本更新新接口
调用地址： /checkVersionV2/
接口用途： 带灰度发布版本获取检查接口
请求方式： GET
接口逻辑：
1）发送VersionCode、IMEI给服务端，服务端会进行记录这两个值
2）为白名单终端、开放了投放百分比 & 未满足投放配额，就进行灰度版本检查，不存在新版就进行正式版本检查
3）非白名单终端 -> 关闭了百分比投放、百分比投放->检查正式发布版本
请求参数：
| 字段名 | 字段类型 | 是否必填（Y/N） | 字段描述 |
|---|---|---|---|
| platform | String | Y | 平台（android,ios） |
| type | String | Y | 1 地面站 2测绘 3CRM |
| channel | String | Y | 发布渠道（eav） |
| versionCode | Number | Y | 版本号 |
| imei | String | Y | 国际移动设备识别码 |
正常输出结果：
{
"code": "000000",
"message": "有新版本，请更新",
"result": {
"apkSize": "18.9",
"publishTime": 1519825101000,
"downloadUrl": "http://whjm-test.oss-cn-beijing.aliyuncs.com/app-firmware/gs/5uno=",
"isForceUpdate": 1,
"versionCode": "200100000",
"updateDetail": "[修复] 任务详情接口添加参考边信息"
}
}
流程图：
4）完善后台apk提交界面
灰度投放规则如下：
1）当未开启百分比投放，只有白名单终端才能够更新到灰度版本
2）当开启百分比投放，白名单终端是直接进行灰度版本检查，非白名单用户投放百分比满额后将不再推送灰度版本
3）白名单用户个数包含在投放百分比里面，如果百分比配额优先达到投放配额，并不影响白名单用户的灰度版本获取。
5.2、客户端实现
1）地面站将版本检查更新接口提前至登录界面
2）当登录成功后，第一次进入主页面将不会再次请求版本检查接口
3）在已经登录的情况下，后面再次打开地面站将会直接进入主页面，这次将会进行版本检查
六、客户端灰度发布版本号变更规则
默认情况下版本变更：
1）版本号由9位数字组成
201005101
2_01_0051_01
主版本-次版本-小版本-灰度版本
灰度发布版本变更说明：
当前功能开发的版本为 v2.1.51，开发工作结束，需要发布第一个灰度版本
| 灰度次数 | VersionCode | VersionName | 通过 |
|---|---|---|---|
| 1 | 201005101 | v2.1.51_beta1 | false |
| 2 | 201005102 | v2.1.51_beta2 | false |
| 3 | 201005103 | v2.1.51_beta3 | true |
如上所示，灰度发布第三版本运行一段时间后，符合全量更新的指标，则在第三版的代码的中修改VersionName：v2.1.051_release，VersionCode不变，生成一个安装包，发布一个正式版本，供非内测用户下载使用。
| VersionCode | VersionName |
|---|---|
| 201005103 | v2.1.51_release |
七.总结
1.灰度发布必须做好版本管理，一旦错乱将导致一些版本无法回收更新。
2.数据的统计，收集，分析，没有一个好的数据平台就没有办法体现灰度发布所起到的作用，随之该功能就失去了意义。
