3、持续集成基础：CI的概念与价值、CI流水线设计、构建与单元测试

好，咱们今天聊聊持续集成。说实话，这个词在圈子里都快被说烂了。但真正把它用好的团队，我见过的不多。很多人以为搭个Jenkins跑个脚本就是CI了——嗯，这其实只是皮毛。

3.1 CI到底是什么？它的价值在哪？

持续集成，说白了就是「频繁地把代码合并到主干，并且每次合并都自动验证」。我个人的习惯是，每个开发每天至少往主干合一次代码。为什么这么频繁？你想想看，如果大家各写各的，憋了两周才合并一次，那场面——冲突能让你改到怀疑人生。

我在项目中遇到过最惨的一次，团队四个人并行开发了三个星期，合并时产生了200多个冲突。那天我们加班到凌晨三点，最后还漏掉了一个逻辑错误，导致线上出了P0事故。从那以后，我强制团队必须每天合并，谁不合并谁请下午茶。

CI的核心价值，我总结为三点：

• 尽早发现问题：代码一提交就触发构建和测试，几分钟内就能知道有没有问题。而不是等到上线前才发现，那时候改起来成本就高了。
• 减少集成痛苦：频繁合并，每次的改动量就小，冲突范围可控。说白了，就是「小步快跑，别憋大招」。
• 保持主干可用：任何时候拉下来的主干代码，都应该能正常构建、通过测试。这是团队的底线。

3.2 CI流水线怎么设计？

流水线的设计，其实没有标准答案。但有一个通用的骨架，我建议你照着这个来搭。

先看一个最基础的流水线结构：

代码提交 → 代码拉取 → 依赖安装 → 代码检查 → 单元测试 → 构建打包 → 制品归档

每个阶段都有它的意义。我一个个说。

3.2.1 代码拉取与依赖安装

这一步看似简单，坑却不少。我曾经遇到过一个项目，依赖安装花了15分钟，整个流水线跑下来要半小时。开发等得心焦，后来干脆不跑CI了——这就本末倒置了。

我的建议是：

• 使用依赖缓存，别每次都重新下载
• 锁定依赖版本，避免「昨天能跑今天挂了」的玄学问题
• 如果依赖太大，考虑分阶段安装，只装必要的

3.2.2 代码检查

代码检查包括静态分析和风格检查。很多人觉得这步可有可无，我告诉你，千万别省。代码风格统一了，review的时候才能聚焦在逻辑上，而不是「这里该不该加空格」这种破事上。

常用的工具有：

• ESLint（JavaScript/TypeScript）
• Pylint（Python）
• Checkstyle（Java）
• SonarQube（全语言，还能检查代码质量）

3.2.3 构建与单元测试

这是CI流水线的核心环节。构建就是把源代码变成可运行的产物，单元测试则是验证每个小功能是否正确。

我见过很多团队把构建和测试混在一起跑，其实应该分开。为什么呢？因为构建失败了，测试就没必要跑了，节省时间。反过来，构建成功了但测试失败了，说明代码逻辑有问题，需要开发去修。

3.3 构建实战：一个Node.js项目的CI配置

光说不练假把式。我拿一个Node.js项目举例，看看实际的CI配置怎么写。

假设我们用GitHub Actions，配置文件大概长这样：

name: CI Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: 拉取代码
        uses: actions/checkout@v3

      - name: 设置Node环境
        uses: actions/setup-node@v3
        with:
          node-version: '18'
          cache: 'npm'

      - name: 安装依赖
        run: npm ci

      - name: 代码检查
        run: npm run lint

      - name: 单元测试
        run: npm test

      - name: 构建
        run: npm run build

      - name: 上传构建产物
        uses: actions/upload-artifact@v3
        with:
          name: build-output
          path: dist/

你看，这个配置里我用了npm ci而不是npm install。为什么？npm ci会严格按照package-lock.json来安装，保证每次构建的环境完全一致。我曾经被npm install坑过——开发机上一个版本，CI上另一个版本，测试通过了上线却挂了。从那以后，我所有项目都强制用npm ci。

3.4 单元测试：不只是为了覆盖率

说到单元测试，很多人第一反应就是「覆盖率要到80%」。但我觉得，覆盖率只是结果，不是目标。单元测试的真正价值在于：

• 保护现有功能：你改了一行代码，测试能告诉你有没有把别的地方搞坏
• 倒逼代码设计：如果一个函数很难写测试，说明它的设计可能有问题——耦合太高、职责不单一
• 提供文档：好的测试用例，本身就是一份活文档，告诉别人这个函数应该怎么用

我在项目中遇到过一种情况：团队为了追求覆盖率，写了很多「假测试」——只调用函数但不做任何断言。覆盖率报表很好看，但一点用都没有。这就像考试作弊，骗的是自己。

3.5 构建与测试的最佳实践

最后，我整理了一些实践中总结出来的要点，希望能帮你少走弯路：

实践项	说明	为什么重要
每次提交都触发CI	不要只在合并前跑，每次push都跑	尽早发现问题，避免「攒了一堆问题才修」
流水线要快	控制在10分钟以内，超过20分钟开发就会不耐烦	慢了大家就不愿意等了，CI就形同虚设
测试要可靠	不能有「偶尔失败」的测试，要么修好要么删掉	不可靠的测试会让人失去信任，最终被忽略
构建产物要版本化	每次构建都生成唯一版本号，方便回滚	出问题时能快速定位到是哪个版本引入的
失败要通知到人	谁提交的代码导致失败，就通知谁	责任明确，修复速度会快很多

嗯，说到这里，我想起一个案例。之前有个团队，CI流水线跑一次要40分钟，而且经常因为网络波动失败。开发们烦透了，干脆在提交代码后手动关掉CI。结果呢？上线前合并时发现一堆冲突和bug，加班加得死去活来。

后来我帮他们把流水线优化到8分钟，加了重试机制和缓存，还配置了飞书通知。一个月后，CI的通过率从60%提升到了95%，线上bug减少了70%。你看，CI做好了，效果是立竿见影的。

所以，别把CI当成一个「不得不做」的苦差事。它其实是帮你省时间的利器。关键是你要把它设计好、用起来，而不是搭完就扔在那不管。

下一节我们会聊自动化构建的进阶内容，包括多环境构建和构建优化策略。到时候再细聊。