之前参加一个线下分享和朋友交流，才知道有些同行不知道苹果官方有提供灰度发布的机制，所以今天给大家介绍一下这个机制。
如果你登录 itunes 后台，你就可以看到在应用版本号的最下方，有“Phased Release for Automatic Updates” 一项。如下图：
这个 Phased Release for Automatic Updates，就是苹果提供的灰度机制，只是苹果把这个叫做自动更新的分阶段发布。点击上图中的 “Learn More"，你可以看到这个功能的详细说明。
该灰度发布机制将灰度分为七天，七天共七个阶段。第一天发布 1%的用户，第二天发布 2%，之后快速上升，第六天发布 50%用户，最后一天发布到所有用户。具体的进度表格如下：
当你在灰度发布时发现严重的 Bug 怎么办？别着急，苹果允许你暂停当前的版本发布。按官方的文档描述，你可以在灰度开始后的 30 天内无限次暂停发布。暂停发布之后，你可以选择提交一个新的版本来修复这个 Bug。
但是，需要注意的是，已经升级到你的灰度版本的用户，是无法让他回退应用版本的。具体为什么，大家可以想想。我觉得很可能是因为很难保证应用回退时数据是兼容的。这也是为什么 iOS 的备份也不能降低恢复到低版本中的原因。
觉得 7 天灰度太慢？没关系，苹果也考虑到了这一点。你可以在灰度阶段的任何时候，选择直接 100% 发布。这样你可以提前结束掉灰度的过程。
官方文档：https://itunespartner.apple.com/en/apps/faq/Managing%20Your%20Apps_Submission%20Process
我们仔细研究了文档以后发现这次的所谓的“自动更新的分阶段发布”就是某种程度上的灰度发布。如果发现版本更新存在问题，可随时暂停分阶段发布。分阶段发布累计最多可暂停 30 天，暂停次数不限。这样做可以加速产品的发布进程，同时降低新版本发现致命BUG的影响。在运营层面，经常很多产品好不容易混到了苹果的推荐位，每天带量几万到十几万，总榜分类榜都借助推荐位维持一个较高的榜位。但是，产品更新的时候一个类似闪退的BUG，导致苹果不得不把产品从推荐位拉下来，以后再上推荐位变得极难，损失巨大。今后这个情况可以得到一定程度的缓解。看上去确实很美，不过仔细一想好像又觉得是不是差了些什么：
— 只能选择老用户更新时的灰度，也就是说新用户安装的都是新版，一旦有bug就是100%命中！
— 在群户群体的选择上是随机的，抽到的用户不能代表全局用户特征，统计误差也许很大、也许很小，谁知道呢？碰运气！
— App Store灰度发布的新版本一旦出现问题是无法回滚的，在修复版开发完成重新发布审核上架之前，已经更新的用户只能继续用bug版本！
— 只能针对大版本的做灰度，而无法针对功能模块甚至代码片段做灰度。
那么，一个更加完善的“分阶段发布”应该是什么样的呢？
— 应该是支持定向受众的，可以根据具体的场景选择在全体用户中灰度发布还是仅针对新用户或者仅针对0以下用户或者iPad用户等，还支持自定义用户标签（比如“付费用户”、“VIP用户”），更可以进行组合筛选，比只能选择老客户有更大的自由度，适合更加复杂多变的具体业务场景；
— 应该是能够科学分流保证代表性的。在用户分组过程中采取多维度动态均衡的专利技术保障选择的样本（比如10%的新用户）和总体样本（所有新用户）在iOS类型、OS版本、浏览器类型、浏览器版本、系统语言、设备类型、设备名称、屏幕宽度、屏幕高度、应用版本、SDK版本等多重维度下都保持一致，绝不碰运气；
— 应该是可回滚可控制的。一旦出现BUG等互联网产品灾难，可以关掉灰度中的新版，所有用户回旧版。甚至可以不着急修复，先分析原因以便下次迭代优化。App Store只是可以让BUG影响面积减小，却无法把受影响的这部分用户从BUG中解救出来，治标不治本；
— 应该是支持不同模块的灰度，并且可以在一次App发版中包含一系列多个小的灰度发布，甚至和具体指标挂钩，比如：提升性能对服务器压力有多大；比如新功能对用户周留存是否有提升等。然后根据这些小的灰度发布的结果来决定发布哪些功能，回滚哪些功能，而且这些都不用发布新版。
其实Google Play早就提供类似灰度发布的功能，但是却始终没什么人用。除了国内的特殊情况之外，广大的国外开发者产品经理还是基于上述的原因选择其他的方案。各位国内开发者怎么办呢？不用急，广告时间到！
http://www.appadhoc.com/blog/tag/灰度发布/
