6.2 CI 里的位次：提交前与流水线上

6.2 CI 里的位次：提交前与流水线上

本节摘要：持续集成与 TDD 是一对共生实践：每轮循环一次提交，流水线替全队跑一遍测试，红灯挡住合并。本节讲清位次设计——本地、提交、合并各守各的门，测试层级按速度对号入座，并给红灯立规矩。读完你应能设计一套人与机器分工明确的反馈体系，让"忘了跑测试"从事故变成不可能事件。

位次这个词借自乐队：指挥、首席、声部长各站各的位置，越位与缺位都会毁掉合奏。CI 里的位次同理——每种测试在正确的时机由正确的触发器执行，错位的代价立刻显形：把端到端塞进提交门，每人每次提交等二十分钟，团队很快学会绕过它；把单元测试只放在流水线上，本地红灯半小时后才见，反馈优势归零。

三道关卡的分工

图：CI 流水线位次图

图上有条容易忽略的暗线：同样的单元层在本地和流水线各跑一遍，这不是冗余。本地跑证明"在我的机器上对"，流水线的干净环境跑证明"在任何机器上对"——环境漂移（本地装了特殊依赖、配置文件被手改过）只有后者能抓到。两者齐备，"我本地是好的"才不再是吵架素材，而是可复现的工程事实。

一条提交的完整旅程

把位次串成时间线最直观。小林改折扣规则的一上午是这样流经三道门的：编辑器里保存，watch 三秒后受影响的四条用例转绿（本地门）——他知道自己没改坏这块；提交，钩子跑单元层全量，四十秒，绿，推送（提交门）；流水线被触发，关卡一的干净环境重跑单元层，三分钟，绿；关卡二起容器跑集成层，八分钟，绿——顺手抓到一处适配层解析偏差，本地替身演错了真网关的字段名，当场修正再推一轮；关卡三的旅程测试对预演环境跑完，六分钟，全绿，合并。上午的反馈总账：本地一次三秒救了他一次手滑，流水线一次八分钟抓了一个替身谎言——两类问题各归其位的门。这套时间线里的每个数字都值得抄回去对照自己的项目：哪一段在你的流水线里是慢的、缺的、或者根本没人盯的？

与发布节奏的配合

流水线不替你决定发布策略，但位次会影响它。主干常绿是位次设计的自然结果——三关全绿才能进主干，主干随时可发；发布前要不要额外加验证，取决于发布形态：持续部署的团队把关卡三做成发布的最后一道门，版本制团队在发布分支上再跑一轮全量。常见的错位是发布形态先行、流水线形同虚设：号称持续部署，主干却常年带红——那不是部署快，是反馈网破了。位次守得住，发布节奏才有得选；位次守不住，任何发布策略都是在雷区跳格子。

红灯纪律：挡合并不是拦截人

流水线的牙齿只有一颗：红灯挡合并。纪律要立三条才立得住。其一，修复红灯的优先级高于一切新开发——红灯存活的时间越长，"在红灯上继续开发"的坏习惯越长，最终演变成"红灯也没人管"。其二，谁提交谁负责，红不过夜；作者不在时最近提交者接手，团队永远只有一条红色分支。其三，跳过与豁免要走显式通道：跳过标记必须带理由与期限，无限期跳过的用例等于自欺，直接删掉更诚实。

三条纪律的执行成本其实很低，难的是立威：第一次红灯被无视时全队怎么反应，基本决定了纪律的寿命。老周团队的土办法有效且好复制——把"当前红灯"做成白板最上方的一行大字，写上 owner 与开红时间，红灯不灭字不掉。物理可见性比一百条群通知都难忽视。

闪红（时好时坏）是红灯纪律的天敌——它会训练团队"红一下没关系"，纪律从内部腐化。对闪红的正确处置是隔离而非容忍：标记进隔离名单，限期修复或删除，绝不允许它留在主干门槛上摇铃。

常见位次错误三例

位次设计 review 时的高发病例，各给一例。病例一：端到端挂在推送触发——每次推送全量旅程，流水线队列排到四十分钟后，红灯来时代码早已切走三件事。修法：旅程只挂合并门，推送只跑单元与集成。病例二：集成层起了真环境却没人消费——数据库容器起了、用例跑了，断言却全是替身式的"不抛异常就行"，花了真环境的钱买了假验证。修法：集成层用例必须至少断言一个"替身给不了的事实"（真实返回结构、真实约束行为）。病例三：红灯通知进了无人订阅的频道——流水线红灯只写进日志页面，当天没人看到，等发现时主干已经带红横穿三天的提交。修法：红灯通知直达提交者与值班人，频道里的红灯必须有认领动作。三个病例的共同点：位次在纸面上是对的，败在触发器、断言或通知的执行细节——设计 review 时拿这三问逐关卡过一遍：谁触发、断言什么、红灯去哪。

让流水线跑得动的工程细节

位次设计再好，跑不动就形同虚设。四个细节决定成败：并行——用例上到千条后开并行执行，前提是 3.1 的独立柱子立住了（并行是独立性的阅兵式，互踩的用例当场现形）；缓存——依赖安装与容器镜像缓存复用，流水线提速的大头永远在环境准备而非测试本身；分层触发——改动落在哪个目录决定触发哪些关卡，文档目录的变更犯不着跑端到端；产物留存——失败时的日志、覆盖率报告、容器现场要能取回，红灯定位不该依赖猜。

流水线配置的骨架（示意，各平台写法略有差异）：

关卡一 unit:   安装依赖 → 跑单元层 → 覆盖率门槛检查
关卡二 integration: 起数据库容器 → 跑集成层 → 拆容器留日志
关卡三 e2e:    部署预演环境 → 跑关键旅程 → 留失败截图
门槛: 三关全绿 → 允许合并；任一红 → 禁止合并
​

⚠️ 最伤团队的做法是"红灯了先把检查关掉，赶完这个版本再说"。检查一旦可以随手关，它的信用即刻破产——之后每条红灯都要先争论"这次是真的吗"，反馈体系的根基就塌了。

💡 流水线时长有个心理阈值：超过一刻钟，开发者就会切去干别的，回来时上下文全无——流水线越慢，个人产出越碎。把关卡一的目标定在五分钟内，是位次设计里最划算的一笔投入。

位次回顾

• 本地秒级门管循环，提交分钟门管底线，流水线三关卡管真相，合并门只认全绿。
• 单元层本地与流水线各跑一遍，抓的是环境漂移，不是冗余。
• 红灯纪律三条：优先修复、谁红谁修、豁免带期限；闪红隔离不容忍。
• 并行、缓存、分层触发、产物留存——四个细节决定流水线是否真的跑得动。
• 下一节回到循环的原点：编辑器里的即时反馈，把体感压到秒级。