持续集成

一句话

你以为持续集成（continuous integration，CI）是「装个 Jenkins、每次提交跑一遍构建」，其实这一章讲的是一条纪律：把「集成」从项目末期那个工期不可测的阶段，拆成每人每天多次的小动作——每次提交都触发一次完整构建加全套自动化测试，一旦变红，全队停下来先修好它。目标是把软件的默认状态从「它不工作、偶尔可用」翻转成「它随时可工作、偶尔坏一下」。原书把话说死了：CI 是一种实践，不是一个工具——效果取决于团队纪律，与你买了什么无关。

Glossary · 术语表

坐标

Part I「基础」的第 3 章，夹在第 2 章配置管理与第 4 章测试策略之间：第 2 章给的版本控制与自动化构建正是本章的前提，本章要求的那套快速自动化测试由第 4 章展开；而「提交 → 构建 → 提交测试」这一环，到第 5 章会被命名为部署流水线的提交阶段（commit stage）、成为流水线第一关。今天的对应物：GitHub Actions / GitLab CI / Jenkins、Google 的 TAP、GitHub 的合并队列（merge queue），以及被 DORA 反复验证的主干开发。

这章要解决什么

先摆个场景。20 人团队做一套交易系统，分 4 个小组各开一条特性分支，约定「做完这期再合」。三周后合并那天你会连撞三件事：语义冲突（两组各自重构了同一个接口，文本上不冲突、合起来跑不通）；合并工期完全估不出来，可能半天也可能一周；以及最贵的一件——某个根本性的设计矛盾其实第 3 天就写下了，你到第 21 天才知道。缺陷的修复成本随「写下」与「发现」的间隔单调上升，攒批集成等于把这个间隔人为拉到最大。

原书对旧世界的判词很冷：大多数项目里软件的默认状态是「它不工作」，只有偶尔一次集成后的短暂窗口它才可用。你失去的不只是效率，更是可预测性——无法承诺发布日期，无法回答「现在能不能上线」，也无法把任何测试结论安在一个具体版本上。

核心内容，讲透

一、定义：它要求的其实是两个动作

原书的定义可以拆成两句。第一句是机器做的：每当有人提交任何改动，整个应用都要被重新构建一遍，并对它跑一整套全面的自动化测试。第二句是人做的，也是真正的分水岭：一旦构建或测试失败，团队停下手上的事，立刻把它修好。

为什么第二句才是灵魂？因为只有它能保证「主干随时可工作」这个不变量成立。红灯若可以挂着，构建结果就退化成装饰性指标，CI 的价值当场归零。这条纪律的精神原型是精益生产的停线（stop the line）：任何人发现次品都能把整条产线拉停，看着损失产量，实则保证次品不会流到成品。

二、三个前提：没有它们，谈不上 CI

动手之前需要三样东西。版本控制：与项目有关的一切放进同一个版本库，而不是「代码在 Git、配置在某人机器上」（第 2 章的主题）。自动化构建：一条命令就能把整个应用构建并测试完，不依赖在 IDE 里点按钮——因为 CI 服务器只会敲命令。团队共识：所有人认同这是优先级最高的活动。第三样最难也最常被跳过，于是就有了「CI 天天亮着红灯、大家绕着走」的团队。

原书另给四条持续做下去的前提：经常签入（至少每天一次，越频繁越好）；建立全面的自动化测试（否则构建通过只说明「能编译」）；保持构建与测试过程简短（超过十分钟就有人不等它）；管好开发工作区（本地结果要和 CI 一致，否则「在我机器上是好的」会吃掉所有信任）。

三、一次提交的完整循环

把纪律落成动作：拉取主干最新代码并在本地合并 → 本地跑一遍构建和提交测试 → 绿了才提交 → CI 服务器从主干干净检出、重新构建、跑全套提交测试 → 红了全队停线，绿了这份制品才有资格进入下一关。

三个细节值得单独说。本地先跑一遍，是别让自己的疏忽变成全队的停线。CI 要从主干干净检出，因为本地总有你没意识到的残留（未提交的文件、本地装的依赖），只有一台从零开始的机器才能证明「换个人拿这份代码也能构建」。提交完不能立刻走人——否则你已沉浸在新任务里，回头修红灯代价大得多，期间别人还会往红灯上继续提交。

四、八条必备纪律

表 1 · 原书列出的必备纪律及其道理

原书还把测试驱动开发（TDD，先写测试再写实现）列进这一节，理由很实在：CI 的效力取决于那套自动化测试有多全面，而 TDD 是让测试真的被写出来的最可靠办法。

五、让反馈快：十分钟不是玄学

提交测试跑多久，直接决定这套纪律能不能活下来。原书给的门槛是十分钟：超过它，人们就开始「攒几个改动一起提交」，提交频率一降，每次红灯的嫌疑范围就变大，正反馈链条断掉。所以提交阶段只放最快、最能定位问题的那批检查，慢的往后放。

六、建议实践：让构建替你守住底线

原书另给几条「值得加进去」的做法，共同点是把口头约定变成会让构建变红的规则。架构违规即失败：约定「界面层不许直接访问数据库」，就写一条自动检查，违反即红——否则这类约定只会活在 wiki 上。慢测试即失败：给单个测试设时间上限，防止测试套件在几个月里悄悄从 3 分钟涨到 20 分钟。警告与风格违规即失败：一次性开全会淹死人，原书给的是棘轮（ratcheting）——把当前警告数记为基线，比基线多就变红，于是这个数字只能单调下降。

七、分支、DVCS 与分布式团队

本章成书于 2010 年，Git 这类分布式版本控制（DVCS）刚刚流行。原书的态度是「工具很好，但它让『不集成』变得太容易」：DVCS 鼓励开一堆本地分支、长期不推，而只要改动没并回那条共同的主干就不叫集成，不管你本地提交了多少次——这正是今天那句「用了 Git 不等于在做 CI」的源头。对分布式团队，原书的答案同样是集中的：一个中心化的 CI、一条共同的主干。

关键权衡与选型

表 2 · 三种分支策略：CI 的效力如何随分支寿命衰减

要点是：CI 的效力随分支寿命衰减。分支活一天，你损失一天的反馈；分支活三周，CI 测的其实只是那条分支自己，「绿」并不代表集成后也绿。

表 3 · 构建红了，四种处理方式

表 4 · 提交测试到底在哪跑

为什么重要 / 落到真实系统

这一章是全书那条流水线的第一块地基：没有「主干随时是绿的」，后面所有关卡都失去起点——你无法回答「拿哪个版本去做验收测试」。它也是今天工程实践的共同底色：GitHub Actions / GitLab CI / Jenkins 把「每次推送触发构建」变成默认配置，合并队列把「本地先绿」工程化成基础设施。面试里问「你们 CI 怎么做的」，考的往往不是工具名，而是本章这几条：多久提交一次、红灯谁负责、提交到反馈多长、有没有人注释过失败的测试。

易错点与争议

• 把 CI 等同于 CI 服务器。装了 Jenkins、每次推送跑构建，但人人在特性分支上待两周——那台服务器测的是各条分支，不是集成结果。判据只有一个：改动多久并回一次主干。
• 红灯常态化。一旦「主干红着也能干活」被默许，构建状态就不再携带信息；随之而来的是关告警、加重试、把失败测试标为忽略——这是 CI 最常见的死法。
• 片状测试是书里被低估的敌人。2010 年原书只立了「不许注释掉失败测试」，没预料到大规模测试套件里片状失败有多普遍。现代做法是补一层：自动识别、隔离出主路径、建单限期治理——既守住「不静默」，也不让全队被随机噪声停线。
• 提交测试的慢性肥胖。没人会一次让它慢 5 分钟，但每周多 10 秒，半年就破线。要设硬上限并让超时变红，否则十分钟规则只是口号。
• 与主流工作流的真实张力。今天多数团队用「特性分支 + Pull Request 评审」，与原书「每人每天直接并回主干」并不完全兼容。务实的调和是短命分支：寿命压到一天以内，配合合并队列在合并后复验。另一半代价常被忽略——主干开发要求半成品靠功能开关（feature toggle）藏起来，而开关本身会累积成要清理的技术债。
• 时代局限。书里的工具是 CruiseControl、Hudson，DVCS 还被当作新事物谨慎讨论；此后云端 CI、容器化构建、远端构建缓存、合并队列大幅改变了实现方式。但「小步、频繁、红了就停」这三条，十五年来没有过时。

要点