第7章 稳定性与持续集成

第7章 稳定性与持续集成

本章要回答的三个问题：并行的套件天天产出红屏，怎么分辨真缺陷与假失败？失败现场怎么自动取证，让红屏自带答案而不是带来一轮会议？脚本怎么接入流水线与报告体系，让回归结果变成团队敢拍板的发布门禁？这是全册的收官之战——前面六章解决"跑得起来、跑得快"，本章解决"结果可信"。不可信的自动化比没有自动化更糟，因为它消耗的是团队对质量的信心。

为什么会有这一章

自动化项目最痛的失败模式，不是技术失败，而是信任失败。剧本通常这样展开：第一周全绿，大家很兴奋；第三周开始出现说不清的红，重跑就绿，没人深究；第二个月，红屏常态化，报告没人看；第三个月，发版时产品问"回归跑了为什么还出线上问题"，测试答"套件红了一半，我们人肉再验一遍"——自动化宣告名存实亡。

拆开看，信任崩塌有三根柱子。真假不分：环境抖动、时序竞态造成的假失败与真缺陷混在一起，红屏的信号价值归零。有败无证：失败时没有截图、日志与现场数据，定位一次失败要复现一次环境。结果无用：报告不能回答"这次能不能发"的决策问题，回归与发布脱节。本章五节就是给这三根柱子逐一换新：先建失败分类学（真假分层），再建取证体系（有败有证），再清脆弱性与反模式（减少失败的根源），最后接流水线与度量（结果进入决策）。

读完能解决什么

读完本章，你应当能：用四象限法给失败快速定性，并按类别选择重试、隔离或修复的处置路径；给工程挂上自动取证体系，让每条失败用例自带截图、日志与上下文数据；识别并清除工程里的脆弱性设计与反模式，把"偶发红"的存量降到可以治理的水平；把套件嵌入持续集成流水线，设计分层触发与门禁分级；搭建一套能回答发布决策问题的度量看板。五样能力对应五节，合起来是一个完整的"可信回归"体系。

各节怎么分工

这张闭环图是本章的总纲：执行只是起点，定性、处置、度量、门禁才是价值链。本册的工单传统在此收口——你现在应该能认出，闭环里每一步都对应前文的一件武器：定性靠 3.2 的排错归层，处置靠 6.2 的隔离，取证靠本节的四件套。

常见疑问

问：套件现在天天红几条，是先把第 7 章做完再修用例，还是先修用例？ 先建 7.1 的分类能力。没有定性框架，修用例就是随机射击——分清四类失败后，你会发现真正要修的缺陷类可能只有几条，其余是环境与时序的账，修法完全不同。

问：团队很小，本章的重体系会不会过重？ 分层取用：失败分类与自动截图是底线，小团队也该有（成本一天以内）；分层触发与看板可以等套件过百条再上。本章的每个机制都标注了它服务的规模阶段，按阶段取用，不必一次建全。

问：流水线平台各不相同，本章内容怎么落地？ 本章刻意用平台无关的概念展开——触发器、阶段、产物、环境变量是所有持续集成平台的通用词汇。落地时把四节的设计要点翻译成你所用平台的配置即可，思想不随平台漂移。

先决条件

本章需要一个已完成第 4 章结构改造、能以第 6 章方式执行的工程——在散装脚本上做稳定性治理是事倍功半的。7.4 的流水线部分以通用持续集成概念展开（触发器、阶段、产物、环境变量），不绑定具体平台；用过任一流水线工具即可平滑对照。

往下走到哪

可信回归体系建成，自动化就完成了从"工具"到"基础设施"的跃迁。下一章（也是全册最后一章）把视野拉回生态与演进：工具链全景、新版本特性与执行性能的持续优化——告诉你这套体系未来往哪里生长。