提交阶段

一句话

提交阶段（commit stage）是部署流水线的第一道关：每次提交自动触发，几分钟内编译、跑提交测试、做静态分析、打包出制品，然后给出一个红或绿的判决。它是整条流水线上唯一一道每个开发者每天都要亲自面对的关卡，所以这一章真正的主题不是「测什么」，而是怎么让这道关快到人肯等、准到人肯信——十分钟不是性能指标，是一条行为约束：一旦超过，开发者就不再等结果，持续集成的纪律会连锁崩塌。

Glossary · 术语表

坐标

本章在 Part II「部署流水线」里紧跟 Ch5：Ch5 画出了从提交到生产的整条传送带，本章放大它的第一格。往上，它继承 Ch3 持续集成的纪律（每天并回主干、红了停线）和 Ch4 测试策略的四象限（提交阶段承接「支持开发的技术面测试」那一格）；往下，Ch8 接手自动化验收测试。现实里它对应的是你每天打交道的东西：GitHub Actions 里那串 PR check、GitLab CI 的第一个 stage、Gerrit / Phabricator 的 pre-submit、Google 的 TAP、Meta 的 Sandcastle——你每天等的那几分钟转圈，讲的就是这一章。

这章要解决什么

Ch5 已经说清「越靠前的关卡越要快」，但没说这一关具体该长什么样。而这一关有个特殊身份：它是开发者与整条流水线唯一的日常接口。后面那些验收测试、容量测试、生产发布，多数开发者一周也未必看一眼；提交阶段是他们一天要面对好几次的东西。所以它一旦体验糟糕，被绕过的不是这一关，而是整套持续交付纪律。

糟糕有三种具体形态，本章逐个点名：

• 慢。算笔账：一个 8 人团队每天提交约 20 次。提交阶段 8 分钟，开发者可以坐等结果；涨到 40 分钟，一天 13 小时机器时间还排着队，而且没有人会等 40 分钟——他们会接着写下一个改动。于是红灯亮起时，上面已经叠了三四个人的提交，「是谁弄坏的」本身就要查半天。
• 没用。反馈只说「FAILED」，不说哪个测试、什么输入、怎么在本机重现。本章明确要求反馈必须可行动：失败信息要能直接指向该看哪段代码。
• 不可信。一旦「红了先重跑一次」成为团队本能，红灯就失去了含义——而红灯失去含义，等于这道关不存在。

不解决会退回 Ch1 那个旧世界：缺陷在代码库里躺上几周才被发现，写它的人早已忘了上下文，定位成本翻好几倍；或者反过来，团队被一套跑两小时还老抖的检查拖死，最后集体决定「先绕过去」。

核心内容，讲透

提交阶段到底做什么：一个输入，两个出口

定义很干净。输入：版本控制里的一次提交。做的事：编译 → 跑提交测试 → 做静态分析 → 把可部署的制品打包出来（必要时还包括建库表、生成安装包）。出口只有两个：要么红——立刻通知全组，按 Ch3 的纪律停线先修；要么绿——把制品、报告、元数据一起存进制品库，成为一个候选版本，继续往验收阶段走。

三样输出里最容易被忽略的是元数据：这个制品来自哪次提交、跑过哪些测试、结果如何。它是后面各阶段「晋级（promotion）」判断的依据，也是出事后一路查回去的绳子。

十分钟预算：一条关于人的约束

本章反复回到同一个数：提交阶段应当在十分钟内跑完（Ch3 的持续集成纪律给的也是这个数）。为什么是十分钟而不是二十？因为这个阈值管的不是机器，是人的行为：

• 十分钟内 → 开发者会等着看结果，红了当场修，上下文还在脑子里；
• 超过十分钟 → 开发者转去做下一件事，修复被推迟；后续提交叠上来，一次失败要在好几个人的改动里找元凶；
• 再久一点 → 团队开始「攒着一起提交」，批量变大——而批量变大正是 Ch1 里所有痛苦的源头。

这也解释了本章为什么拒绝把「所有测试」都塞进来：它不是要证明这版是对的，而是用最便宜的手段把明显是错的挡在门外。

算术：为什么提交测试不能碰数据库、界面和等待

一个纯内存的单元测试通常在毫秒级；一个每次都要连数据库、建表、清表的测试，单条轻松到50~100毫秒；一个通过真实界面点击的端到端测试，单条几秒到几十秒。乘以数量，差距就是数量级：

于是本章给出一串很具体的写法约束，全都服务于同一个目的——把每条测试的单价压到毫秒级：

• 避开界面（GUI）。界面测试慢、脆、依赖渲染时机，属于 Ch8 验收阶段的事。
• 避开数据库。把业务逻辑与持久化分开，用内存实现或替身顶替仓储层；碰真库的那部分留少量集成测试，放到后面的阶段跑。
• 避开异步。跨线程、跨进程、靠「等一会儿再断言」，是不稳定测试的头号来源。做法是把异步边界切开：同步地测业务逻辑，异步编排单独测。实在避不开，就把等待封装成带超时的轮询，而不是散落各处的固定 sleep——本章把这类硬扛的做法列为最后手段。
• 伪造时间。别让代码直接读系统时钟，把「现在几点」做成可注入的东西。否则「月末结算」「过期 30 天」这类逻辑要么测不了，要么只在某些日子红。
• 最小化状态。共享的全局状态、残留的库表数据会让失败依赖执行顺序——这类测试比没有测试更糟，因为它消耗信任。

测试替身与依赖注入：让一小块代码能被单独拎出来测

上面这些约束的共同前提是：被测的那块代码，得能把它的协作者换掉。这就是依赖注入的用武之地——协作者从构造函数或参数传进来，测试时就能塞一个替身进去。

本章对替身也留了一句提醒，这句今天更值钱：替身用过头，测试就被焊死在实现上。stub 只是喂返回值，测的仍是「输出对不对」；mock 却在断言「你必须按这个顺序调这几个方法」——你一重构内部实现（哪怕行为没变），这类测试就成片变红。测试是为了让你敢改代码；反过来让你不敢改，它就站到了自己的反面。

什么该让提交阶段变红

编译失败、提交测试失败，毫无争议地红。有争议的是静态分析：覆盖率跌破阈值、重复代码超标、圈复杂度飙升、新增警告——这些要不要让构建失败？

本章的立场是可以，而且往往应该——把团队认可的阈值编码进构建自动执行，好过写在 wiki 上没人看。但有个重要限定：这些指标是趋势指示器，不是目标本身。覆盖率尤其危险：它只告诉你哪些代码没被执行过，不告诉你被执行的那部分测得好不好——把所有断言删掉，覆盖率纹丝不动。所以它适合用来发现明显空白（某个新模块 0 覆盖），不适合当 KPI 追高。

输出：制品库、报告与元数据

绿灯之后的产物必须被妥善收好，这正是 Ch5「只构建一次」的落地点。制品不进版本控制——它是从源码派生出来的东西，塞进 Git 只会让仓库爆炸；用专门的制品库存放，用修订号命名，任何时候都能从生产上的一个包一路查回那次提交。报告（测试结果、覆盖率、静态分析）同样是一等公民产物，要放在全员点得开的地方——让分析结果可见本身就有价值，哪怕暂时不用它卡构建。

谁来养这道关

最后一条常被跳过，却最有组织意味：提交阶段属于开发团队，不属于「构建团队」。改动代码的人才知道该加什么检查、红灯意味着什么；交给一个不写业务代码的小组维护，结果必然是脚本跟不上代码，开发者也不再觉得红灯与自己有关。与之配套的是把构建脚本当一等公民代码：进版本控制、有人重构、有人评审。人数很多的团队可以设一个轮值的构建管家盯红灯、催修复、养脚本——注意是轮值，为的是分担而不是外包责任。

关键权衡与选型

表 1 · 一项检查该放提交阶段，还是往后推？

表 2 · 什么信号让构建变红，什么只警告

表 3 · 提交测试怎么对付数据库

表 4 · 测试替身怎么选

表 5 · 提交阶段超过十分钟了，怎么办

五张表背后是同一条判据：提交阶段的每一秒都要用「它平均能提前多久发现问题」来买。一项检查如果既慢又只能发现罕见问题，它就不该待在这道关里——但也别把它丢掉，往后放一格。

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

形态换了，逻辑一模一样。GitHub Actions 里挡在合并按钮前的那串 required check、GitLab CI 的第一个 stage、Gerrit 的 pre-submit verify、Bazel 的 small 测试与远端缓存、Google 的 TAP 与 Meta 的 Sandcastle——都是提交阶段的工程化实现。制品库（Nexus、Artifactory、容器镜像仓库）的存在理由就是本章说的「输出制品 + 元数据」；merge queue（合并队列）则补上了本书没展开的一环：多人并发提交时，逐个把改动放在合并后的状态上再跑一遍，避免两个各自绿灯的改动合到一起变红。

面试和架构评审里这几乎是标准考题。被问到「你们 CI 怎么做的」，能拿分的答法不是报工具名，而是四个事实：提交阶段几分钟？什么会让它变红？不稳定测试怎么处理、隔离区里现在有多少个？红了之后谁负责、平均多久修绿？

易错点与争议

• 把提交阶段当成「测试全集」。最常见的死法：每漏一个缺陷就往里加一组测试，十分钟慢慢变成四十分钟。这道关的时长是要主动守的预算，不是自然长成的结果——加之前先问：这项检查平均能提前多久发现问题？
• 把覆盖率当 KPI。它只说明哪些代码被执行过。追高的结果通常是一堆没有断言的测试：数字漂亮，缺陷照漏。用它找空白，别用它排名。
• 用「自动重跑」治不稳定测试。重跑是止痛药：它把真实的偶发缺陷（并发、时序）也一并掩盖掉。现在的普遍做法是隔离 + 限期修 + 统计不稳定率，而不是无限重试。
• mock 用过头。过度 mock 让测试断言的是「内部怎么实现」而不是「行为对不对」，重构必然成片变红，团队反而更不敢改代码——这也是「伦敦学派 vs 经典学派」争到今天的分歧所在。
• 时代局限。本书成于 2010 年，早于容器、Testcontainers、远端构建缓存与 ML 测试选择。「绝不在提交阶段碰数据库」今天可以放宽一点——起一个真库变便宜了；但十分钟预算这条一点没变，因为它管的是人不是机器。另一方面，本书基本没谈多人并发提交的相互干扰，这正是今天 merge queue 要解决的问题。
• 争议：单元测试该占多大比例。Google 的 80 / 15 / 5 是一种立场；另一派认为过度单测会锁死实现、真正的信心来自集成层。诚实的说法是比例取决于架构可测性与缺陷主要来自哪一层——但提交阶段必须由快到毫秒级的测试撑起，这点没有分歧。

要点