Android开发规范：APP版本发布（全量发布、灰度发布）

顾名思义，全量发布就是一次性发布给所有用户使用。

已经安装app的用户打开app后会收到更新弹框，或者在app的关于里面也可以点击查看是否有升级提示，并且点击升级。

优点：

每个新版本只会有一次更新，也就是说不存在补丁版本，也不会让用户收到多次升级的打扰；

新版本app经过多轮测试，质量一般会有保障；

省去了发布多个补丁包在人力和流程上的消耗；

缺点：

因为只会发布一个版本，所以对app的质量把控要求高，需要测试团队这边严格把控，一般要3轮甚至更多的测试，扩大测试范围，保证app不出现重大bug影响使用；
除了新版本功能外，还需要保证主路径功能没问题，另外还有手机兼容性、app旧版本和新版本互通、app旧版本升级等需要测试。

存在重大bug的风险，比如导致app崩溃。这样没有版本就需要再次发版解决。
笔者甚至遇到过发版后客户端https证书过期从而导致app不可使用的问题，这个时候只能重新发版。

适用范围：

app更新频度不高，比如几个月甚至半年以上更新一个版本的。一般在传统行业中比较常见。
灰度发布

灰色是介于黑色和白色之间的一种颜色，引申到app版本发布上面来可以理解为在正式版本发布之前的一个版本。

灰度版本的作用是用来验证新版本是否有重大bug或者严重影响用户体验的问题。

理想状态是发布一个灰度版本v1后没有任何问题，那么就可以将这个灰度版本v1作为正式版本全量发布；

如果这个灰度版本v1存在问题，那么需要开发人员进行修复，还要经过测试，然后再发布一个灰度版本v2，然后再观察这个v2版本是否有什么问题。如果有问题仍然需要再发布一个v3版本，甚至更多。

AB Test

灰度发布这种思路其实是跟AB Test解决方案一样。让大部分用户使用A版本，然后让一小部分用户开始使用B版本，观察B版本用户的反应，如果B版本用户没什么反应，那么就逐步地让A版本用户过渡到B版本。AB Test可以保证系统的稳定性，如果有什么问题可以立即解决。

灰度策略

灰度数量
需要根据用户体量来决定，也可以根据产品需求来决定。一般可以投放10%的量来观察。量太小了数据统计会有影响，比如发现某个崩溃可能就是灰度的几台特殊机器，从而导致崩溃率上升；如果全量后这个崩溃率反而会降低。

灰度目标
我们可以通过用户id、用户手机号、设备id的尾号来决定给哪些用户推送升级信息。一般不选择给某一个渠道的所有用户发送升级信息，因为这个渠道的用户数量不好控制，而且这个渠道包邮可能被别抓包拿走了影响数量统计。

需要注意的是如果有v2版本灰度包，那么选择灰度目标需要避开v1版本的灰度目标，避免导致v1版本的用户再次收到升级提示，影响用户体验。

回收功能
需要保证这些安装了有问题灰度包的用户，在最终能升级到稳定版本。如果不这样的话，会导致市面上一直存在有问题的版本，从而导致崩溃之类的一直存在，影响整体新版本的app数据统计。

一般采取的方法是服务器这边如果发现有存在问题的灰度版本发送的请求，则会通知客户端弹框，要求用户强制升级。

优点

1. 提前获得目标用户的使用反馈；
2. 根据反馈结果，做到查漏补缺；
3. 发现重大问题，可回滚“旧版本”，或再次发布修复后的灰度版本
4. 补充完善产品不足；
5. 快速验证产品的 idea。
6. 小步快跑，迅速开发，迅速测试，发现问题（bug或用户反馈）立马改进，然后继续发布灰度包观察用户使用数据；

缺点：

如果灰度版本较多，那么势必会消耗不少开发和测试的人力。因为每发布一个灰度版本，至少主功能路径之类的需要过一遍。而且还有各种公司内部的发版流程、邮件，也是一种消耗。

灰度版本到正式版本中间会有一段时间间隔，如果灰度版本存在问题，那么这个灰度用户只能一直等到正式版本的发布。

灰度流程：

相关解释：

• 选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
• 筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
• 部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
• 发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表

【某宝的案例.来源网络】

产品需求收集和确定 –>； 技术方案出具和分工协调 –>； 开发编码 –>； 内部服务器环境的测试 –>； 联调（又名预发环境） –>； 小淘宝环境发布，内部员工喷喷喷 –>； 小流量（具体有多少取决于业务影响面）公网测试 –>； 收集数据写反馈 –>； 全量上线。

3、灰度发布的方式方法有哪些？

产品Q群、产品微信群、内部用户、app自升级、换量渠道、不会被抓包的小市场，在这些渠道将灰度包放还出去。这里边可控度最强的当属app自升级了。根据时间段，用户版本，升级请求数量，实际升级数等等

4、灰度发布三大类型？

1. web页面灰度：按照ip或者用户id切流啊。具有随机性，可以控制比例
2. 服务端灰度：考验主系分能力了，可以做逻辑切换开关，按照义务相关属性逐渐切流
3. 客户端灰度：一般按照用户逐渐推送包，主要是PC端(WIN，MAC)、移动端（安卓，OS）内部大规模内测

5、灰度发布时，目标用户选取策略？

即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。

对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，最好能够提供让用户自主回滚至旧版本的渠道。

对于客户端应用，可以考虑类似Chrome的多channel升级策略，让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。

6、A/B测试云服务提供商

海外应用：optimizely

国内应用：AppAdhoc（简单够用）、optimizely（相当强大，尤其在native app A/B测试这块）

7、延伸阅读：

2015年5月31日，马化腾在香港大学李兆基会议中心大礼堂举办了一场创业演讲，演讲中爆了一个大料：微信的诞生史。

微信在诞生之前，在腾讯内部有三个团队在同时做微信，主要竞争者为张小龙的e-mail团队和手机QQ团队。做这个产品之前，腾讯内部并没有给这个产品定一个完整的基调，而是让公司内部形成一个激烈的竞争，通过观察用户对产品的喜好程度和产品的实际完成情况决定上线结果。

马化腾的灰度机制是这样的：很多公司在一开始做产品定义时，要么确定它是黑的，要么确定它是白的。但是马化腾发现，互联网产品的定义是有用户投票决定的。在一开始，我们不定义它是黑，还是白，有一个灰度的周期。在这个灰度周期里，让用户的口碑决定它是生是死，是白还是黑。

说的再直接点，这也是马化腾创新上的灰度机制：容忍失败，允许适度浪费，鼓励内部竞争内部试错。马化腾说过，在产品研发过程中，我们还会有一个困惑：自己做的这个产品万一失败了怎么办?

在面对创新的问题上，要允许适度的浪费。怎么理解？

就是在资源许可的前提下，即使有一两个团队同时研发一款产品也是可以接受的，只要你认为这个项目是你在战略上必须做的。

很多人都看到了微信的成功，但大家不知道，其实在腾讯内部，先后有几个团队都在同时研发基于手机的通讯软件，每个团队的设计理念和实现方式都不一样，最后微信受到了更多用户的青睐。

你能说这是资源的浪费吗？我认为不是，没有竞争就意味着创新的死亡。即使最后有的团队在竞争中失败，但它依然是激发成功者灵感的源泉，可以把它理解为内部试错。

具体内容，请参考：《马化腾致信合作伙伴：灰度法则的七个维度》

1. 需求度：用户需求是产品核心，产品对需求的体现程度，就是企业被生态所需要的程度；
2. 速度：快速实现单点突破，角度、锐度尤其是速度，是产品在生态中存在发展的根本；
3. 灵活度：敏捷企业、快速迭代产品的关键是主动变化，主动变化比应变能力更重要；
4. 冗余度：容忍失败，允许适度浪费，鼓励内部竞争内部试错，不尝试失败就没有成功；
5. 开放协作度：最大程度地扩展协作，互联网很多恶性竞争都可以转向协作型创新；
6. 进化度：构建生物型组织，让企业组织本身在无控过程中拥有自进化、自组织能力；
7. 创新度：创新并非刻意为之，而是充满可能性、多样性的生物型组织的必然产物。