记一次前端构建速度优化

关于自动化构建

关于前端项目的上线，其实就是将前端项目执行构建后，将构建的产物放到静态资源服务器上。在开发个人的机器上构建，然后通过上传的方式发布，其实就能完成简单的上线目标。

几年前，所在的公司推行敏捷开发，发版会非常频繁，手动上传的方式就显得非常笨拙，需要自动构建的机制。

根据当时公司所具备的资源，决定采用 jenkins 来构建，主要就是通过 gitlab 的 webhook，在指定分支代码更新后，调用 jenkins 的构建任务。

Jenkins 的具体构建任务大致就是，基于 docker 的 node 镜像，拉取最新的代码，安装依赖，然后执行构建，最后将构建的产物再放到一个 nginx 容器中，对外提供静态服务。

后来，在 shopee 及后面的公司，自动化发布的过程大同小异，都是类似的。

现在所在的公司，使用了阿里云的云效流水线来构建前端，本质也是这个原理。

但是遇到了流水线上，构建时间长达 7-8 分钟的问题，需要优化。

要减少构建时间，无非从下面几个角度：

所以，我当时就从这些角度开始排查当前项目的 webpack 配置。

然而当我看完，发现之前的维护者把这个配置已经维护的很好了，上述优化都已经加上了。所以没有任何优化的情况下，我在本机执行了构建。

除去安装依赖，克隆代码等时间，本机构建仅需要 40s！

一开始，认为是机器的差异，我用自己的机器构建了多次，第一次 2 分钟，后续几次也都是 40s 左右。

随后我又去查看云效分配的机器的配置，配置远高于个人电脑，但是构建速度却很慢。

一方面，这确实是由于环境的差异带来的构建速度慢，云效的机器毕竟是给所用用户共享的，可能会有各种限制，执行效率比个人电脑低可以理解。

所以我们只能从缓存的方向进行优化，因为远程自动化构建，相当于每一次都是一个新的环境来构建，缓存的优化手段是没有办法生效的。

好在云效的文档中提到了，如何设置自己的缓存来达到在多次构建直接使用缓存的目的。

剩下的就是在构建脚本执行前，将上一次的缓存复制到工作目录下，在本次构建完成后将构建过程中产生的缓存复制到缓存目录下。

唯一遇到的坑就是目录结构的问题，我的缓存目录是 /root/.cache, 将缓存复制进去后我们的缓存实际在 /root/.cache/.cache 下，一开始复制到项目下的是前者，由于目录结构的问题导致缓存不生效。

最后，构建的时间从 7-8 分钟优化到了 3 分多钟。

虽然比起本地不使用缓存还慢，但是这还是由于机器的原因造成的，而且优化效果已经很明显了，一天多次构建的情况下，积少成多，一天可能可以少等待 30 分钟。