一、增量部署的完备性

前端增量部署需要每一个版本存放一个独立完整的目录，文件只会新增不能替换，各版本不会相互干扰。但是，这样也会带来一个很明显的问题：入口文件（index.html）在不同目录下，这样每一个版本的URL路径都不一样，发布后投放地址就会变化，无疑增加运营成本。

一个理想中的完备的增量部署需要满足两个条件：

• 各版本独立完整的，互不干扰，线上多版本共存；
• 一个URL地址对应多个版本；

二、缓解代码冗余的问题

增量部署需要各版本的文件皆为新增，构建的不同版本的产物出现相同内容的文件不少，这些文件在一定时间内是一直存在的。特别是一些lib库（比如：vue、react、lodash等node_modules和通用模块）基本在需求版本是不变，冗余情况太严重，也增加存储成本。为了缓解业务需求的版本代码的冗余问题，我们将一个web站点的构建产物分成三层，将其中通用模块的代码和lib库按照模块进行抽离并单独打包发到线上，供web站点使用。

三、增强正向影响力

每个版本的入口文件（index.html）存放在不同目录，导致版本的直接访问路径不一样，这里可以使用nginx（网关）转发一下就可以做到url固定。但是我们团队引入了BFF来解决该问题。

灰度逻辑可以通过编码来指定不同策略，这样前端在需求版本测试和发版可以更加灵活。

3.1 支持更灵活的版本生效方案

多版本共存，通过url参数来指定，切换更近方便，成本更低！

对于一个客户端的内嵌页（hybrid app），不方便修改地址的页面，我们也可以使用按照用户的属性进行灰度逻辑设计。比如，按照用户的userId进行版本绑定。就可以做到一个账号一个版本。

3.2 整合请求，提高首屏速度

既然引入BFF就不能就这么简单，只做一个多灰度逻辑。我们会对HTML进行整合。

对于构建的原始html在BFF进行劫持，并注入环境信息和将影响首屏加载速度的后端请求放到BFF请求整合到html。

由于后端服务和BFF都是在同一个机房的局域网，这样就可以减少网络传输时间以增加页面的首屏加载速度。

做到一个构建版本可以部署开发-测试-正式环境（一包到底）。

四、总结

有BFF层加持的增量部署，不但解决URL统一的问题，而且从流程上优化后首屏加载速度。用户和版本的关联，既可以做到研发人员可以有无限的测试环境，而且，灰度放量可以更加灵活。