第1章 CI概述与价值

持续集成到底在解决什么问题？

我先说个真实的事。
几年前我带一个团队做电商后台，五个开发并行写代码。大家各自埋头干了两周，到合并那天——好家伙，光冲突就解了三个小时。更糟的是，合并后的功能跑不通，订单接口返回全崩了。那个场景我记得很清楚：所有人围着会议室白板，指着鼻子互问“你改了我什么”。

这种“集成地狱”你们多半见过。持续集成（CI）就是用来干掉它的。

说白了，持续集成是一种软件开发实践：团队成员每天多次把自己的代码变更合并到主干，每次合入都通过自动化构建和测试来验证。 不是一周一次，也不是一天一次——而是每次提交都触发。

嗯，这里要注意：CI不是工具，不是Jenkins或GitLab CI，它是一种纪律。工具只是帮我们执行纪律。

核心原则：五个关键词

搞CI这么多年，我总结下来离不开这五条原则。你想想看，缺了哪条都容易翻车。

1. 频繁提交——每天至少一次。我见过团队要求每小时触发一次CI，效果反而不好（排队太长）。
   建议：每次完成一个原子功能就提交，不要攒。
2. 一次提交一个变更——别混着改。我曾有一次在同一个提交里修了bug、加了功能、还改了配置。CI跑挂了，根本不知道是哪块出的问题。
3. 自动化构建+测试——手工跑测试不是CI。人总会偷懒，机器不会。
4. 修复优先于新功能——CI变红，全队停手，先修好再继续。这条最难做到，但只有这样才能保持绿灯。
5. 主干同步——确保每个人的工作都基于最新的主干。我见过有人一周不拉代码，最后合并时改了几百个文件——那场面，嗯，不想回忆。

原则	为什么重要	反例（我踩过的坑）
频繁提交	减少冲突范围，快速定位问题	一周一次提交，合并三天
单次变更	问题归属清晰，回滚安全	混合提交导致CI失败后排查一小时
自动构建+测试	消除人为疏忽，保障回归质量	某次忘记跑单元测试，上线后核心接口报错
修复优先	保持CI通道畅通，防止质量问题堆积	曾经积压3个红牌，最后不得不回退整个版本
主干同步	避免大合并，减少冲突	同事两周没拉代码，合并时改了两百文件，崩溃

CI到底能带来什么价值？

你可能听过很多漂亮话：“提高质量”“加快交付”。我换个说法——CI能让你睡个安稳觉。

我经历过没有CI的时期，每次上线前大家都像在猜谜：代码能跑吗？会不会改坏了别的地方？有了CI之后，每次提交都有测试结果。红就是红，绿就是绿，清清楚楚。

• 减少集成风险——每天集成，冲突被控制在很小的范围内，不会出现“最后一天大爆炸”。
• 提升代码质量——每次提交都自动跑单元测试、静态检查、代码风格检查。烂代码根本进不了主干。
• 加快反馈速度——CI任务通常在几分钟到十几分钟完成。我一个同事的团队把CI控制在5分钟以内，反馈快到让人上瘾。
• 增强团队信心——看见CI徽章是绿色，大家就敢merge。这种感觉，没CI之前体会不到。
• 减少人工重复劳动——手动执行测试、手动部署到测试环境，这些本该由CI干。我见过一个团队每天花2小时做这些，上了CI后，每天省出来的时间都用来重构代码了。

持续集成的基本流程（一张图说清楚）

下面这张图概括了CI的经典流程。每次提交都会触发流水线，每个环节都自动化执行。

什么时候该上CI？

只要你们团队不止一个人写代码，就值得上。哪怕只有一个人，也建议跑CI——方便统一构建环境。我见过太多“在我电脑上能跑”的经典场景。CI帮我把环境差异暴露在明面上。

举个例子，一个微服务项目有12个模块，每个模块需要不同的Java版本。如果手动部署，配环境都配到头痛。CI里定义好每个模块的构建镜像，提交代码后自动选择对应的JDK版本，省心太多了。