6.2 持续集成与持续交付：自动检修线

6.2 持续集成与持续交付：自动检修线

有了台账与编组纪律，本节在它们上面铺自动检修线：每次提交自动触发构建与测试，主干随时处于可发布状态。持续集成（CI）与持续交付（CD）不是两件工具，是同一条流水线的两段抱负——CI 保证"合进去是好的"，CD 保证"随时能发出去"。本节讲流水线的骨架、一段真实的配置，以及集成变慢时的诊疗手法。

把期末考试改成每日打卡

传统项目的集成与验证攒在项目末尾，人称"集成大爆炸"：几个月的工作第一次真正拼在一起，缺陷集中爆发，工期在最后一段雪崩。CI 的药方是提高频率摊薄风险——每人每天至少集成一次，每次集成自动验证。缺陷间隔从"几个月攒一批"变成"几小时一粒"，定位范围从全项目缩到最近几次提交，修起来的成本完全不是一个量级。

一条典型的流水线骨架如下：

两段抱负的分界在最后一环：做到"可发布制品持续产出"是持续交付；再往前一步，制品自动部署到生产，是持续部署——要不要走最后一步取决于业务承受力（第 2.5 节的灰度纪律照常生效），多数团队停在"一键可发"就是合理终点。

一段真实的流水线配置

配置不用背，看懂结构就行。云梯的流水线配置核心段：

流水线配置 · 云梯平台（节选意译）
  触发：主干分支有提交 或 每小时定时
  阶段一 构建（约 3 分钟）
    拉取代码 → 安装依赖（走缓存）→ 编译
  阶段二 检查（约 4 分钟，与构建并行）
    静态规范检查 → 安全依赖扫描
    任一高危项 → 立即红灯，不进下一阶段
  阶段三 测试（约 6 分钟）
    单元测试全量 → 输出覆盖率报告
    覆盖率低于基线 → 警告（不阻断，趋势下滑才阻断）
  阶段四 部署验证（约 5 分钟）
    制品部署到测试环境 → 核心接口回归套件
  产物：带版本号的制品入库，测试报告与覆盖率随制品归档
  全程约 15 分钟，红灯即群通知，谁提交谁负责修复
​

三个设计决策值得留意：检查与构建并行省时间；覆盖率警告不阻断——门槛一刀切会逼人造"空测试"，趋势管理比绝对值诚实；红灯修复优先——团队约定主干红灯时所有人停下别的提交，先把干线修绿，这是"主干随时可发布"承诺的代价。

慢集成诊疗

流水线最常见的死法是越跑越慢：从一刻钟涨到半天，提交间隔被拉长，集成频率名存实亡。诊疗表按症状抓药：

⚠️ 另一个隐蔽的坑是"绿 but 空"：测试全过，是因为用例写得敷衍。流水线只保证"测过的都对"，不保证"该测的都测了"——这正是下一节检测线与巡检仪要补的课。

流水线自身的安全：凭据与供应链

流水线是高价值目标——它握着代码、密钥与生产部署的通行权。三道基础防线：凭据最小化——流水线只拿它需要的那几把钥匙，部署凭据与开发凭据严格分家，任何凭据不落日志、不进代码；制品不可变——进入生产的制品只能来自流水线产出，禁止"临时在服务器上打个补丁包"，保证线上运行的与库里存的是同一个东西；依赖来源锁定——构建拉取的依赖锁定版本并经私有仓库代理，上游被投毒时你的仓库是缓冲带。这三条的成本都不高，缺任何一条的代价却可能是一整次安全事件的底盘（第 7.3 节的安检清单会再点名一次）。

构建提速的账：缓存怎么算才真省

缓存是流水线提速的第一功臣，也是"假绿"的潜在源头。云梯给依赖缓存算过一笔账：未加缓存时构建阶段平均六分钟，其中依赖安装占四分钟；接入缓存后构建降至三分钟——省下的时间乘以全队每天几十次提交，每人每天净赚的时间相当可观。但缓存引入了新问题要一并管理：缓存失配——依赖清单改了而缓存没失效，构建用的是旧依赖，测试全绿却测试了错误的版本；对策是缓存键绑定依赖清单的哈希，清单一动缓存自动失效。省时间的账与失配的险一起算，缓存才是真省。

红灯文化：流水线的灵魂条款

流水线跑得怎么样，硬件只占一半，另一半在"红灯文化"——红灯出现后的团队行为。健康的红灯文化有三条约定：修复优先，主干红灯期间其他提交自觉等待，红灯不满一小时不升级、满一小时自动拉响响应；红灯实名，谁提交谁负责修复，修不动时升级求助不丢人，挂红灯逃跑才丢人；禁止压绿灯，跳过失败测试或注释掉用例来"变绿"按事故处理——绿灯的价值全在于不可收买。云梯统计过红灯文化的收益：主干红灯的平均存活时间从最初的五小时缩到二十分钟以内，而团队用于等待与修复的总时间反而下降——红灯短痛，好过绿灯掩盖下的长痛。

两个高频疑问

问：要不要让流水线快到极致，比如一分钟内？ 提速有边际：超过某个点，继续压缩靠的是削减验证深度，得不偿失。合理目标是让开发者愿意"每次提交都走流水线"——十五分钟内多数团队不会绕行，超过半小时绕行必然发生。先把"没人绕行"守住，再谈提速。

问：测试环境的资源有限，多人提交排队怎么办？ 两条路并行：短期用"合批"——几个待验提交合并进一次流水线，红灯再二分定位；长期把验证环境容器化按需拉起，跑完即毁。排队本身不全是坏事——它是推进"小步提交"的自然动力，但队伍一旦长到大家开始攒着不提交，就必须扩容了。

本节要点回顾

• CI 的本质是高频集成摊薄风险：缺陷几小时一粒，定位范围缩到最近提交。
• 流水线骨架：构建、检查、测试、部署验证、制品入库；CD 的终点由业务承受力定。
• 配置的三个决策：检查并行、覆盖率管趋势不管一刀切、红灯修复优先。
• 慢集成按症状诊疗：缓存、用例下放、范围选择、实名责任。
• 警惕"绿 but 空"：流水线保证测过的都对，不保证该测的都测。

检修线铺好了，还差检测手段本身——下一节给流水线装上检测线与巡检仪。