从敏捷测试的角度理解灰度发布

Posted 2022-03-22 软件质量报道

如今，在软件持续交付流水线中，软件灰度发布的应用越来越广泛，不仅是互联网应用，移动App，智能手机，还包括智能物联网设备等嵌入式系统的迭代升级。今天我们从敏捷测试的角度来认识灰度发布的意义。

    很多人认为灰度发布就是金丝雀发布，其实有些区别。先说一下什么叫金丝雀发布（canary deployment or canary release），这个名字来源于17世纪的英国，矿井中会产生一种有害气体“瓦斯”，经常引起矿工中毒，造成人员伤亡。而工人们发现，金丝雀对瓦斯气体十分敏感，在人体还没有察觉时，金丝雀就会中毒身亡。于是，矿工们每次下井时都带上一只金丝雀，一旦金丝雀中毒，矿工就会知道井下有毒气，立即返回地面。“金丝雀”发布是指把新的软件版本先行发布给一小部分用户使用的一种方式。如果发现问题，就不会让更多用户升级使用新的版本，从而避免对更多用户的影响和伤害。这一小部分用户就相当于试错的金丝雀。

灰度发布是将发布分成不同的阶段， 先把新版本发布给一小部分用户先行使用，这时可以称为金丝雀发布，而如果新版本在一定时间内没有发现问题，就逐渐扩大发布范围，直至覆盖所有的用户。因此，灰度发布可以认为是在金丝雀发布基础上的扩展。整个过程相当于在旧版和新版之间（黑白之间）平滑过渡的一种发布方式。

灰度发布是支持软件低风险发布的一种方法，其它方法还包括蓝绿部署、滚动部署以及暗部署。采用灰度发布的目的是，如果新的软件版本出现问题，可以将对客户的伤害控制在局部范围内。

灰度发布有两种实现方式，一种是开关隔离方式，即在代码中为新功能设置开关，将软件的新版本部署到生产环境中的所有节点，通过代码中设置的开关针对不同范围的用户逐渐开放新功能，一旦出现问题，就马上关闭开关，下线新功能；第二种是通过滚动部署的方式，将新版本部署到生产环境中的一部分节点上，当确认没有风险后，再逐渐部署到更多的节点上。当灰度发布时在当前阶段发现问题，可以及时通过回滚机制，将软件版本回滚到上一个稳定的版本，这样就可以把对用户的影响降至最低。

常见的灰度发布方式按照端来区分，可以分为Web前端、服务端、客户端灰度

Web前端灰度将新版本随机的发布给一定比例的用户使用，当用户首次命中新版本时，需要把用户ID和版本号的映射关系存储起来，保证同一个用户上次请求和下次请求访问到的都是同样的前端版本；

服务端灰度又分为兼容变更灰度和不兼容变更灰度，当服务端更改了功能，不影响前端使用时，服务端可以单独发布，称之为兼容变更。如果服务端的变更影响到前端，如接口逻辑发生变化，需要前后端同时发布，为不兼容变更。兼容变更灰度又分为物理灰度和逻辑灰度（特性开关）的方式，不兼容变更灰度采用新旧版本号并存的方式。在微服务架构中，网关是负责请求的统一入口，主要功能之一是请求路由，因此可以利用网关实现让指定用户路由到指定版本的服务上。

客户端灰度包括的客户端有PC端(Windows，Mac)、移动端（安卓，ios）等，客户端升级采取提醒的方式建议用户进行升级，是否升级主动权在用户手中。

在确定灰度流量分配策略时，可以按照三种方式来划分。

第一种是按流量百分比划分，以先到先得的方式，先访问网站的用户优先升级到新版本，直到达到这一阶段事先定义的用户量，然后逐级扩大用户量；

第二种是按人群划分，根据用户画像，选择特定地域、性别、年龄的用户，或者按照用户活跃程度划分人群进行逐步升级；

第三种是按渠道划分，发布到不同应用市场的应用都会被打上渠道标签，所以可以根据渠道来区分用户。

以互联网企业的软件产品为代表的高频发布的需求，它们的软件产品往往每小时就要经历上千次的发布。有时是版本升级，更频繁的是缺陷修复。敏捷开发模式和DevOps的发展让各行各业的软件都以持续交付为目标，即使不像互联网企业那样频繁，一周或者两周一个迭代也成为常态。在持续交付流水线中，一方面需要提高开发的效率，消除开发过程中的瓶颈，这方面有很多实践，包括低代码开发、测试左移、持续集成、自动化测试、智能测试等。另一方面，测试周期的缩短和测试范围的减少不可避免地会造成测试不充分，有些严重缺陷在开发阶段没有发现。灰度发布和测试右移一样，目的都是降低已发布软件的风险。

在测试右移中还有一个重要实践，是A/B测试，实际是在灰度发布（Web前端和客户端灰度）的基础上进行用户体验测试。A/B测试通常应用在用户界面的用户体验测试当中，当一个软件应用变更了用户界面的设计，我们并不知道新的设计会带来怎样的市场效果，这时最好的做法是开展A/B测试：把新版本推送给一定比例的客户，通过对比实验进行科学的验证，从而判断这些变化是否产生了更积极、符合预期的影响力，为下一步的决策或改进提供依据。A/B测试的目的是帮助企业提升产品的用户体验，实现客户增长或者收入增加等经营目标。

A/B测试可以看作是UXE中关注质量的一个典型活动。我们先来看看其中一个小的改动带来明显效果的例子，以帮助你理解什么是A/B测试。Fab是一家在线电商，原来的购物车造型是一个购物车的图案，和我们今天线上购物的体验一样，用户浏览商品时可以通过点击购物车把商品放进去。这家公司的产品经理设计了两个新的方案 B1、B2，把购物车的图形改成不同的文字，期望新的方案能够提高商品加入购物车的转化率。

图1 “购物车”的A/B 测试案例

如图1所示，该公司把实现了两个新方案的软件版本都发布到线上和老版本同时运行，等价、随机地把同一地区的用户分流到这3个版本上，然后在线监控该地区用户转化率。运行一段时间后，得到的结果是：相比老版本A， 新的版本B1和B2都不同程度地提升了转化率，B1提升49%，B2提升了15%。因此，Fab公司最终选择了方案 B1，向所有用户发布集成了 B1 的软件版本。今天在其网站上看到的购物车的样子就是纯文字“Add To Cart”的设计方案。

另外，灰度发布本身相当于让用户参与测试。来自微软的一篇论文阐述了灰度发布的理论和实践，如图2所示，强调应该伴随在软件测试方面投入的不断增加来不断扩大发布范围，这里的测试投入既包括内部研发团队的测试投入，也包括用户以使用新版本并反馈问题，还包括对于软件系统的在线监控。

图2　微软的灰度发布的理论及实践

最初，团队可以发布一个“测试中的版本”，相当于金丝雀发布，尽管质量比较差，但是影响范围很小，而且这部分用户也参与了测试并且反馈产品问题；随着测试投入增加，当产品中的严重缺陷进一步被修复，这时可以扩大用户范围，但仍然选取部分用户发布新的版本。下一步，当产品质量满足了质量标准的下限，可以面向所有用户发布具备“最小化可行性质量（Minimum Viable Quality，MVQ）”的版本。版本发布后，持续通过线上监控手段来识别已经发布的版本中的严重缺陷（测试右移）。整个过程体现了精益的理念，在每个范围内以可接受的质量和风险尽快发布产品。

（当当满100减50活动正在开展）

灰度发布需求

什么是灰度发布

• 什么是灰度发布呢？要想了解这个问题就要先明白什么是灰度。灰度从字面意思理解就是存在于黑与白之间的一个平滑过渡的区域，所以说对于互联网产品来说，上线和未上线就是黑与白之分，而实现未上线功能平稳过渡的一种方式就叫做灰度发布。
• 非黑即白从来不是一种普遍现象，从色彩角度讲，灰度指不饱和的黑色，我们把黑色定为基准色，每个灰度对象是从白色（0%）到黑色（100%）的中间值，这中间的98%都是灰。

互联网产品的几个特点：

• 用户规模大、版本更新频繁。新版本的每次上线，产品都要承受极大的压力，而灰度发布很好的规避了这种风险。

在了解了什么是灰度发布的定义以后，就可以来了解一下灰度发布的具体操作方法了。可以通过很多种形式来抽取一部分用户，比如说选择自己的VIP用户，或者选择一些活跃用户，把这些用户分成两批，其中一批投放A版本，另外一批投放B版本，在投放之前就要对各种可能存在的数据做到收集记录工作，这样才能在投放以后查看两个版本的用户数据反馈，通过大量的数据分析以及调查来确定最后使用哪一个版本来进行投放。

什么是灰度发布呢？

• 一般来说，一套完善的灰度发布是需要先进行必要的用户标识的，也就是区分用户，比如说从付费数量或者所在地区以及活跃程度等很多方面来进行区分，这种区分的目地也是为了可以更加精确的进行必要的数据分析。

一套完整的灰度发布机制会包括下面这些阶段：

• 用户标识：主要是区分用户，同时也为数据分析做辅助。
• 目标用户/流量筛选：需要参考用户特征、用户流量、用户范围及用户体验的一致性，版本迭代针对全部用户还是部分用户，小流量试验通过再放量，一般来说按照内部用户-种子用户-活跃用户-所有用户的顺序就是一种典型的范围控制，体验一致性要求考虑新旧版本的跨度是否过大，用户能否接受。
• 实时数据监控：监测诸如新版本稳定性、服务器稳定性、使用次数、使用频率等数据与原有数据对比。
• 一键发布/回滚：从数据反馈结果决定是否发布/回滚。

有人质疑灰度发布是一种浪费。但与其说这是浪费不如说是冗余和弹性，灰度发布能避免新版本全量上线的风险，通过小流量验证的方式，在灰度阶段就能发现、调整并优化产品中的问题，平滑迭代。
同时还要对所有的相关数据进行收集工作，比如新版本的稳定性，服务器的稳定性以及使用次数，使用频率以及各种数据，方便和以前的原有数据进行对比。

也许有人会觉得灰度发布完全没有必要，是一种资源的浪费，其中灰度发布是非常有用的，这样做的目地不但能了解最真实的用户体验同时还可以有效的防止重大BUG产生影响系统回档或者造成其他更多不必要的经济损失，所以说灰度发布是有效避免新版本上线风险的一种有效办法，可以通过小流量来先进行测试工作，帮助新版本完成平滑迭代。