一、灰度发布（百度百科解释）
灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。
今天被人询问灰度发布，ios上面支不支持灰度发布。一时懵逼，因为之前虽然听过类似的名词，但没有真正查找做过，这一次尴尬自然不能有下一次了。
经了解，App Store发布App产品除了传统的手动发布，自动发布外，还有一个分阶段发布，这个分阶段发布就是灰度发布，
登录 itunes 后台，你就可以看到在应用版本号的最下方，有“Phased Release for Automatic Updates” 选择项。
这个 Phased Release for Automatic Updates，就是苹果提供的灰度机制，只是苹果把这个叫做自动更新的分阶段发布。该灰度发布机制将灰度分为七天，七天共七个阶段。第一天发布 1%的用户，第二天发布 2%，之后快速上升，第六天发布 50%用户，最后一天发布到所有用户。
二、苹果的分阶段发布特点
1，分阶段时间为7天，第七天对全部人群发布，已打开自动更新的 iOS 用户；
2，在分阶段发布期间每天完成自动更新的用户的百分比将显示在iTunes Connect中
3，所有老用户仍然可以直接从App Store手动更新应用，而新客户将始终看到最新版本。用户就是不在当天分阶段发布之列，仍然可以手动更新当前版本
4，如果发现版本更新中发现有问题，可以随时暂停分阶段发布，总共最多30天，而不管暂停次数。版本更新暂停超过30天后，发布将在暂停的那一天恢复，将无法再次暂停发行。
5，分阶段发布不能选择特定的人群（如年龄、性别，领域或设备信息，如操作系统版本或设备类型），为随机选择。
6，在分阶段发布期间，开启自动更新的用户完成自动更新，用户不会受到通知。用户自身不知在体验灰度版本，没有相关机制提示
三、自动更新的分阶段发布的利弊
利：
1，发现新问题，可及时暂停分阶段发布，将损失降到最低。
2，加速产品的发布进程，减少测试周期。
弊：
1，只能选择老用户更新时的灰度，也就是说新用户安装的都是新版。
2，在群体的选择上是随机的，抽到的用户不能代表全局用户特征，统计误差不定，有可能很大，也有可能很小。
3，灰度发布的新版本一旦出现问题是无法回滚的，在修复版开发完成重新发布审核上架之前，已经更新的用户只能继续用bug版本。
4，只能做较大的灰度测试，无法针对功能较小模块甚至代码片段做灰度。
四、针对性实现灰度发布策略
针对以上出现的弊端，又想用灰度发布机制，有人想到结合TestFlight测试版本发布安装机制，做一款属于“内测”版本的灰度发布，发布之后根据运行情况，该TestFlight版本是有bug暂停，还是直接转App Store正式发布，是一个不错的选择。
TestFlight 的限制和特点：
1，需要运行在 iOS8 及以上版本的设备上
2，需要安装 TestFlight App
3，有效时间（90天）
4，测试人员有最大上限（最多10000）
5，TestFlight版本，可以提交反馈
6，TestFlight版本，需要审核（1天左右）
7，TestFlight版本，可以生成公开链接，并且可以修改公开链接用于安装（https://testflight.apple.com/join/xxxxxx），安装链接（itms-beta://testflight.apple.com/join/xxxxxx）
整体灰度发布的逻辑思路
该流程特点
1，可以根据用户id判断用户是否满足我们要发布版本的对象用户
2，需要判断用户手机是否安装testflight，否则无法安装testflight测试版本
该灰度发布实现完全没有使用到苹果官方提供的分阶段发布，而是结合testflight测试版本来实现的。10000安装使用数量，一定程度上已经足以满足版本的各种测试。
该策略实现的灰度发布，也有些弊端。比如，安装testflight测试版本出现问题，也无法版本回滚，只有在发布新的更正版本后才能避免bug。但是在声名“内测”版本，并且安装用户数量在10000以内情况，这种更具有针对性的灰度发布还是很有优势的。
五、除了灰度发布之外其他有名发布或者部署策略
冰冻三尺非一日之寒，单单知道灰度发布并不足以我下次被询问时一定不会“尴尬”。
1，蓝绿部署
蓝绿部署，是指同时运行两个版本的应用。一般应用后台服务端，还得是做负载均衡的后台应用。新版本发布后，老版本不会立刻关闭，而是会同时运行一段时间，等新版本的后台应用运行稳定后老版本关闭。
使用蓝绿部署，硬件需求很高，使用蓝绿部署的硬件至少是日常所需的两倍。
2，滚动发布
滚动升级，就是在升级过程中，并不一下子启动所有新版本，是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成，这样的话，如果日常需要10台服务器，那么升级过程中也就只需要11台就行了。
但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。
遇到，记录，分享~~
喜欢的点个赞，大神路过要指点的，欢迎下方留言！
相关参考链接
1，https://itunespartner.apple.com/en/apps/faq/Managing%20Your%20Apps_Submission%20Process
