前言：本承接上一篇文章《不用刷新！用户无感升级，解决前端部署最后的问题》，在加入BFF层后的增量部署会碰撞出哪些火花呢？本文主要讲解一个完备的增量部署是怎么样，以及如何缓解增量部署的代码冗余的问题。最后，加入BFF层后的增量部署会增强哪些正向的影响力。
一、增量部署的完备性
前端增量部署需要每一个版本存放一个独立完整的目录，文件只会新增不能替换，各版本不会相互干扰。但是，这样也会带来一个很明显的问题：入口文件（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统一的问题，而且从流程上优化后首屏加载速度。用户和版本的关联，既可以做到研发人员可以有无限的测试环境，而且，灰度放量可以更加灵活。