如何优雅进行灰度发布测试？中国工商银行是这样实践的

分享中国工商银行软件开发中心项目组对于灰度发布的测试前移、静态测试、引流策略验证、回退方案验证等方面的测试实践。

作者：中国工商银行软件开发中心珠海开发四部

灰度发布（Gray Release），又名金丝雀发布，是从不发布，逐渐平滑过渡到正式发布的一种发布方式。在黑与白之间能够平滑过渡，得名灰度发布。灰度发布使新旧版本短期并存，新版本只向特定用户发布，产生的问题只影响部分用户，降低新版本上线风险。

如下图所示，通过引流策略将用户引流到灰度版本，可以有效控制爆炸半径，但增加了系统复杂度，需要考虑非灰度版本的兼容，服务连续性等，涉及到应用侧的灰度部署策略的制定和研发，需要开展针对性的测试，避免灰度发布引入新缺陷。

项目组开展灰度发布测试实践已近2年，取得一定实效，下面通过一个具体实例分享灰度发布测试经验。

项目组根据业务重要性、爆炸半径、部署频率确定灰度目标，经专家组评审后，制定灰度设计、实施方案。灰度发布测试主要是验证灰度设计、灰度实施方案是否满足灰度目标的要求，以及灰度方案对程序的改动不影响非灰版本功能。

1、开展测试前移工作

测试人员参与到灰度目标制定、灰度设计中，让灰度相关策略用最小修改成本试出最多缺陷。

（1）分析灰度目标

项目组制定灰度目标，主要包括灰度部署策略，持续交付策略的确定。具体策略制定如下图，✅ 为选取的策略。

灰度部署策略：主要有物理灰度和逻辑开关两种方式，物理灰度是物理隔离，逻辑开关通过代码增加开关实现。物理灰度安全性高于逻辑开关，但实现难度较大，宜采用物理灰度和逻辑开关结合方式，具体说明如下。

服务节点通过分布式框架自定义路由可实现物理灰度，修改路由控制即可，较简单，可实现物理灰度。但物理灰度可能无法兼容上下游不同的灰度策略，可同时实现逻辑开关。

批量节点、消息节点、大型机所在框架无法支持物理灰度，需自行修改程序，较复杂，选用逻辑开关方式。

数据库节点做物理隔离需数据同步，处理很复杂，可能涉及停机。支持物理灰度，需额外研发一个中间版本，采用逻辑开关方式。由于逻辑开关方式仅有一个数据库实例，表结构的变动涉及修改原分支功能，无法实现完整意义的灰度。

物理灰度节点部署范围：仅服务节点部署灰度节点。

物理灰度部署策略：为降低复杂度，采用单版本发布。要求服务节点旧版本的功能和其他节点新版本兼容，如不能兼容，则放弃物理灰度，仅使用逻辑开关。具体如下。

物理灰度版本发布范围：正式版本、补丁版本均按物理灰度发布。补丁版本的发布策略需根据正式版本所处阶段调整，具体如下。

正式版本阶段	补丁版本解决的问题	补丁版本安装策略
灰度试点	解决灰度试点问题	同正常版本。先安装灰度节点，后续和正式版本一同扩大试点，一同灰转正。
解决存量紧急问题	正式版本立刻灰转正，所有节点安装补丁版本。
解决存量非紧急问题	待灰转正后，所有节点安装补丁版本。
灰转正	/	所有节点安装补丁版本

物理灰度引流策略：使用多规则组合，白名单，渐进式方式引流。

持续交付自动化程度：根据持续交付工具的能力，尽可能自动化。

（2）分析灰度设计

灰度设计主要是引流策略的设计、服务端设计等。根据具体情况举例如下。

引流策略的设计：根据渠道和用户特征设计引流策略，匹配引流功能，避免灰度引流涉及重要客户。按分行、支行、柜员组合进行引流，根据灰度功能灵活配置，可逐步扩大引流范围。如，需要灰度登陆功能，在柜员未登陆的情况下，无法获取对应的支行，引流策略设置为按柜员引流；需要灰度跨支行调拨功能，调出支行在灰度，调入支行在非灰度，版本不兼容，设置为按分行引流。

客户端设计：根据客户端类型明确灰度版本推送下载方式。

服务端设计：通过参数配置灰度引流开关，灰度引流规则，支持灵活修改，实时生效。

数据库设计：根据具体修改评估是否可以物理灰度。

服务连续性设计：采用完全不停机方案，灰度在途功能可以闭环。

2、开展静态测试工作

主要包括整体灰度策略的静态验证和具体功能灰度的静态测试。

• 对整体灰度策略：
  

物理灰度节点与普通节点物理隔离，如，灰度节点采用独立的容器模板。

服务节点存在对应的灰度节点。服务节点按功能归类多个节点，非重要功能服务节点，不实现物理灰度。对于命名相似的节点，可采用工具检查，避免混淆。

• 对项目功能灰度：

从具体功能评估，是否需要灰度，是否可以灰度，以及具体的灰度策略。由于灰度策略限制，某个功能的修改会影响当期版本灰度策略。具体如下。

新增一套功能，新增表结构，不涉及相关通讯区改动，业务部门暂不开展相关业务，那么随正常版本开展灰度策略即可。

修改一套功能，涉及表结构修改，或者上下游通讯区修改，那么当期版本便无法灰度，其他需求如果需要灰度，考虑增加逻辑开关。

修改一套功能，影响比较小，不涉及表结构修改，或者上下游通讯区修改、消息推送等功能。不考虑灰度，随正常版本开展灰度策略即可。

3、开展测试执行工作

测试执行工作主要针对灰度实施开展。灰度实施包括灰度试点、灰转正等，具体过程举例如下。

灰度测试执行工作主要是引流测试、灰转正测试、回退测试、以及非业务功能测试。

引流测试：针对灰度试点工作开展。验证引流规则，以及分流后的功能验证。单独验证重点保障业务对象，强制引流到非灰节点，不受灰度引流策略影响。全链路灰度验证涉及上下游灰度引流策略一致，避免灰度，非灰均报错的情况。

对于灰度试点功能，开发灰度引流测试工具，遍历引流规则并核对结果。灰度试点功能自动化脚本调用引流测试构件，轮询引流规则，根据灰度、非灰节点使用不同版本的断言，实现引流测试自动化核对。通过Jenkins例行调度运行自动化脚本，可快速验证引流策略和灰度试点功能。

对于存量功能，使用工具将存量功能生产日志在灰度、非灰分别运行回放，比对两者结果一致。

灰转正测试：验证在不停机转正场景下，在途业务可以闭环。
回退测试：验证在途业务可闭环，且支持回切。
非业务功能测试：主要包括高可用测试，性能容量测试。

做好灰度发布的质量守护是一个长期的过程，需要我们时刻关注灰度发布的问题，发现改善点，及时提升。以上实践欢迎同仁参考交流。

还不过瘾？还想了解更多精彩？GOPS  2023 · 深圳站要来啦！

早鸟票限时限购中，扫码立刻解锁精彩~

近期好文：

“高效运维”公众号诚邀广大技术人员投稿

投稿邮箱：[e-mail]，或添加联系人微信：greatops1118。

点个“在看”，一年不宕机