5.4 CI/CD：让灯自动亮、自动拦

本节摘要：把单元与集成测试接进持续集成，是"灯能自己亮"的物理化身。本节讲清 CI 的分层关卡怎么设置、红灯如何自动拦截，以及 CD 与测试的关系，并给出一份可持续的配置思路。

灯要自己亮，不能靠手点

前面学了红绿灯怎么装、怎么分层，但若每次都要人手工去跑，灯就没有把"及时性"自动化——漏一次就回到不设防。持续集成（CI）就是把这些灯接上自动开关：代码一提交、一合并，流水线自动拉起测试，红灯当场拦住，绿灯自动放行。这一步把"我为什么没测"这种懊恼从源头消灭。

CI 的分层关卡：别把所有灯塞一道门

流水线最常见的错误，是把单元、集成、端到端一股脑全塞进一道门里，跑一趟动辄半小时，所有人都在等构建。正确做法是按第 4.3 节的防守顺序，把灯放不同关卡，分档调度：

• 提交级（PR 内）：单元 + 快集成，秒级~分钟级，每一次提交都跑。
• 合并级（合并时）：集成深检 + 契约测试，分钟级，每次合并跑。
• 发版级（发版前）：端到端冒烟兜底，分钟级~小时级，按需跑。

每道关卡的负担不同、频次不同，换来的是"快的灯常开、贵的灯精跑"。

下面把这道"自动亮灯闸门"画出来。

红灯拦截的姿势：快速失败 + 明确定位

拦截不该只是"构建失败"四个字。好的拦截要做到"快速失败 + 明确定位"。快速失败：哪层先红，就该在哪层停下输出来，别让慢的端到端还傻傻跑完。明确定位：失败的报错信息要能一眼看出是哪个用例、哪一层、为什么，配合第 2.4 节的命名纪律，红灯自己就会报病情。这两点做不好，拦截就成了添乱的噪声。

一个 CI 配置思路的落地

背景：一个支付服务 CI 里单元、集成、端到端全放一起，构建常超时、没人看红灯。

操作：按三层分关卡重排——提交级只跑单元 + 快集成（内存库），合并级跑集成深检（容器 + 契约测试），发版级才跑端到端冒烟。

结果：提交级从半小时降到两分钟，红灯复位灵敏度大增，发版级的关键冒烟依然兜底。

解读：分档的价值不是"跑得少了"，而是"贵的灯被用在高价值的时刻"——这是 CI 设计的核心账。变式：规模再大，可以按服务拆并行管道，让同一级的多条构建同时推进。

CD 里的测试：做交付的门卫

在持续交付（CD）阶段，测试的角色是门卫：一边是绿灯放行、一边是自动化的发布动作。这时的测试更多关注"这包能不能交付"：冒烟、健康检查、迁移验证。注意 CD 与 CI 偏好不同的灯——CI 多跑单元和集成的密度，CD 多跑交付就绪的深度验证。两者节奏错开，才不会让一次发布被无谓的密集回归拖死。

红灯的种类决定处理姿势

接入 CI 久了会发现，红灯也不是一种，处理方式得跟着变。大致可分成三类。第一类是新改动直接引入的回归——红灯带编号、能定位到用例，这类要当场修掉才算数，别绕过绿灯硬合。第二类是"先红后绿"的环境噪声——重跑一次就绿，多半是外部抖动，处理原则是"允许一次自动重试，但记录重试次数"，连续多次闪红的用例要回第 3.4 节去查根因，而不是无限重试掩盖。第三类是"没改动也红"的存量问题——多半是依赖版本漂移或 schema 升级，需要回 3.3 检查版本对齐，而不是归到某个人头上。

给这三类红灯各配一种默认动作，能避免两个极端：既不让团队对每一条红灯都如临大敌地重写，也不让红灯因为总被 retry 而失去信用。红黄的判定标准是"是否描述了一个真实回归"，这一条始终别丢。

让 CI 更快，别只靠加机器

上一节讲了分档，但分档只是第一步，CI 速度仍有水分可挤。三个务实技巧：缓存依赖——把 pip/npm 依赖、编译产物缓存起来，避免每次全量重下载重编译；增量触发——只跑与被改代码相关的测试子集，哪怕是个粗糙的"按改动文件映射测试目录"都比全量省；并行分桶——把慢档测试拆成多个桶并行，摊平时间。这三样做下来，往往能再压缩掉大头的时间，让"提交后看到绿灯"的等待变得几乎无感。

不过要留个心眼：缓存和增量触发带来的提速，代价是"可能漏跑"。越是关键的接缝，越要保证它在全量档里一定有跑到的机会，别让优化把高风险路径悄悄挤出运行。速度是手段，守好回归才是目的。

CI 是一套流水线，也是一面照团队分工的镜子

分档、拦截、提速讲完，若只停留在"配好一个 pipeline"，就错过 CI 最有价值的一面——它其实是把团队对质量的真实分工摊开来给人看。哪道关卡被频繁跳过、哪层红灯常常没人接手、哪台构建老是排队，这些都直接反映"哪块质量没人真正承担"。比如"提交级不做任何测试就合入"的配置，并不仅仅是技术问题，更是团队默认"质量验收只靠最后一道门"的信号。所以每隔一段时间，值得像审视架构一样审视一次 CI：现在的关卡安排，是否和你们嘴上说的质量主张一致？

这种审视还有个副作用：它能指出"自动化表面之下"的隐性负担。谁在一次红灯里花了最多时间手动定位，谁就最该被分到"把那条红灯变成可自动判断"的任务。CI 的意义不止于停住坏代码，也在于把"哪一环最耗人"暴露成一目了然的数据，从而让改进有的放矢——这是纯粹的流水线配置给不了你的东西。

一点诚实的预期：CI 不会让人变懒，只会让偷懒现形

最后泼一点冷水：有人以为接上 CI 就能一劳永逸，其实 CI 不创造绿灯，它只是把"该亮而没亮的灯"摆到你眼前。没有 CI 时，你可以跳过测试、假装交付；有 CI 后，"没跑测试"变成了一次一次看得见的红灯或未过的门，偷懒从隐性地滑过，变成显性地暴露。所以真正的效果不是"测试不用人管了"，而是"该守的质量守住了，守不住的次数看得见"。别把 CI 当省心按钮，它是一面更诚实照见现状的镜子，好用与否，仍取决于你是否愿意随着红灯一起修正。

本节要点回顾

• CI 即自动开关：提交、合并、发版各配一道灯。
• 分档关卡：提交级单元快筛、合并级集成深检、发版级冒烟兜底。
• 拦截姿势：快速失败 + 明确定位，红灯自己会报病情。
• 贵灯精跑：深入测试留给高价值时刻，不拖慢日常。
• CD 当门卫：CD 偏交付就绪验证，与 CI 的密度节奏错开。

下一节我们谈"覆盖率与度量"——灯都接进 CI 了，怎么判断"全绿 ≈ 健康"，这把尺该怎么拿。