阅读 223

关于前端项目部署发布的相关思考

公司前端项目部署现状

将 html 托管给后端,前端只发静态资源(index.js/index.css),然后通过某种方式去刷 html 的静态资源版本号(?version=时间戳或递增数字)。

比较好的实践

我们先来看看前端项目部署的比较好实践是什么?

出处:大公司里怎样开发和部署前端代码?

可以总结出以下四点:

  1. 配置超长时间的本地缓存 —— 节省带宽,提高性能
  2. 采用内容摘要作为缓存更新依据 —— 精确的缓存控制
  3. 静态资源 CDN 部署 —— 优化网络请求
  4. 变更资源发布路径实现非覆盖式发布 —— 平滑升级

上面文章可是本文的基石,5 年过去了,更好的方案是什么呢,还希望大佬赐教。

作为一个毕业 1 年的菜鸟,我就先着上面的文章来看看目前公司发布流程的不足吧。

公司部署方案优缺点

前端只发布静态资源,只要 html 引用的资源不刷版本号,对老用户是没有影响的(存在强缓存,直接请求本地缓存,对应实践 1),新用户虽然没有缓存,但由于是静态资源是同名覆盖发布,所以请求新的 index.js/index.css 资源,只要资源不依赖 html 结构,看到新版本功能,也没有影响(注意:如果依赖 html 结构,请求新资源可能就会出现问题,好在目前单页应用基本不依赖 html 结构,一个#root 根节点 就够了)。

(强行)优点

  1. 覆盖发布。服务器不会有大量静态资源文件积累。(这个很重要?)
  2. 后端可以向 HTML 内注入一些内容,比如用户信息。

缺点

  1. 粗粒度的版本号刷新策略,导致根据文件内容变化选择性更新缓存(对应实践 2)无法实施
  2. 覆盖发布。在 html 刷新版本号前,新用户和老用户可能看到的页面版本(功能)不同
  3. html 托管在后端,导致一定程度的前后端未分离(譬如打包策略变更需要后端配合更改 html)

照猫画虎

那么按照上面的实践,如何处理比较好呢?

  1. 前端每次基于 content hash(依赖数据摘要算法) 打包生成静态资源文件名(例如 aaa.[contenthash].jsbbb.[contenthash].css),文件名是否变化取决于文件内容是否变化
  2. 使用前端的 html,前端可在打包过程中自动注入静态资源文件地址
  3. 静态资源先发布,html 后发布

再来看看上面的缺点是否被解决了?

1. 粗粒度的版本号刷新策略,导致根据文件内容变化选择性更新缓存(对应实践 2)无法实施

文件名是基于 content hash生成,在发布新的 html 后,若文件内容未发生变化,文件名不会发生改变,依旧使用本地强缓存,若文件内容变化,文件名会发生改变,会请求新的静态资源,达到了选择性更新缓存的效果。

2. 覆盖发布。在 html 刷新版本号前,新用户和老用户可能看到的页面版本(功能)不同

非覆盖式发布,文件名[contenthash]不同不会覆盖,旧的静态资源文件依旧存在。

新的静态资源发布后,新的 html 未发布前这个时间段内,老用户请求到旧的 html,请求的是旧的静态资源,文件名(或者说文件路径)未变化,依旧使用本地强缓存,新用户请求到旧的 html,没有本地缓存,但旧的静态资源未被覆盖,依旧可以请求到,此时看到的都是旧版本内容。

新的 html 发布后,老用户浏览器会选择性更新本地缓存,新用户直接请求新的静态资源,看到的都是新版本内容。

3. html 托管在后端,导致一定程度的前后端未分离(譬如打包策略变更需要后端配合更改 html)

html 完全由前端控制,后端只需要提供 API 即可,前后端真正意义上的完全分离。

缺点:

  • 发生变化的文件 hash 值不同,非覆盖发布,可能造成服务器上无用的静态资源越来越多,但这是可以解决的
  • 后端不能往 html 注入一些内容

结语

经验浅了些,参考的资料古老了些,可能有些地方有失偏颇,请一定要指正。

而且项目上线是肯定要配 Nginx 的,要去找运维帮忙配,流程上还有可以优化的地方,现在这种形式对前端制约太大了。

关注下面的标签,发现更多相似文章
评论