今天，谈一谈我一个业务前端开发对质量保证-灰度验证理解。
灰度发布，有的团队叫预发布，说法口径不一，但实际是一样，都是在生产发布前，发布一个内部人员的生产发布，不对用户开放。稍微正规的团队，发布部署有专门的平台架构去研发，搭建一个部署发布平台，里面就有灰度。但大多数灰度的研发者，考虑的是应用服务层面，即如何灰度服务器（集群）跟生产数据挂钩，顶多涉及一个前端到后端的关联，当然前端也有服务应用，即 ssr 项目，也就做一个访问路径映射。
所以，实际很多时候前端灰度验证，涉及 webview 环境、灰度和生产链接等问题，平台提供灰度方案无法解决所有场景验证，还需业务开发自己想方法（本文下方会谈到有哪些这样问题） 。举个具体例子，h5投放微信环境的场景，灰度如何验证？平台（架构）会考虑这类问题吗？不会，最终还的是业务方，自己找解决方案，这也是本文讨论的重点，不过我们还是先简单了解部署流程和灰度架构，这里不会详谈，具体的科普大家可以看下面几篇文章地址。
灰度测试是什么意思呢？
前端灰度发布落地方案
搭建具备灰度发布能力的技术架构
1、研发流程
从上图可以，看出灰度是上线之后最后一次验证，若发现有问题可以修改代码，之后就不能在修改，一旦上了生产，若在发现问题，只能重排需求或者其他紧急方案，我们不说生产造成什么问题（在生产之后开量开关控制，保证不用发版，业务功能恢复上一个版本），单从业务价值来说，是不是延期了！所以，尽量保证所有测试案例在灰度下验证到。
ps：有些过于敏捷开发团队，可能生产环境，前1个小时发现问题，立马修改部署，这多半创业公司，不算太正规。
2、前端灰度实现方案
我们不需要纠结灰度架构细节，说到底前端灰度实现原理不算太复杂。得了解前端几种灰度实现方案
2.1 csr 项目灰度方案
csr 项目是静态资源，我访问页面，保证静态资源服务是最新的代码就行，场景灰度方案，单独设置灰度域名或灰度路径。然后，如果本次发版涉及后端依赖，接口需要透传cookie灰度标识或者其他灰度标识给到后端。
2.1.1 灰度域名方案
生产域名: www.abc.com
灰度域名: hd.abc.com
优点：部署快，操作简单，不需要运维。
缺点：验证时，遇到连接跳转麻烦，同于会遇到跨域的问题，尤其手机断的跨域问题不太好解决，存在一定安全问题。
2.1.2 灰度path方案
生产路径：www.abc.com/your/prd/project/path
灰度路径：www.abc.com/your/hd/project/path
优点：部署快，操作简单，运维可有可无。
缺点：验证时，遇到连接跳转麻烦，也存在一定安全问题。
实际上，这个灰度域名方案本质是一样，都是弄一个灰度url，映射静态资源。
2.1.3 灰度客群白名单方案
弄一个客群灰度白名单，在白名单里可以访问灰度，不在只能访问生产。
为了更加灵活控制，客群灰度白名单只是条件之一，应该设置一个cookie灰度标识或其他方式灰度标识，组成满足2个条件就可以进入灰度。为什么？灰度白名单属于生产，应该严格控制发版次数，越少越好，cookie就不一样，开发人员内部想设置。具体流程如下：
优点：无需理会跳转连接问题，也无需考虑链接跳转问题，相对来说安全。
缺点：部署多，操作不简单，非登录页面等场景无法验证。
2.2 ssr 项目灰度方案
ssr项目灰度，最根本是要灰度服务应用，即一个灰度服务器。 ssr 项目灰度方案也可以像csr那样，弄个灰度域名或灰度path来映射灰度应用服务，但没有必要了，会产生多余跳转连接问题，并且人力不会少。所以，最佳标识，应该是灰度cookie标识或者其他方式灰度标识。
由于没有对比性，优缺点不谈。
2.3 RN 项目灰度方案
RN 项目，基本上和src项目方案一样，略。当然这里不考虑依赖native层、原生层，下面会谈到。
2.4 涉及native层或原生的项目灰度方案
这个方案简单，发一个内侧版本的生产app。
2.5 灰度方案归类
会发现前端灰度方案，分为4类
- 灰度的url
- 灰度的服务器
- 灰度白名单
- 内测版本的生产app
需要注意的，有些灰度场景需要结合上面几种方法，才能实现灰度，切记不要照本宣科，这里提供更多是解决问题思路。
在我工作的经验和我所了解到了也就是4种，你也可以说底层实现思路，我看我司很多同学被平台xxx灰度方案，吓懵逼了。然后前端页面访问灰度的链路流程，大致分为2种：
非灰度白名单方案
灰度白名单方案
3、灰度不能解决的问题
我所知道灰度方案，上已经列举完了。如果你做为一个业务开发，那么这些所有灰度方案，并不能解决在灰度场景下验证所有场景，且是常态，这个我们认知必须要有。
3.1 问题1，script标签引入第 3 方 js 文件的灰度，如何实现？
方案肯定很容想到，不就和csr项目一样吗？
- url 的更换（包含域名、path）方案，修改链接会造成额外代码进入
- 灰度白名单方案，部署平台方有研发吗？
再说句大实话，大多数的团的第 3 方js文件的开发人员，不考虑灰度是常态。那有无更好的方案？当然有，chrome 插件实现请求转发，无需修改我们业务源码。我自己也研发了，由于在公司使用，不方便公开。但是有同学，已经弄过了，贴一个文章地址
这个方案有个缺点，如果应用场景不能在chrome浏览器上验证的话，那么这个方案也解决不了。
3.2 问题2，缺乏数据，怎么验证前端场景？
某一个场景的数据帐号缺乏，我相信很多团队都遇到这个问题，这是一个常态问题。利用chrome 插件 mock 生产数据。这里可以推荐插件——Ajax Interceptor，在chrome 应用商店下载不到，可以在github上下载源码？
这个方案的缺点是：不能 mock 后端逻辑，只能验证前端场景。
3.3 问题3，灰度域名方案，各个平台跨域问题怎么解决？
这个问题要分情况，具体如下：
- 自家公司的app，这个最好由 app 的webview的研发，把灰度域名设置成不跨域。当然不设置，只能灰度path方案
- 微信app，这里提供一个操作文档chrome 和 微信开发者工具 跨域
- chrome，也参考这篇chrome 和 微信开发者工具 跨域
- 其他平台，没有调研过
3.4 问题4，ssr 项目，除了灰度方式外，还有其他方式模拟生产环境？
ssr 项目是一个应用，他需要服务器才能跑起。但有的时候，我们发完灰度之后，发现问题却无法确定问题，原因是日志没有打，无法排查，需要重新发灰度。如果是个正规团队，灰度发版是有严格限制的，需要等待几天才能发灰度，有时候这个时间等不起。
但是，有一个方法——本地环境mock生产环境。这个方法是不是很简单，但是我告诉你，我们有一个搞了3年ssr项目，相当精通ssr的同学，就没想过这个方案。导致我们一个灰度问题排查，看看足足2天梳理逻辑排查，虽然排查出来。
3.5 问题5，怎么模拟各种 app 的环境？
这个就很简单的了，利用chrome修改 useragent，具体看截图。
这个大家，可能有很多其他方式，改变chrome的 ser-agent 来模拟是哪个app的webview，大致思路都是一样的。
3.6 问题6，面临的场景，实在无法验证，那怎么办？
按照我的工作经验和现在状态，目前能够想到，只有这5个问题，但是还有灰度场景，是我们无法验证。这个时候，我们该帮日志监控告警和埋点做好。在发完生产代码之后，查看一个功能整个链路是否有埋点，如果有且数量，代表正常，反之不正常。日志监控告警也是同理。
（完）
