CI流水线基础

CI/CD，说白了就是让代码从提交到上线全自动。我刚开始工作时，项目还没引入CI。每次上线都得手动打包、上传、部署。那叫一个痛苦。后来团队推了Jenkins，我才知道原来这些事能让机器干。

1.1 什么是CI/CD

持续集成（CI）——你每次提交代码，系统自动拉取、构建、跑测试。它的核心是尽早发现问题。问题越早发现，修起来成本越低。

持续交付（CD）——构建测试通过后，自动把制品部署到预发环境。随时可以发布。持续部署则更进一步，直接推到生产。

我记得有个同事说过一句大实话：「CI/CD就是让机器干机器擅长的，人干人擅长的。」自动化重复劳动，开发专注写代码。就这么简单。

1.2 传统流水线的痛点

传统流水线最大的毛病就一个字：慢。有多慢？我见过一个项目，构建要40分钟。40分钟啊！开发只能干等着。喝杯咖啡回来，还没跑完。

具体来说，有这几个硬伤：

• 依赖安装——每次从头下载。 npm install / maven install 跑一遍，十几分钟没了。同样的包，昨天下过，今天又下。这不是傻是什么？
• 编译构建——全量编译。 只改了一行代码，结果整个项目重新编译。尤其Java、C++这类语言，编译时间能让你怀疑人生。
• 测试执行——重复跑所有用例。 改了登录模块的代码，却要把支付模块、订单模块的测试全跑一遍。浪费啊。
• 资源消耗——高得离谱。 每次构建都吃满CPU和内存。CI服务器长期高负载，其他任务排队等着。
• 开发者体验——差到极点。 提交代码后等半小时才出结果。要是挂了，再修再等。一天能跑三趟就不错了。

为什么会这样？因为传统流水线把每次构建都当成「第一次」来跑。它没有记忆。昨天刚下载过的依赖，今天照样重新下载。刚编译过的模块，今天重新编译。这种「失忆症」就是所有慢的根源。

1.3 缓存优化的重要性

缓存优化解决的核心问题就一个：别重复造轮子。你想想看，每次构建90%的依赖跟上一次一模一样。干嘛不直接复用？

我建议团队做缓存优化时，从这三步入手：

1. 依赖缓存。 把 node_modules、~/.m2、vendor 等目录缓存起来。下次构建直接复用，只有变了才重新下载。
2. 编译缓存。 用 ccache、sccache 或 build cache 工具。只编译改动的文件，没变的部分用缓存。
3. 测试缓存。 只跑受代码改动影响的测试用例。IGo 这类工具能自动分析依赖关系，精准定位。

来看看具体效果。下面是我团队一个Node.js项目的对比数据：

对比维度	传统流水线	缓存优化后
依赖安装	每次都跑 npm install（~12min）	缓存命中时直接跳过（~5s）
编译时间	全量编译（~18min）	增量编译（~3min）
测试时间	全量测试（~15min）	增量测试（~4min）
总耗时	~45min	~7min
资源消耗	CPU 80%+，持续45分钟	CPU 30%+，持续7分钟

从45分钟降到7分钟，你想想开发体验提升多大。而且服务器资源消耗大幅降低，同一台机器能跑更多构建任务。

我习惯在 CI 配置里这样写缓存逻辑：

# GitHub Actions 示例：缓存 node_modules
- name: Cache node_modules
  uses: actions/cache@v3
  with:
    path: node_modules
    key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

原理很简单：用 package-lock.json 的哈希值作为缓存key。文件没变，命中缓存；文件变了，自动更新缓存。restore-keys 是兜底策略——即使key没精确命中，也能用最近的缓存版本，减少下载量。

缓存优化的价值不只是「快」。它带来了一连串的正向连锁反应：构建快了 -> 反馈快了 -> 开发迭代速度上去了 -> 产品交付周期缩短了。说白了，这就是杠杆效应——你在流水线上投入一点缓存逻辑，撬动的是整个团队的效率提升。

下面这张图总结了 CI/CD 流水线中缓存优化的整体框架，方便你建立全局视角：