背景與問題
當一個程式碼庫每天湧入數百甚至上千筆變更時，如何確保主線分支永遠處於可建置、可通過測試的「綠燈」狀態，是一個比表面上看起來困難得多的問題。Uber 資深軟體工程師 Dhruva Juloori 在 InfoQ 與 QCon San Francisco 2025 的演講中，分享了 Uber 內部系統 SubmitQueue 的設計經驗。先說明規模：Uber 有超過 4,500 名工程師分布於十餘個全球開發中心，主要向六個 monorepo（單一大型程式碼庫）提交變更，其中 Go 儲存庫最為繁忙，其次為 iOS、Android 行動端儲存庫，以及 Java、Python 後端與 Web 儲存庫。這些儲存庫每月處理超過 65,000 筆變更，承載 1,000 個以上業務關鍵微服務、每月逾 100,000 次部署，程式碼總量超過 1.35 億行。
主線變紅的代價為何如此之高
主線變紅的根本原因在於：開發者各自測試自己的變更時是隔離的，但合併後的組合從未被驗證過。演講中以 Alice 與 Bob 為例：兩人從同一個綠色節點拉出分支，各自的 CI 檢查都通過，Alice 先合併後主線仍綠，但 Bob 合併時建置失敗，因為兩筆變更從未一起被測試。主線一旦變紅，代價是多方面的：功能與修補無法發布到生產環境，直接造成業務損失；其他開發者無法判斷自己的失敗是自己的問題還是主線本身的問題，浪費除錯時間；且當數百人同時提交時，回滾到最後一個穩定狀態變得極其複雜。Juloori 也指出，未來當 AI agents 大量並發提交程式碼時，這個問題只會更加嚴峻。
SubmitQueue 的核心機制
SubmitQueue 是 Uber 自 2018 年底開始使用的合併佇列系統，對開發者呈現為一個單一提交佇列，保證合理的落地 SLO、高效利用 CI 資源，並維持主線常青。系統由四個核心元件組成：enumerator 負責將待合併變更展開成所有可能建置組合的二元決策樹，內部稱為投機樹（speculation tree）；profiler 預測每個節點的建置時間並排序變更的落地順序；prioritizer 透過預測變更成功率，計算每個節點「需要被建置」的條件機率；selector 則挑選機率最高的節點排入 CI，依建置結果決定合併或拒絕。
為什麼需要投機樹？因為若佇列中有 n 筆變更，暴力驗證所有情境需要 2 的 n 次方減 1 個建置節點，資源上完全不可行。第一層優化是衝突分析（conflict analysis）：藉助 Buck、Bazel 等建置系統，判斷兩筆變更是否影響不相交的建置目標集合，若不重疊即視為互相獨立，可以並行合併，大幅削減樹的高度與節點數。第二層是機率式投機（probabilistic speculation）：每個節點的建置需求是前置變更成功與否的條件機率，系統只排程最可能需要的建置。
關鍵突破：bypassing large diff
但純粹的機率式排程帶來一個新問題：若佇列前方有一筆變更牽動大量建置目標、建置時間很長，後方的小變更即使所有投機建置都已跑完且結果一致，仍得空等前方結果才能決定要採用哪一個建置。Juloori 指出這會造成惡性循環——變更在佇列中待越久，與後續新進變更衝突的機率越高，樹就越大、需要建置的節點越多。解法是 bypassing large diff：若一筆變更的所有投機建置（涵蓋前方衝突變更成敗的所有組合）都已完成且產出相同結果，那麼合併順序在此數學上等價，如同加法或乘法的交換律，該變更可以立即落地，不必等待。排程策略也因此分為兩路：對可 bypass 的變更，優先排滿其所有投機建置以加速落地；對無法 bypass 的變更，則只排最可能需要的建置以節省資源。
機器學習與實際成效
這套機率計算仰賴機器學習模型：Uber 為每個儲存庫訓練分類模型預測變更成功率（準確率約 97%），以及迴歸模型預測建置時間（平均絕對百分比誤差約 5% 至 7%）。特徵包含變更層面因素如受影響建置目標數、diff 中的 commit 數與檔案變更數、pre-submit 檢查狀態，以及投機樹的動態特性如樹高、樹寬與節點位置。成效方面，bypassing large diff 結合建置時間預測的改進在 2024 年推出後，主要 monorepo 的 CI 資源使用量下降 53%，CPU 消耗降低 45%，變更落地時間加快 37%。相關技術細節可參考 Uber 發表的 EuroSys 2019 論文「Keeping Master Green at Scale」、ICSE 2025 論文「CI at Scale: Lean, Green and Fast」及 Uber 工程部落格文章。
影響與限制
SubmitQueue 展示的是一個務實的工程取徑：與其驗證所有可能組合，不如用建置系統的目標依賴關係做衝突分析、用機率模型排序建置優先級、再用交換律性質讓確定安全的變更提早落地。值得注意的是其限制：系統成效高度依賴建置系統能否精確給出變更的建置目標集合，以及 ML 模型對各儲存庫的預測品質；對於建置目標劃分粗糙或變更模式多變的環境，衝突分析的削減效果與成功率預測的準確度都可能打折扣。但對任何面臨高提交頻率、共享主線的大型團隊而言，這套「投機加機率加 bypass」的組合提供了一條已被大規模驗證的路徑。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。