灰度发布
| 文档状态 | [ ] 草稿 [ ] 正式发布 [ √ ]正在修改 |
|---|---|
| 文档版本号 | v1.1 |
| 文档密级 | 内部资料 |
| 归属部门 | 武汉极目未来数据科技有限公司 |
| 产品名 | 极目农业植保运营系统 |
| 子系统名 | 地面站 |
更新日志：
| 日期 | 版本 | 变更记录 | 作者 |
|---|---|---|---|
| 2018/05/30 | v1.0 | 编写初版 | 余明旭 |
| 2018/05/31 | v1.1 | [调整] 5、实施流程 | 余明旭 |
一、定义
按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的反馈以及对新版本功能、性能、稳定性等指标进行评估，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。
二、目的
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）新增数据表
a. 内测白名单表：包含测试人员、开发人员、内定协商用户、用户主动申请成员名单
b. 内测成员表：包含内测白名单表中所有成员+投放百分比人员
2）修改接口
a. 获取用户信息接口：/getPersonInfo/ 返回值需新增 isTester字段(1:内测人员 0:非内测人员)，通过userId查询内测成员表获取。
3）新增接口
3.1 内测资格操作接口：1 申请 0 取消
a. 申请：客户端调用接口，传参 1 后台将userId加入内测白名单表
b. 取消：客户端调用接口，传参 0 发起后将userId从内测白名单表中删除，并将内测成员表中删除。为保证灰度阶段的测试百分比，一旦取消一个内测成员，将自动从总人员中随机抽取一个加入内测成员表。
3.2 新增接口：/checkVersionV2/ 不管服务端存在大于当前版本的发布版或测试版本，都将返回给客户端，由地面站根据用户信息表所有获取的isTester参数来判断是显示测试还是正式版本提示更新。
{
"code": "000000",
"message": "有新版本，请更新",
"result": {
"release": {
"apkSize": "18.9",
"publishTime": 1519825101000,
"downloadUrl": "http://whjm-test.oss-cn-beijing.aliyuncs.com/app-firmware/gs/5uno=",
"isForceUpdate": 1,
"versionCode": "200100000",
"updateDetail": "[修复] 任务详情接口添加参考边信息"
},
"beta": {
"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）投放用户10%，以地面站为例，因使用角色要求必须为飞手，总账户个数1000人，具有飞手角色用户500人，内测白名单成员数20人，计算公式如下：
设定百分比投放新增成员数=（有效角色总人数 * 投放百分比） - 内测白名单成员数
3）投放用户百分比变更：
增加： 增加人数 = (有效角色总人数 * 投放百分比) - 内测成员表总人数
减少： 减少人数 = 内测成员表人数 - （有效角色总人数 * 投放百分比），例如减少人数50人，随机从内测成员表中移除，过程不包含内测白名单中成员。
5.2、客户端：
1）登陆后请求用户信息表，获取isTester值
2）客户端新增版本回退UI（仅限回退上一个正式版本）
3）新增内测资格控制按钮（在开启内测资格给出弹窗，提示内测版本）
2）调用接口：/checkVersion/ 服务端将会返回release最新版本信息和beta最新版本信息
| 内测资格 | 存在新发布版 | 存在新测试版 | 提示 |
|---|---|---|---|
| true | true | true | 显示beta版本更新提示 |
| true | false | true | 显示beta版本更新提示 |
| true | false | false | 无提示 |
| false | true | true | 显示release版本更新提示 |
| false | false | true | 无提示 |
| false | false | false | 无提示 |
六、客户端灰度发布版本规则
默认情况下版本变更：
1）版本号由9位数字组成
201005101
2_01_0051_01
主版本-次版本-小版本-灰度版本
灰度发布版本变更说明：
当前功能开发的版本为 v2.1.51，开发工作结束，需要发布第一个灰度版本
| 灰度次数 | VersionCode | VersionName | 通过 |
|---|---|---|---|
| 1 | 201005101 | v2.1.51_1_beta | false |
| 2 | 201005102 | v2.1.51_2_beta | false |
| 3 | 201005103 | v2.1.51_3_beta | true |
如上所示，灰度发布第三版本运行一段时间后，符合全量更新的指标，则在第三版的代码的中修改VersionName：v2.1.051_release，VersionCode不变，生成一个安装包，发布一个正式版本，供非内测用户下载使用。
| VersionCode | VersionName |
|---|---|
| 201005103 | v2.1.51_release |
七.总结
1.灰度发布必须做好版本管理，一旦错乱将导致一些版本无法回收更新。
2.数据的统计，收集，分析，没有一个好的数据平台就没有办法体现灰度发布所起到的作用，随之该功能就失去了意义。
``
