第29章：集成

为什么需要这一机制

把几块已经完成的工作放到一起时，真正困难的往往不是“能不能拼上”，而是出了问题能不能马上知道哪一块改变了结果。若所有工作都留到最后合并，问题会叠在一起，修复者只能猜。

本章把集成看成一条逐步验收的装配线：每次只带入一小批变化，留下构建和测试证据，发现偏离就停在最近的节点。这样做的价值不是让每次都成功，而是让失败范围小、原因可查、主线可回退。

核心合同

本节只使用三个量：b 是一次合入的构件数，f 是这些构件触及的依赖扇出，R 是当前批次的风险信号。

这个式子在说：一次变化越大、触及的依赖越多，单次集成越难隔离。它不是缺陷数量或工期预测器，而是帮助我们决定批次大小和验证频率的提醒。

集成合同还要固定四件事：构建版本、输入样本、验证断言和观察窗口。只改一个直接条件，先写预期，再观察第一个不一致的节点；如果为了让结果变绿而更换输入或跳过失败，实验就失去了裁决能力。

目录节点到四级证据

下面按原书目录保留 19 个节点。每个节点都说明它改变什么、为什么改变、实验能看见什么，以及读者如何用证据复核，而不是只让标题出现一次。

第29章 集成

集成的目标不是“最后一次合并成功”，而是让一个可工作的主线持续接纳小变化。每个构件都应有版本身份、输入契约和最小验证；每次通过都留下构建记录，每次失败都留下首个偏离。

本章的 构件基线 是后面所有比较的起点。没有基线，修复后的“通过”可能只是换了输入或环境，不能证明故障真的消失。

29.1 集成方式的重要性

集成方式决定反馈何时出现。阶段式做法把大量变化推到后面，单次失败包含很多候选原因；增量做法把变化切成小批，能让每个接口在仍接近原始上下文时被验证。

选择方式时不要只问“哪种流派更快”，而要问：项目能否保持主线可构建？每批变化能否在一个观察窗口内完成验证？失败时能否回退到上一个已知基线？这三个问题比口号更能裁决方案。

29.2 集成频率——阶段式集成还是增量集成

频率和批次大小是一对联动旋钮。每天合入一次并不自动等于增量集成：如果每天塞入一大批互相耦合的变化，反馈仍然很晚；反过来，小批次若几周才验证一次，也会积累环境漂移。

阶段式集成适用于接口尚未稳定、需要先搭建整体骨架的探索阶段，但必须用替身、契约和短周期构建限制未知范围。进入交付期后，更适合把“可回退的小批次”作为默认单位，并按风险调整频率。

阶段式集成

阶段式集成先建立较大的整体，再在某个阶段集中接通各个部分。它的优势是早期能看到完整拓扑，缺点是一次变化可能跨过多个责任边界，失败定位需要回溯很长的差异链。

使用它时要提前写出退出条件：哪些接口必须先用替身验证，哪一个构建是阶段边界，哪些冒烟断言必须在进入下一阶段前通过。没有退出条件的阶段式集成，很容易变成“等所有人都完成再试一次”。

增量集成

增量集成把故障定位距离压缩到最近一次变化。每一批都应该有清楚的输入、预期输出和回退点；批次通过后才继续，不通过就停止扩散。

它并不要求每次只合入一个文件，而是要求批次边界能被解释。一个批次可以包含同一功能所需的多个文件，只要它们由同一个断言验收，并能在失败时整体撤回。

增量集成的益处

增量的第一项收益是缩小搜索空间：失败发生在第 3 批，就先检查第 3 批及其直接依赖，不必重新审查整个项目。第二项收益是反馈更早，接口分歧还没有被后续代码掩盖。

第三项收益是主线具有可用的历史。每个已通过批次都能成为新的基线，团队可以在不丢失上下文的情况下回退、重放和比较。代价是需要纪律：构建、冒烟和回退不能被视为“以后再补”的文档工作。

29.3 增量集成的策略

策略的共同骨架是“选边界、合入、验证、记录、决定下一批”。差别在于第一批从哪一层开始，以及如何处理尚未完成的依赖。用替身隔离未完成部分，能避免为了等待一块代码而把所有集成推迟。

排列策略时可以记录每个候选接口的依赖扇出、失败代价、可观察性和回退难度。优先级不是永久不变的；一旦新的故障证据出现，就应重新排序，而不是继续执行原计划。

自顶向下集成

自顶向下从用户可见的主流程或控制层开始，逐层接入下方服务。它适合尽早验证“系统是否沿正确路径走通”，但下层尚未完成时需要替身；替身若只返回固定成功值，可能掩盖真实接口边界。

最小证据是：主流程调用了哪个接口、替身收到什么输入、真实实现接入后哪些断言仍保持不变。替身必须逐步收紧行为，不能因为演示通过就永远留在主线上。

自底向上集成

自底向上先验证底层构件，再逐层接通调用者。它适合底层算法、数据访问或协议适配风险较高的项目，因为问题会在较小的边界内暴露；代价是早期不容易看到完整用户流程。

要避免“底层都绿了所以系统一定可用”的推断。每接上一层，都需要新增跨层断言，确认数据格式、错误语义和资源生命周期没有在边界处改变。

三明治集成

三明治集成把自顶向下和自底向上夹在一起，从上层和下层同时推进，在中间边界会合。它能平衡用户流程反馈和底层风险，但中间层的责任最容易变得模糊。

因此要为会合点指定唯一的接口所有者和验收样本。若上下两路都通过、会合后才失败，不能把失败归咎于“中间层很复杂”，而应检查两侧对字段、时序和错误处理的合同是否一致。

风险导向的集成

风险导向的集成先处理“失败最贵、扇出最大、最难观察”的连接，而不是按组织图或文件名排序。风险导向的集成特别适合外部服务多、接口变化频繁或回退成本高的系统。

它不等于凭感觉挑一个“看起来危险”的模块。每次排序都要能指出依据：依赖数量、失败影响范围、已有断言、复现难度和回退动作。排序依据变了，集成顺序也应随证据变化。

功能导向的集成

功能导向按一条可验收的用户功能切片集成，从输入到结果接通最短的端到端路径。它能较早展示可交付价值，也便于把测试样本和产品行为绑定起来。

风险在于只挑“演示顺利”的功能。功能切片还必须覆盖错误路径、权限边界和跨功能共享的接口；否则第一条 happy path 通过，并不代表公共基础设施已经集成可靠。

T-型集成

T-型集成先做一个较窄但较深的端到端切片，再沿横向扩展更多功能。竖线用来证明关键路径确实能运行，横线用来逐步增加覆盖范围；两者都要持续回到同一构建和回归入口。

它的验收问题是“竖线是否真实，横线是否只是堆数量”。每增加一个横向分支，都要补一条与公共接口相关的断言，并确保原来的深路径仍然可重放。

集成方法小结

方法选择可以压缩成四个判断：风险高的连接先验证；批次要小到失败可归因；未完成依赖用可收紧的替身隔离；每批通过后立刻保留构建和回退证据。自顶向下、自底向上、三明治、功能导向和 T-型只是起点，不是免检清单。

如果团队无法回答“哪一个构建通过、哪个断言失败、从哪里回退”，说明方法还没有落到操作层。此时增加会议或增加一次大集成都不会自动补上缺失的证据。

29.4 Daily Build与冒烟测试

每日构建把集成从事件变成节奏。它要求版本可追踪、构建可重现、失败有人响应；“每天”只是上限提示，不是把不稳定的构建机械地发布出去。

冒烟测试应覆盖启动、关键接口和最短可交付路径。它的工作是快速拒绝明显坏的构建，而不是取代完整测试。冒烟失败时应停止继续接入，先保存日志、输入和首个断言。

哪种项目能用daily build过程？

适合 Daily Build 的项目通常具备：能自动或半自动生成构建；有稳定的最小启动路径；团队能在短窗口内响应失败；构建结果能回到具体提交和环境。项目规模不是唯一条件，小项目如果无法重复构建，也不适合装作已经有 Daily Build。

评估时先做一次干净构建，再故意破坏一个接口，观察失败能否在同一窗口被发现、定位和回退。如果失败只能靠手工拼装环境或依赖某个人记忆，先补构建可重复性，再谈提高频率。

持续集成

持续集成把“合入主线、自动构建、快速验证、反馈修复”变成日常事件。它不只是一个服务器开关：分支策略、测试入口、失败责任、构建产物和回退动作必须相互对应。

持续集成也不意味着每个检查都要在每次提交完成。可以把检查分为快速门和较慢的回归门，但两道门的边界、等待时间和失败升级路径必须公开，否则快速门会被误当成完整质量保证。

额外资源

额外资源要服务于当前瓶颈：构建不可重现时，补环境锁定和产物记录；接口频繁漂移时，补契约样本和版本兼容表；故障定位太慢时，补结构化日志、最小复现和回退脚本。

选资源前写出要解决的问题、使用期限和验收产物。读完一篇文章或装上一个工具不算完成；只有它改变了下一次构建的输入、断言或回退步骤，才算进入集成流程。

关键点

一个可靠的集成闭环是：固定 系统回归 的基线，选定小批次和顺序，构建并执行冒烟，在首个偏离处停止，修复后从同一基线重放，再决定是否接纳下一批。

最值得记住的不是某个策略名称，而是可追踪性：变化来自哪里，影响了哪些依赖，哪个断言先失败，修复后是否用同一输入回到了同一状态。没有这条链，绿色结果也可能只是一次偶然。

最小可重放实现

baseline = capture_baseline(version, inputs, assertions)
for batch in ordered_batches:
    build(batch, baseline.version)
    result = run_smoke(batch, baseline.inputs)
    record(batch, result)
    assert result.is_accepted or stop_at_first_failure(result)
assert replay(baseline) == baseline.expected_trace

这段伪代码表达的是本章的教学合同，不复制原书代码。真实记录至少要包含构建版本、批次清单、依赖扇出、首个失败断言、修复动作和复位后的轨迹。若复位改变了环境或输入，就不能把两次结果当成同一实验。

专属因果实验

猜一猜：把批次从 1 个构件调到 5 个，或关闭每日构建，哪个节点会先变红？先写下批次风险信号、预计失败位置和回退动作，再操作控件。三步都要观察一个直接条件、保存一个中间状态，并在最后重置实验。

故障诊断与误区

术语与边界

本章的六个操作术语是构件基线、增量集成、风险导向的集成、每日构建、冒烟测试和系统回归。它们分别指向实验的起点、批次边界、排序依据、构建节奏、快速拒绝门和完整行为证据；如果一个词只能指向目录标题，说明解释和验证仍未完成。

集成边界也要写清楚：程序级集成关注局部接口和调用链，产品级集成还要包含配置、数据与验收样本，系统级集成则要纳入外部服务、发布窗口和运行环境。边界扩大时，验证证据必须一起扩大。

本页小结

• 用批次大小乘依赖扇出估计集成风险信号，不把它冒充缺陷或工期预测。
• 按风险和可观察性选择顺序，用增量批次缩短失败定位距离。
• 用每日构建和冒烟快速反馈，再用系统回归确认跨接口行为。
• 保存构件基线、首个偏离和回退动作，修复后用同一输入重放验收。