SPA前端项目灰度发布策略

前提

B/S 项目的灰度发布本应完全由服务端控制，但是SPA的出现打破了这个局面，B/S变得越来越像C/S，故发布策略也需要做相应调整。

灰度发布（又名金丝雀发布），在此基础上，我们可以做内测，也可以做 A/B 测试，战略意义还是很大的。

简单思路todo：

常规项目 npm 打包，同一版本的代码，每次打包静态文件名必须一致，

webpack中hash、chunkhash、contenthash 区别

使用 contenthash 作文件名， 或者使用自定义版本号来维护。

打包完成，手动提交版本号到服务端，由服务端纳入灰度发布的控制

项目入口文件 不再直接使用 dist/index.html

而是由服务端来控制

用户登录后，服务端可以任意控制用户应该访问哪个版本的前端；

前端项目的每次请求都必须带上版本号：由服务端处理做后续处理，

比如：

有版本太旧，可提示用户刷新，刷新以后依然如此，可以提示向后台反馈；

好处：

1. 提前获得目标用户的使用反馈；
2. 根据反馈结果，做到查漏补缺；
3. 发现重大问题，可回滚“旧版本”；
4. 补充完善产品不足；
5. 快速验证产品的 idea。