一次NPM前端项目的CI-Build速度优化
基础设施部分，项目部署在中国的亚马逊云，使用了 AWS 的容器服务（ECS）、容器注册表（ECR）、对象存储（S3）与弹性计算（EC2）。源码管理采用 Atlassian 的 Bitbucket，一个基于 Git 的代码仓库。CI/CD 通过 Jenkins 实现，使用插件 pipline 进行维护。项目使用 Node.js 语言进行开发，代号为 salmon。项目打包与发布采用 NPM 和 Docker。
流程分为标准发布流程。在收到同事 A 和 B 的反馈后，对 CI/CD 过程进行了深入分析。主要分为三个关键步骤：编译代码（stage{ Build }）、推送到仓库（stage{ Publish }）和运行服务（stage{ Deploy }）。在分析“编译”步骤时，发现 npm run build 占用了最多时间，约为 9 分钟。进一步分析发现，容器化 CI 流程的基础设施为纯净、无状态的环境，这与传统基础设施存在差异，可能是速度差异的关键。
为复现非容器化构建流程，使用 EC2（2 核 8GB）进行测试。结果显示，已 build 过的项目目录进行后续 build 耗时显著减少，原因可能是生成了编译缓存文件。对比发现，删除 .next 目录后，项目容量减少 470MB，定位到编译后的 node_modules/ 目录下存在 .cache 文件夹，经过多次调试验证，build 前后差异 30MB 文件的确位于 .cache 目录中。将 .cache 内容应用到已执行 npm install 未 build 的目录，构建速度得到提升。
为优化缓存，考虑维护线上缓存池，使用 AWS S3 服务进行目录同步。在 EC2 测试机上运行结果良好。对 Dockerfile 进行改造，添加了 AWS CLI 工具以操作 S3。验证优化效果后，Jenkins blue-ocean 统计显示，提速效果明显。实施线上缓存池后，对其他项目进行了评估，发现无法广泛应用此优化策略。虽然工具相对简单，但在优化过程中取得的工程逻辑与解决问题的方法论，对项目和读者都具有启发意义。
流程分为标准发布流程。在收到同事 A 和 B 的反馈后，对 CI/CD 过程进行了深入分析。主要分为三个关键步骤：编译代码（stage{ Build }）、推送到仓库（stage{ Publish }）和运行服务（stage{ Deploy }）。在分析“编译”步骤时，发现 npm run build 占用了最多时间，约为 9 分钟。进一步分析发现，容器化 CI 流程的基础设施为纯净、无状态的环境，这与传统基础设施存在差异，可能是速度差异的关键。
为复现非容器化构建流程，使用 EC2（2 核 8GB）进行测试。结果显示，已 build 过的项目目录进行后续 build 耗时显著减少，原因可能是生成了编译缓存文件。对比发现，删除 .next 目录后，项目容量减少 470MB，定位到编译后的 node_modules/ 目录下存在 .cache 文件夹，经过多次调试验证，build 前后差异 30MB 文件的确位于 .cache 目录中。将 .cache 内容应用到已执行 npm install 未 build 的目录，构建速度得到提升。
为优化缓存，考虑维护线上缓存池，使用 AWS S3 服务进行目录同步。在 EC2 测试机上运行结果良好。对 Dockerfile 进行改造，添加了 AWS CLI 工具以操作 S3。验证优化效果后，Jenkins blue-ocean 统计显示，提速效果明显。实施线上缓存池后，对其他项目进行了评估，发现无法广泛应用此优化策略。虽然工具相对简单，但在优化过程中取得的工程逻辑与解决问题的方法论，对项目和读者都具有启发意义。