iOS APP灰度发布方案

对于大项移动APP来说，每一次版本的发布，特别是在进行大的功能更新时，都需要选择部分用户先进行试用，并及时关注崩溃、卡顿、用户反馈等，等待各项业务指标都达到预期要求时，才能将新版本全量推向市场。灰度发布是移动产品稳定性的重要保障，它能解决以下问题：

常规测试很难覆盖到足够的机型，也无法搜集到足够多的测试数据。一旦常规测试没有发现一些隐蔽的致命bug，APP带着bug上线，后果不堪设想。灰度发布即是让部分用户参与到产品测试中来，一旦发现问题，可及时止损，将影响降低到最小。

高频服务新上线时，客户端和服务端都需要一个适应的过程，灰度发布能逐步放量，保证服务可控。

新上线的功能，当无法确定哪种方式更受用户欢迎或能带来更大的收益时，可以采取AB测试。而AB测试用灰度发布的方式再适合不过。

灰度发布要达到比较好的效果，需要设计一套优秀的灰度系统。它应该具备或部分具备以下几个特征：

灰度发布一般是和具体业务相关联的，业务需求可能会和用户的位置、年龄、机型、标签等相关，这就需要灰度系统在筛选灰度用户时，能够根据特定的条件获取最优的实验样本，以最短的时间获取最有价值的数据。

除了监控APP的崩溃、卡顿等性能问题外，还需要关心灰度的业务指标。特别是对于AB测试来说，如何区分两组测试哪一组更优，需要设计一个统一的计算方式。常见就是转化率指标，在灰度的业务路径中，应该事先进行数据埋点。

灰度发布虽然是一项测试行为，但发生大范围的崩溃或功能不可用问题，对用户的使用体验也是一种伤害。当出现问题时，应该能引导用户回滚或更新到正常版本。

对于Android和Web产品来说，因为可以自由的控制发布渠道，所以灰度方案相对容易。但对于iOS APP来说，受限于AppStore，灰度方案比较单一。在早几年91市场流行的时代，越狱用户的占比相对较高，有很多APP选择在越狱市场进行灰度，但越狱市场的问题在于很难获取有效的实验样本，灰度反馈的数据可能和实际情况有偏差，现在已基本不采用。

目前，iOS的灰度主要有两种方式：

在AppStoreConnect的后台，可以对APP进行分阶段的自动更新。该灰度机制将灰度分为七天，第一天发布1%的用户，第二天发布2%...第六天发布50%用户，最后一天发布到全量用户。灰度期间发现严重问题时，可以暂停并重新提交一个新的版本，也可以在灰度过程中提前开启全量。

这种灰度方案有两个问题：

TestFlight测试工具允许开发者通过邮件等方式邀请用户测试。TestFlight在被苹果收购之后，和AppStoreConnect进行了深入整合，现在，它可以生成一个公开的链接，用户可以直接安装测试。

在AppStoreConnect后台允许从开发者账户的开发、销售、管理成员中邀请少量的（25个）内测用户，内测用户不需要审核可直接安装灰度版本的APP。非常适合内部在发版前进行整体功能的验证测试。

在AppStoreConnect后台的TestFlight项新建并提交灰度版本审核通过后（和正式版本的审核不一样），可以生成基于TestFlight的公开链接，用户访问该链接后，即可安装灰度版本的APP。

很多iOS APP使用「内测邀请」实际上就是依赖于TestFlight的「外部测试」的能力。当用户打开现有版本的APP后，服务器可以根据当前用户的标签判断是否为灰度用户。如果是的话，需下发TestFlight的安装链接，APP端引导用户进入TestFlight安装。外部测试有一些限制条件：

可通过判断itms-beta scheme的方式判断用户是否已经安装TestFlight，如果用户符合版本、机型、位置等维度的逻辑条件，则可弹窗提示用户抢先体验。用户点击接受体验则跳转至TestFlight安装。用户不接受体验时，可回收邀请链接供其他用户使用。

这种情况下如果用户命中灰度条件，需要先引导用户下载TestFlight，后续流程是一样的。

原文地址：easeapi.com/blog/blog/1…