iOS APP灰度发布方案

灰度发布解决什么问题

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

• 常规测试的局限性

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

• 验证服务

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

• AB测试

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

灰度策略

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

人群筛选

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

数据反馈

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

及时止损

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

iOS的灰度方案

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

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

Phased Release for Automatic Updates

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

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

1. 已经升级到灰度版本的用户，没法回退；
2. 没法精准选择灰度用户。

TestFlight

TestFlight测试工具容许开发者经过邮件等方式邀请用户测试。TestFlight在被苹果收购以后，和AppStoreConnect进行了深刻整合，如今，它能够生成一个公开的连接，用户能够直接安装测试。

内部测试

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

外部测试

在AppStoreConnect后台的TestFlight项新建并提交灰度版本审核经过后（和正式版本的审核不同），能够生成基于TestFlight的公开连接，用户访问该连接后，便可安装灰度版本的APP。

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

• 用户需安装TestFlight（内部测试也同样）；
• 有效测试时间为60天（内部测试也同样），再有效期结束以前需引导用户更新正式版本；
• 外部测试用户能够达到最多10000。

最佳实践

• 已安装TestFlight

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

• 未安装TestFlight

这种状况下若是用户命中灰度条件，须要先引导用户下载TestFlight，后续流程是同样的。

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