Uber 为加快 AI 时代的代码合并，放弃主干始终通过测试

Preetam Dwivedi 说，Uber 有六个主要单体仓库，超过 5,000 名贡献者，每周产生超过 36,000 次提交和 27,000 个 pull request。演讲主要关注规模最大、扩展挑战尤为突出的 Go 仓库。

两个变更分别针对同一个原始主干通过测试，组合后却可能失败。如果 A 先合并，而 B 没有针对包含 A 的状态测试，那么合并 B 就可能破坏主分支。数千名开发者同时工作时，这类问题会带来持续的恢复负担。

Uber 的 SubmitQueue 在合并前测试可能出现的未来状态，使变更合并时主干保持通过测试。它分析受影响的构建目标，让独立工作并行；根据历史结果优先进行可能有用的推测构建；并允许较小、已准备好的变更绕过较慢的大型变更。

Dwivedi 说，AI 生成的工作改变了请求到达速度：2026 年 1 月，高峰每小时合并约 90 次，到 3 月增至 130 次，两个月增长 44%。与此同时，合并耗时的第 95 百分位从约 30 分钟上升到三四小时，尽管主干依然保持通过测试。

Manjari Akella 介绍了三项应对措施：用准入控制调整流量，用延迟队列减轻开发者负担，以及通过放宽冲突恢复并行度。每项措施都有权衡。

准入控制按成本对请求分类，例如根据受影响的构建目标数量。繁忙时段允许小变更进入；影响多个目标的昂贵变更最初会被拒绝，以免它们阻塞活跃队列。

Akella 说，这让工作时间的吞吐量从每小时约 130 次升至 160 次，增长超过 20%。代价是开发者必须寻找空闲时段重新提交；维护广泛使用的共享库的开发者受影响尤其明显。

延迟机制用持久化等待队列取代拒绝。开发者只需提交一次，系统会在容量允许时将昂贵请求送入活跃队列，通常是在高峰期之外。这避免了手动重新安排时间，但并没有消除等待。

第三项改动处理构建目标重叠造成的串行化。如果 A 与 B 重叠、B 与 C 重叠，以此类推，整条关联链可能被视为一个组件，即使部分关联很弱，也会限制并行工作。

冲突放宽机制对重叠强度评分，而不是把所有重叠视为同等重要。SubmitQueue 保留较强的关联，移除较弱的关联，直到达到配置的并行度。分数综合考虑目标重叠和新增依赖关系。

在 Akella 的示例中，移除最弱的连接后，六个请求被分成三个独立队列。系统不会持续重建整张冲突图，而是在新请求进入时确定其关联，保留先前的决定和推测构建结果。

Akella 说，放宽冲突后，高峰吞吐量从每小时约 160 次升至约 250 次，有时更高。代价是部分组合在合并前没有一起测试，因此主干可能出错，合并后的验证也随之成为必要工作。

Dwivedi 回到 A 和 B 的例子：两个变更分别通过测试，但合并后的组合可能失败。Uber 使用 Stovepipe 在提交合并后进行验证，检测构建失败并启动恢复流程。

Stovepipe 跟踪两个引用。变更合并时，main 向前移动；verified main 则停留在最近已知通过验证的状态。如果提交 B 到 D 的组合验证失败，已验证指针就继续停留在 A。后续状态通过时，指针才向前移动。

当 Stovepipe 检测到失败，它会通知值班工程师。工程师准备修复或回滚，再通过 SubmitQueue 提交。Stovepipe 持续验证变化中的主干，并在某个状态通过后推进已验证指针。目前恢复过程仍需人工处理。

Dwivedi 说，截至 2026 年 10 月，高峰吞吐量达到每小时约 300 次合并，而合并耗时的第 95 百分位约为 30 分钟。讲者将其与 1 月每小时约 90 次的基线比较。SubmitQueue 和 Stovepipe 都以开放方式开发。

团队正在探索把相关变更批量处理以减少重复构建，按服务或项目而非整个仓库报告健康状态，并自动执行修复或回滚以缩短恢复时间。

最终采用的是混合策略：在合并前测试重要关联，放宽较弱关联以提高吞吐量，再验证合并后的状态。系统持续检查 main 的同时，下游可以使用已验证通过的状态。