git灰度发布版本_一种前端灰度发布方案

本文介绍一种前端灰度发布方案，主要解决的是传统的灰度发布只能以机器维度进行分组的问题。提供一种用户维度分组的灰度发布机制。

传统灰度发布，因为是以机器分组，所以要求服务是无状态的。所谓无状态就是对请求的处理是上下文无关的。有长连接、读写文件、缓存等场景，就是所谓”有状态“的。有状态的服务，如果用户的前一个请求打在机器A，后一个请求打在机器B，就会出问题。

所以，有状态的服务灰度发布，要做到：

同一用户始终访问同一版本的代码

放量过程像传统发布一样可控

本灰度发布方案对构建、部署、启动服务、处理请求阶段分别做改造，实现有状态服务灰度发布。

1、方案概述

我们把线上的代码称为stable版，本次发布的新代码称为beta版。先整体描述一下方案：

用git tag标识每次发布

在构建阶段生成tag，同时用tag名称来命名manifest.json

每次构建完新版本后，从cdn源机器取回上次发布的manifest.json文件，一并放在dist目录下

部署阶段全量部署到所有机器，在运行阶段来决定访问哪个版本的代码

node层启动服务时，读dist目录下的两份manifest.json文件，这样就能拿到新旧两个版本的文件清单

处理请求时，根据动态配置的放量信息和分流策略，来决定使用哪个manifest.json中的文件

版本号信息放在cookie中，以保证同一用户始终访问同一版本代码

2、开发阶段

正常开发代码，无需有任何额外操作。

3、构建阶段

publish-tag

新增一个git tag，以p-开头，意为publish。每次发布都有一个tag标记，格式为p-201911111001-lvdabao.标记发布时间与发布者。构建完成并同步cdn成功后，会将该tag同步到git仓库。

manifest.json

manifest.json是webpack构建完毕后的文件清单，可以用webpack-manifest-plugin插件生成。如有特殊需求也可以自己编写。我们是自己编写，并在动态渲染首页HTML时读取清单内容并输出script标签。

每次构建生成的文件名称是这样的格式：manifest-p-201911111001-lvdabao.json，这样每次发布都生成对应tag命名的manifest.json文件。

启动服务时可以一次读取到内存中，并不是处理每个请求都读一下文件，所以不必担心性能。

获取上次发布的版本信息

我们是用publish-tag来标识版本号的，只要拿到上次发布时的tag，就能取到对应的manifest.json文件。所以构建的最后一步就是把上一版的manifest.json文件从cdn源机器取到当前构建后的dist目录下，为后续服务启动时使用。

取上次的tag也很简单，一个git命令搞定：git tag –sort=-taggerdate | grep “^p-.*” | head -n 1

容错机制

如果上次发布的版本有重大问题，不能作为stable版使用，有什么办法呢？

所以我们增加了一个额外流程，允许构建的时候传入环境变量，指定stable tag。这样在获取stable版本信息时，优先取环境变量中指定的。

4、部署阶段

部署跟普通流程没什么区别，将dist目录发布到目标机器就行了。每次部署的dist文件包含以下：

beta版的manifest.json文件

beta版的资源文件

stable版的manifest.json文件

5、启动服务

启动服务时我们需要干两件事情：

把两个manifest.json文件读到内存中，供分流时使用

自动修改放量配置，将新版本比例改为