轻量化的灰度发布实践技术方案

前段时间业务组负责人提出因为合规原因，一个功能模块需要在 App 实现灰度发布，具体来讲就是要在不同的地域和用户等级开展差异化的活动内容展示。利用这个契机恶补了一些“灰度发布”相关的知识，顺势将其中有价值的一些内容梳理与大家进行分享。

什么是灰度？

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

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

​

灰度发布和 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 进行全回归测试；

• 小程序业务功能开发可以高度并行；

• 灰度发布粒度更细致（例如一个小程序是可以仅在测试白名单的范围内试点）。

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