3. 构建工具与自动化：Maven、Gradle、npm、Webpack

聊到持续集成，构建工具是绕不开的第一道坎。说白了，构建工具就是帮我们把源代码变成可交付产物的那套流水线。我见过不少团队，CI 跑得慢、经常挂，根子往往就出在构建脚本写得不够好，或者缓存策略没搞对。

这一章，我带你过一遍主流的构建工具——Java 系的 Maven 和 Gradle，前端系的 npm 和 Webpack。我会结合自己的踩坑经验，聊聊怎么写构建脚本，以及怎么优化构建缓存。

3.1 Maven：约定大于配置的老大哥

Maven 在 Java 世界里地位很稳。它的核心思想是「约定大于配置」——你只要按它的目录结构放代码，它就知道怎么编译、测试、打包。

我个人习惯用 Maven 做标准化的 Java 项目。它的生命周期很清晰：clean、compile、test、package、install、deploy。在 CI 里，我们通常跑 mvn clean package 就够了。

关键点：Maven 的依赖管理基于 pom.xml，所有依赖都会下载到本地仓库（~/.m2/repository）。这个仓库就是缓存的关键。

我在项目中遇到过一个问题：CI 每次构建都重新下载所有依赖，导致构建时间长达 10 分钟。后来我配置了 Maven 的本地仓库缓存，把 .m2 目录挂载到 CI 的持久化存储上，构建时间直接降到 2 分钟。

构建脚本示例（pom.xml 片段）

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>3.8.1</version>
      <configuration>
        <source>11</source>
        <target>11</target>
      </configuration>
    </plugin>
  </plugins>
</build>
缓存优化技巧：在 CI 配置中，将 ~/.m2/repository 设置为缓存目录。如果使用 Jenkins，可以用 Pipeline 的 cache 步骤；GitLab CI 可以用 cache 关键字。

3.2 Gradle：灵活高效的后来者

Gradle 比 Maven 更灵活，构建速度也更快。它用 Groovy 或 Kotlin DSL 写脚本，支持增量编译和构建缓存。说白了，Gradle 知道哪些文件没变，就不重新编译。

我曾经把一个大型微服务项目从 Maven 迁移到 Gradle，构建时间从 15 分钟缩短到 4 分钟。为什么？因为 Gradle 的增量编译和并行任务执行太强了。

构建脚本示例（build.gradle）

plugins {
    id 'java'
    id 'application'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.google.guava:guava:30.1-jre'
    testImplementation 'junit:junit:4.13.2'
}

application {
    mainClass = 'com.example.App'
}

// 开启构建缓存
tasks.withType(JavaCompile) {
    options.incremental = true
}
注意：Gradle 的构建缓存默认是本地缓存。在 CI 中，你可以配置远程缓存（比如用 Redis 或文件共享），这样不同构建节点之间也能共享缓存。我曾经因为没配远程缓存，导致每个 CI 节点都要重新编译一遍，白白浪费了半小时。

3.3 npm：前端世界的包管理器

npm 是 Node.js 生态的基石。它管理着成千上万的包，但也是构建速度的瓶颈之一。你想想看，每次 npm install 都要下载几百兆的依赖，能不慢吗？

我建议在 CI 中做两件事：

  • 缓存 node_modules：把 node_modules 目录缓存起来，避免每次重新下载。
  • 使用 package-lock.json：锁定依赖版本，确保构建可重复。

构建脚本示例（package.json 片段）

{
  "name": "my-app",
  "version": "1.0.0",
  "scripts": {
    "build": "webpack --mode production",
    "test": "jest",
    "lint": "eslint src/"
  },
  "dependencies": {
    "react": "^18.0.0",
    "react-dom": "^18.0.0"
  },
  "devDependencies": {
    "webpack": "^5.0.0",
    "babel-loader": "^8.0.0"
  }
}
缓存优化技巧：在 CI 中，将 node_modules 和 ~/.npm 目录都缓存起来。npm 的缓存目录存放着已下载的包，即使 node_modules 被清空，也能从缓存中快速恢复。

3.4 Webpack：模块打包的艺术

Webpack 是前端构建的核心工具。它把 JavaScript、CSS、图片等资源打包成浏览器能识别的文件。但 Webpack 的构建速度，嗯，有时候让人头疼。

我记得有一次，项目里的 Webpack 构建需要 3 分钟。后来我加了几个优化，直接降到 30 秒：

  • 使用 cache-loader：把 loader 的处理结果缓存起来。
  • 开启持久化缓存：Webpack 5 内置了文件系统缓存。
  • 使用 DllPlugin：把不常变动的第三方库单独打包。

Webpack 配置示例（webpack.config.js）

const path = require('path');

module.exports = {
  mode: 'production',
  entry: './src/index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        use: 'babel-loader',
        exclude: /node_modules/,
      },
    ],
  },
  // 开启持久化缓存
  cache: {
    type: 'filesystem',
    cacheDirectory: path.resolve(__dirname, '.webpack-cache'),
  },
};
核心思路：构建缓存优化的本质是「避免重复劳动」。不管是 Maven 的本地仓库、Gradle 的增量编译，还是 Webpack 的持久化缓存，都是在告诉构建工具：「上次的结果还能用，别重新算了。」

3.5 构建脚本编写的最佳实践

写构建脚本，说白了就是写自动化流程。我总结了几个原则：

  1. 保持幂等性：同样的代码和配置，每次构建结果应该一样。
  2. 最小化依赖：只安装真正需要的依赖，别把整个宇宙都拉进来。
  3. 分阶段构建：把编译、测试、打包分成不同阶段，方便定位问题。
  4. 善用缓存：依赖缓存、编译缓存、测试缓存，能用的都用上。

3.6 构建缓存优化策略对比

工具 缓存类型 缓存位置 优化效果
Maven 依赖缓存 ~/.m2/repository 减少依赖下载时间
Gradle 增量编译 + 构建缓存 ~/.gradle/caches 减少编译时间
npm 依赖缓存 ~/.npm + node_modules 减少包安装时间
Webpack 持久化缓存 .webpack-cache 减少打包时间

3.7 避坑指南

我曾经在 CI 里犯过一个低级错误：把 node_modules 缓存了，但没把 package-lock.json 的变化考虑进去。结果依赖更新了，缓存还是旧的，导致构建失败。嗯，这里要注意：缓存一定要和锁文件关联，锁文件变了就清缓存。

另一个坑是 Maven 的 mvn clean。如果你在 CI 里每次都跑 mvn clean package，那 clean 会清掉编译缓存，导致每次都要重新编译。我建议只在需要完全重建时才用 clean，平时用 mvn package 就够了。

警告：不要盲目缓存所有东西。比如测试报告、临时文件这些，缓存了反而会占用空间，甚至导致误判。只缓存那些「构建一次，多次复用」的内容。

好了，这一章的内容就到这里。构建工具和缓存优化，说白了就是「让机器少干活」。你想想看，每次构建都重新下载依赖、重新编译，那得多浪费？下一章我会聊聊容器化与镜像构建，到时候再给你分享一些 Docker 的实战经验。

← 上一章 📖 返回目录 下一章 →