全量发布与灰度发布（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数据统计。
一般采取的方法是服务器这边如果发现有存在问题的灰度版本发送的请求，则会通知客户端弹框，要求用户强制升级。

优点：

小步快跑，迅速开发，迅速测试，发现问题（bug或用户反馈）立马改进，然后继续发布灰度包观察用户使用数据
不必担心灰度版本出问题，因为可以再次发布修复后的灰度版本

缺点：

如果灰度版本较多，那么势必会消耗不少开发和测试的人力。因为每发布一个灰度版本，至少主功能路径之类的需要过一遍。而且还有各种公司内部的发版流程、邮件，也是一种消耗
灰度版本到正式版本中间会有一段时间间隔，如果灰度版本存在问题，那么这个灰度用户只能一直等到正式版本的发布

适用范围：

app更新频率高，一般一个月甚至2-3周就有一个版本发布。一般互联网行业的app常用这种方式

————————————————
原文链接：https://blog.csdn.net/ddnosh/article/details/100091866