iOS APP灰度发布方案

Posted 2021-04-18 我的IT笔记

对于大项移动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，后续流程是一样的。

企业包

iOS的企业包类似于自建发布渠道，自由度更高，但一般也仅用来企业内部应用，不适合直接用于外部用户（涉及到更换包名等更复杂的问题），这种方案用的比较少。

UPDATE

iOS TestFlight的局限性及改进

转载自 https://easeapi.com/blog/blog/116-ios-app-beta.html