Angular应用Azure部署：VSTS CI流水线合理性与npm优化咨询

我首次将Angular应用部署至Azure，选择了Node with Grunt模板搭建VSTS持续集成流水线，步骤如下：

• 任务：Npm@1，显示名称npm install，工作目录CrSPA/Clientapp，verbose设为false
• 任务：Npm@1，显示名称Build Project，命令为custom，工作目录CrSPA/Clientapp，verbose设为false，自定义命令run build-prod（对应ng build --prod）

现存在以下疑问：

1. 当前方案是否正确？
2. 每次应用小改动都需执行完整npm install，耗时较长，如何优化？
3. 是否应本地构建后再推送代码？
4. 能否将node_modules文件夹推送到代码仓库以避免每次执行npm install？

1. 当前方案的正确性 #

你的基础CI流水线流程是合理的：先安装依赖再执行生产构建，完全符合前端项目CI的标准逻辑。不过有个小细节可以优化——你选的是Node with Grunt模板，但实际用的是npm命令执行Angular构建（通过npm run build-prod调用ng build --prod），如果模板自带的Grunt任务没用到，建议移除，避免冗余步骤拖慢流水线。

2. 优化npm install耗时的方法 #

每次全量安装确实会浪费时间，推荐这两个实用优化方向：

• 启用npm缓存：在VSTS流水线里添加Cache@2任务，缓存node_modules目录。配置示例：

  - task: Cache@2
    inputs:
      key: 'npm | "$(Agent.OS)" | CrSPA/Clientapp/package-lock.json'
      restoreKeys: |
        npm | "$(Agent.OS)"
      path: 'CrSPA/Clientapp/node_modules'
    displayName: Cache npm dependencies
  

  这样只有当package-lock.json内容变化时，才会重新全量安装依赖；否则直接复用缓存的node_modules，能把安装时间压缩到原来的1/10甚至更少。
• 改用npm ci代替npm install：npm ci会严格按照package-lock.json的版本安装依赖，不仅速度比npm install快，还能保证CI环境和本地依赖版本完全一致，避免因为依赖版本差异引发的构建问题。

3. 是否应该本地构建后推送代码？ #

绝对不推荐这么做，原因有三个：

• 构建环境不一致：本地的Node版本、依赖版本可能和CI代理环境不同，很可能出现本地构建正常，但CI构建失败的情况，排查起来非常麻烦。
• 仓库冗余膨胀：Angular生产构建的dist目录体积不小，推送到仓库会大幅增加仓库大小，拖慢克隆、拉取代码的速度。
• 失去CI的核心价值：CI的意义就是自动化验证每一次代码提交的可靠性，本地构建推送相当于跳过了这个验证环节，万一有人本地构建时偷偷修改了产物，很容易引发线上问题。

4. 能否将node_modules推送到代码仓库？ #

强烈不建议这么做，理由如下：

• 跨平台兼容性问题：node_modules里很多依赖包含平台专属的二进制文件（比如某些原生模块），Windows环境下的node_modules拿到Linux的CI代理上根本无法正常工作，反之亦然。
• 仓库体积暴增：node_modules通常会占用几百MB甚至几GB的空间，推送到仓库会让仓库变得臃肿不堪，后续克隆仓库会慢到让人崩溃。
• 依赖版本不可控：如果后续修改了package.json但忘记同步更新node_modules，会导致代码仓库里的依赖版本和package.json不一致，引发各种莫名其妙的bug，排查难度极大。
• 违背前端最佳实践：行业通用做法都是通过package.json和package-lock.json管理依赖，CI环境按需安装，这样既能保证依赖版本的一致性，又能避免上述所有问题。

内容的提问来源于stack exchange，提问作者Sandeep Thomas