灰度发布和AB Test有什么关系？

由于工作需要，近期又恶补了一下“灰度发布”的相关知识，也和身边小伙伴探讨了轻量化实现灰度发布的落地方案。借此机会，正好将相关内容跟大家整理分享一下。

什么是灰度？

要想了解这个问题就要先明白什么是灰度。灰度从字面意思理解就是存在于黑与白之间的一个平滑过渡的区域，所以说对于互联网产品来说，上线和未上线就是黑与白之分，而实现未上线功能平稳过渡的一种方式就叫做灰度发布。

灰度发布又叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。

灰度发布和 AB Test 的区别

和大部分人一样，我个人之前对灰度发布和 AB Test 存在一定的混淆，认为就是换了一种说法，但实际调研发现两者之间存在着本质上的区别。

1、AB Test

AB测试一般由产品经理和运营来主导。它是把两种功能，或者两个版本，交给相同的用户来使用，看用户喜欢哪种功能。

要点是，AB的两种功能都是可用的， 投放的用户群体无差别，让用户选择更受欢迎的功能，后期可能是A上线，也可能是B上线。

2、灰度发布

灰度测试一般由研发，测试或运维来主导。它是把系统的新版本，或者说新功能，以部分上线的方法来上线，验证新版本是否足够可靠。

关键要点是，灰度版本未必是可用的，或者说没有严重bug的，投放的客户群体可能只是北上广深等一线城市的用户，由监控确定是否有问题，后续可能会继续放量上线。

灰度发布的优势

1、提前获得使用反馈，缩减风险影响范围

因为灰度发布可以通过地域、性别、用户等级、使用客户端等一系列的策略条件对目标用户群进行筛选，所以可以保证验证版本影响的用户在最小可接受的范围内。此外，基于验证版本提前收集用户使用意见，及时完善产品功能，并且根据用户和监控的反馈结果，做到查漏补缺，对于过程中发现的重大问题，甚至可以及时的回滚至“旧版本”。

2、自定义规则引擎，精准控制内容投放

此外灰度发布可以作为一个自定义的规则引擎，可按地域、人群、时段等自定义标签对 App 模块或者 Web 页面进行内容的精准投放，满足企业产品的精准化投放发布需要。就像是我们业务组负责人提出的需求，把新上线的活动仅投放给北上广深四个一线城市的高等级用户。

灰度发布方案分析

1、TestFlight

对于 iOS 开发者来讲有一个较为方便的灰度测试方案，也是大家使用最多的 —— TestFlight。TestFlight测试工具允许开发者通过邮件等方式邀请用户测试。TestFlight 在被苹果收购之后，和 AppStoreConnect 进行了深入整合，现在，它可以生成一个公开的链接，用户可以直接安装测试。

当用户打开现有版本的 App 后，服务器可以根据当前用户的标签判断是否为灰度用户。如果是的话，需下发TestFlight 的安装链接，App 端引导用户进入TestFlight 安装。

但 TestFlight 也有一定的不足：

• 用户必须安装 TestFlight ；
• 有效测试时间为60天，在有效期结束之前需引导用户更新正式版本；
• 测试用户可以达到最多10000。

2、功能小程序化

第二种对于很多开发者来讲可能比较陌生，起因是因为公司的 App 较为臃肿，迭代发版非常麻烦，希望功能模块互相解耦实现模块化开发，各业务模块间互不影响，所以计划集成 FinClip SDK ，让整个 App 具备小程序的运行能力，继而把 App 之前的业务功能都小程序化，通过管理后台去实现动态更新与发布。

刚好在进行技术体验时发现，FinClip 的小程序是借助部署的 FinClip 管理后台实现上下架，上下架的同时可以进行上架规则的制定。这样一来，相当于有了一个自定义的灰度发布引擎去自由配置地域、性别、用户等级等自定义条件，不需要编写任何复杂的应用逻辑代码，完成上下架的同时就完成了精准的上线发布。

相对于 TestFlight ，这种方式的优势在于：

• 不仅可以用在iOS系统中，Android 和桌面端应用也能集成 FinClip SDK ，相当于灰度测试覆盖的范围更加广；
• 自身的迭代升级，不会影响到宿主 App 运行的稳定性，也无需对 App 进行全回归测试；
• 小程序业务功能开发可以高度并行；
• 灰度发布粒度更细致（例如一个小程序是可以仅在测试白名单的范围内试点）。

由于时间有限，所以我认为较好用的轻量化灰度发布方案就暂时罗列这两类，当然方案有千千万，选择自己合适的就好。