持续集成基础

聊持续集成，很多新手觉得不就是自动构建吗？其实没那么简单。

我个人习惯把持续集成（CI）理解为开发团队的“合流点”。你写了代码，他改了接口，她修了Bug——这些零散的工作最终要汇到一起，怎么才能不打架？CI就是干这个的。说白了，它是一个自动化过程，只要有人把代码推送到主干，机器就会帮你验证这套新代码能不能跟现有系统和平共处。

为什么需要持续集成？

我刚开始带项目时，团队习惯“攒一波再合”。两周开发结束，合并那天叫“合并地狱”。十几个人的改动堆在一起，冲突满天飞，编译过不了，测试跑不通，定位问题又得回退版本。那两天基本就是在加班中度过的。

后来我强制推行了CI。哪怕只是改了一个变量名，也必须通过完整的构建和测试。刚开始团队觉得麻烦，但两周后大家都沉默了——再也没有出现过“合并地狱”。

持续集成与持续交付、持续部署的区别

这三个概念容易混淆。我给你列一个表格，一目了然。

概念	终点	自动化程度	关键动作
持续集成（CI）	代码合并到主干，验证通过	构建 + 测试	合并后自动运行验证
持续交付（CD）	可部署的产物就绪	CI + 部署前检查	生成制品并发布到测试环境
持续部署（CD）	自动部署到生产	全流程自动化	验证后直接上线

你想想看：如果没有CI做根基，后面的持续交付和部署就是空中楼阁。所以我做CI/CD课程，一定会把这一章讲扎实。

CI的核心工作流程

一个典型的CI流水线包含几个环节。这些环节按顺序执行，任何一个环节失败，流水线就停止。

1. 代码检出——从版本控制系统拉取最新代码。
2. 静态检查——用工具扫描代码风格、潜在缺陷和安全漏洞。
3. 编译构建——把源码变成可执行文件或包。对于C++项目是cmake + make；对于Python项目是打包成wheel；对于前端是webpack。
4. 单元测试——运行开发者编写的测试用例。这一步通常要求覆盖率不低于80%。
5. 集成测试——测试模块间的交互是否正确。
6. 质量报告——生成测试覆盖率、代码质量等数据，发送给相关人员。
7. 制品归档——将构建产物保存到制品仓库，供后续环节使用。

CI的关键实践

这一节我想跟你分享几个我踩过的坑，以及总结出来的最佳实践。

1. 频繁提交，小步快跑

为什么要频繁提交？因为改动越小，冲突越少，定位问题越容易。

有一次，团队里一位同事积累了三天的改动才提交。结果CI跑了一小时，全部失败。最后发现是中间改了一个公共函数的签名，但后续提交的代码没适配。如果分三次提交，第三个失败时就能立刻关联到那次签名修改。

2. 自动化构建与测试

所有构建步骤和测试步骤都必须脚本化、自动化。不能有“手动点击”的环节。

我们团队使用CMake + CTest做C++项目的CI。一个典型的构建脚本如下：

cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=ON
cmake --build build --target all -j$(nproc)
cd build && ctest --output-on-failure

这三行搞定一切。如果依赖手动配置，很容易遗漏某个环境变量导致构建失败。

3. 快速反馈机制

CI跑完，一定要把结果立刻通知到相关的人。我通常使用以下方式：

• PR（拉取请求）上显示Pipeline状态，红/绿一目了然。
• 机器人把失败信息推送到即时通讯群组。
• 流水线失败时自动在评论区@代码提交者。

为什么要快反馈？因为开发者正在上下文中，回头看自己的代码成本最低。等三天后再回来看，可能连变量名都忘了什么意思。

4. 失败修复不滞留

有一条铁律：流水线失败后，团队要优先修它。

我曾经在一个项目里，CI坏了三天没人修。结果又提交了20个PR，全部失败。最后合并时，20个改动堆在一起，鬼知道哪个环节出的问题。

常用CI工具对比

工具选型也是CI实践的一部分。我简单列几个我用过的，给你做个参考。

工具	部署方式	配置文件	优缺点
Jenkins	自托管	Jenkinsfile (Groovy)	插件生态最丰富，但配置复杂
GitHub Actions	云托管	.github/workflows/*.yml	与仓库深度集成，上手快，但安全审计麻烦
GitLab CI	自托管或云	.gitlab-ci.yml	内置镜像仓库，YAML语法灵活
CircleCI	云托管	.circleci/config.yml	缓存机制好，并发能力出色

我个人建议：如果团队规模小、不想维护服务器，直接用GitHub Actions。如果对安全要求高、希望完全控制基础设施，自托管的GitLab CI或Jenkins更合适。

持续集成流水线（示意图）

实战案例：以GitHub Actions搭建一个最简单的CI

光说不练假把式。我给你看一个真实项目里的配置示例。这能帮你理解上面讲的理论怎么落地。

假设我们有一个Python项目，需要在每次PR时运行测试和代码检查。在仓库里创建 .github/workflows/ci.yml：

name: CI Pipeline

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

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Set up Python 3.10
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install flake8 pytest
          if [ -f requirements.txt ]; then pip install -r requirements.txt; fi

      - name: Lint with flake8
        run: |
          flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics

      - name: Test with pytest
        run: |
          pytest --cov=. --cov-report=term-missing

这段配置做了三件事：
1. 拉起最新的代码。
2. 安装依赖和工具链。
3. 运行静态检查（flake8）和单元测试（pytest）。

当开发者提交PR时，GitHub Actions会自动拉起一个Ubuntu容器，执行这段配置。如果其中的任何一步返回值不是0，流水线就会标记为红色，PR页面上的状态卡片也会相应变化。

常见的CI失败原因

流水线跑起来之后，失败几乎是家常便饭。我根据经验总结了几个最常见的原因：

失败原因	根因	预防措施
环境不一致	开发环境和CI运行环境的库版本、系统配置不同	使用Docker或虚拟环境固定环境
依赖更新	外部依赖突然升级，接口不兼容	锁定版本号，使用锁文件
测试数据污染	测试用例之间共用数据库或文件，相互影响	每个测试用例独立准备和清理数据
超时	测试用例运行时间超过CI限制	拆分长测试，设置合理的超时时间
资源不足	CI runner并发过多，或测试消耗内存过大	合理分配runner资源，限制并发数

小结

持续集成不是什么高大上的技术概念。它就是一套确保代码质量的门禁系统。作为工程师，你要做的就是把门禁规则制定好、执行好，然后相信自己写的代码会被机器认真验证一遍。有了这个基础，后续的持续交付和部署才能稳稳落地。