[[200333]]

相對于一般公司，Google 使用了單一代碼倉庫，很多人不理解為什么這么做。本文作者是谷歌基礎設施小組的工程師，他對這個問題進行了詳細解讀。譯者在翻譯過程中受益良多，也相信大家看完之后會認為自己還活在史前時代。

早期 Google 員工決定使用集中式源代碼管理系統來管理代碼庫。這種方法已經在 Google 運行了 16 年以上，而今天絕大多數的 Google 軟件仍然存儲在一個共享的代碼庫中。

隨著 Google 開發軟件數量穩步增加，Google 代碼庫的規模也呈指數增長(圖 1)。 因此，用于管理代碼庫的技術也發生了顯著變化。

圖1

本文概述了該代碼庫的規模，并詳細介紹了 Google 定制的集中式代碼庫以及該模型的選擇原因。Google 使用自主開發的版本控制系統，管理公司的代碼庫，這個集中式系統是許多 Google 開發人員工作流程的基礎。

在這里，我們提供了系統和工作流的背景，這些系統和工作流程可以有效地管理和高效地使用這樣一個大型代碼庫。

我們將解釋 Google 的“基于 trunk 的開發”策略和支持系統，以及構建工作流程，還有保持 Google 的代碼庫健康的工具，包括用于靜態分析，代碼清理和簡化 code review 的軟件。

Google 規模

Google 95%的軟件開發人員使用的代碼庫滿足超大規模系統的定義[4]，該倉庫是可以成功擴展集中式代碼庫的證據。

Google 代碼庫包含大約十億個文件，并且具有約 3500 萬次提交的歷史(包含 Google 18 年所有的代碼提交)。該代碼庫包含 86TB 的數據，包括 900 萬個源文件以及大約 20 億行代碼。

文件總數還包括復制到發布分支的源文件、最新版本刪除的文件、配置文件、文檔和數據文件。請參閱此處的表格，以了解 2015 年 1 月以來 Google 存儲庫統計信息的摘要。

2014 年，每周在 Google 代碼庫中有 1500 萬行代碼被修改。相比之下，Linux 內核是一個大型開源軟件代碼庫示例，該代碼庫包含的 40,000 個文件中共有大約 1500 萬行代碼。[14]

Google 的代碼庫由來自世界各國數十個辦事處的 25,000 多名 Google 軟件開發人員共享。在典型的工作日，他們通常會對代碼庫進行 16,000 次更改，另有 24,000 次更改由自動化系統提交。

每天，代碼庫提供數十億次文件讀取請求，峰值每秒大約有 80 萬個查詢，工作日平均每秒大約有 50 萬個查詢，大部分流量來自 Google 的分布式構建和測試系統。

圖2

圖 2 報告了 2010 年 1 月至 2015 年 7 月主要代碼庫每周提交數量。

圖3

圖 3 報告了在同一時間段內每周向 Google 主代碼庫提交數量?？偺峤坏拇a包括交互式用例或用戶數據以及自動化提交的代碼，假期(如圣誕節和元旦，美國感恩節和美國獨立日)會有大幅度提交行數下跌。

2012 年 10 月，Google 代碼庫增加了對 Windows 和 Mac 用戶的支持(之前僅支持Linux)，現有的 Windows 和 Mac 代碼庫與主代碼庫合并，Google 的代碼庫合并工具將所有歷史變更歸因于其原始作者。

因此[圖 2]圖形中的相應凸起，這種合并的效果在[圖1]中也是顯而易見的。

根據每周提交的圖表顯示，到2012年之前，提交率由用戶主導，此時 Google 將代碼庫改為私有實現。如下所述，在此之后，自動提交到存儲庫的代碼開始增加，代碼提交的增長主要是由于自動化。

管理這種規模的代碼庫和開發對于 Google 來說是一個持續的挑戰，盡管經過幾年的試驗，Google 還沒有找到一個商業上可用的或開放源代碼版本控制系統，以便在單一代碼庫中支持這種規模，Google 解決此問題的專有系統是 Piper。

背景

你在審視使用單一代碼庫的優缺點之前，需要了解一些 Google 工具和工作流的背景。

Piper and CitC

Piper 是一個大型代碼庫，在標準的 Google 基礎設施上實現，最初是基于 BigTable，現在是基于Spanner。[3] Piper 分布在全球 10 個 Google 數據中心，依靠 Paxos [6]算法來保證副本一致性。

該架構提供了高冗余，并有助于優化 Google 軟件開發人員的延遲。此外，緩存和異步操作可以隱藏大量網絡延遲。這很重要，因為獲得 Google 云工具鏈的全部優勢需要開發人員在線。

在推出 Piper 之前，Google 主要依靠一臺 Perforce 實例(加上自定義緩存基礎架構[1]，提供服務超過 10 年)。繼續擴展 Google 代碼庫是開發 Piper 的主要動力。

由于 Google 的源代碼是公司最重要的資產之一，因此安全功能是 Piper 設計的關鍵考慮因素。Piper 支持文件級訪問控制列表，所有Piper用戶都可以看到大部分代碼庫，也可以更嚴格地控制重要的配置文件或關鍵算法的文件。

可以對 Piper 中的文件進行讀寫訪問。如果敏感數據文件被意外地提交給 Piper，則可以清除該文件，讀取日志允許管理員確定是否有人在刪除問題文件之前訪問過該文件。

圖4

在 Piper 工作流程中(見圖 4)，開發人員在更改代碼庫之前創建文件的本地副本，這些文件存儲在開發人員擁有的工作區中。

Piper 工作區與 Apache Subversion(Git 中的本地克隆)或 Perforce 中的客戶端的工作副本相當，Piper 代碼庫中的更新可以根據需要被拉入工作空間并與正在進行的工作進行合并(見圖 5)。

圖5

可以與其他開發人員共享工作空間快照以供審核，工作空間中的文件僅在經過 Google code review 過程后才會提交到中央代碼庫。

大多數開發人員通過名為 Clients in Cloud 的系統或 CitC 訪問 Piper，該系統由基于云的存儲后端和 Linux FUSE [13] 文件系統組成，開發人員將他們的工作空間看作是文件系統中的目錄，將更改覆蓋在完整的Piper庫之上。

CitC 支持代碼瀏覽和 Unix 工具，無需本地克隆或同步狀態。開發人員可以在 Piper 存儲庫中的任何地方瀏覽和編輯文件，只有修改的文件才存儲在其工作空間中。

這種結構意味著 CitC 工作區通常僅消耗少量存儲(平均工作空間少于 10 個文件)，同時向開發人員呈現整個 Piper 代碼庫。

對文件的所有寫入都作為快照存儲在 CitC 中，使得可以根據需要恢復以前的工作階段，可以明確命名，恢復或標記快照以供審核。

CitC 工作區可以在任何連接到云的機器上使用，從而輕松切換機器并且不間斷地工作，這也使得開發人員可以在 CitC 工作區中查看彼此的工作，將所有正在進行中的工作存儲在云中是 Google 工作流程的重要組成部分。

工作狀態可用于其他工具，包括基于云的構建系統，自動測試基礎架構以及代碼瀏覽，編輯和查看工具。

有幾個工作流程利用了 CitC 中未提交代碼的特性，使軟件開發人員能夠更有效率的使用大型代碼庫。

例如，當發送更改 code review 時，開發人員可以啟用自動提交選項，這在代碼作者和審閱者處于不同的時區時特別有用。review 被標記為完成時，測試將會運行。

如果可以通過測試，代碼將被合并到代碼庫，不需要進一步的人工干預，Google 代碼瀏覽工具 CodeSearch 支持使用 CitC 工作區進行簡單的編輯。

瀏覽資料庫時，開發人員可以點擊按鈕進入編輯模式，并進行簡單的更改(例如修改打字或改進評論)。然后，在不離開代碼瀏覽器的情況下，他們可以將自己的更改發送到適當的審閱者，并啟用自動提交。

Piper 也可以在沒有 CitC 的情況下使用，開發人員可以將 Piper 工作區存儲在本地計算機上，Piper 還可以和 Git 互操作。目前，超過 80% 的 Piper 用戶使用 CitC，由于 CitC 有許多優勢，使用率持續增長。

Piper 和 CitC 可以保證在 Google 代碼庫的規模下，使用單一代碼庫進行有效的工作。這些系統的設計和架構都受到 Google 采用的基于 trunk 的開發模式的影響，如下所述。

基于 trunk 的開發

Google 在 Piper 源代碼庫之上實施基于 trunk 的開發。Piper 用戶絕大多數在“head”或最新版本的“trunk”或“mainline”代碼副本中工作，對代碼庫的更改是串行的。

基于 trunk 的開發與中央代碼庫的組合定義了單一代碼庫模型，在任何提交之后，其他所有開發人員都能看到更改。Piper 用戶對 Google 代碼庫的一致視圖是提供本文后面描述的優勢的關鍵。

圖6

基于 trunk 的開發是有益的，因為它避免了合并長支鏈分支時的痛苦。盡管代碼分支通常用于發布上線，但是在 Google 代碼分支支持的不好。

通常在 trunk 上開發 bug fix 和必須添加到版本中的增強功能，然后將其引入到 release 分支中(參見圖 6 )。

由于需要保持穩定性并限制發布分支上的流失，所以 release 通常是“head”的快照，根據需要從”head”拉出可選的少量帶代碼，在 branch 和 trunk 上并行開發的長壽命 branch 是非常罕見的。

Piper 和 CitC 可以在 Google 代碼庫的規模下，使用單一源代碼庫進行有效的工作。

當開發新功能時，新舊代碼路徑通常同時存在，通過使用條件標志來控制。這種技術避免了開發分支的需要，并且通過配置更新來打開或者關閉功能。

雖然開發人員還需要一些額外的復雜性，但是避免了開發分支合并問題，標志翻轉使得用戶切換具有問題的新實現變得更加容易和快捷。

該方法通常用于項目特定的代碼，而不是通用的庫代碼，最終會刪除標志和舊代碼。Google 使用類似的方法來對不同代碼做測試，這樣的 A / B test 可以從代碼性能得到與產品變化相關的參數。

Google 工作流程

需要幾種最佳實踐和支持系統，以避免在基于 trunk 的開發模式中碰到的問題。例如，Google 有一個自動測試基礎設施，可以在幾乎每個提交上啟動所有受影響的依賴項測試。

如果一次代碼更改造成構建破壞，系統就會自動撤消更改。為了減少發生的錯誤代碼的發生率，高度可定制的 Google “預提交”基礎架構可以在更改代碼添加到代碼庫之前自動進行測試和分析。

針對所有更改運行一組全局預先提交分析，代碼所有者可以創建僅在其指定的代碼庫中的目錄上運行的自定義分析，僅有一小部分非常低級別的核心庫使用 branch 的機制，以保證在新版本暴露給客戶端代碼之前執行其他測試。

鼓勵代碼質量的一個重要方面是期望在提交到代碼庫之前對所有代碼進行 review。大多數開發人員可以在代碼庫的任何地方查看和建議更改(除了一組更加精心控制的高度機密代碼之外)。

不熟悉的開發人員更改相關代碼的風險通過代碼 review 過程和代碼所有權的概念得到緩解，Google 代碼庫以樹結構布局，每個目錄都有一組所有者控制是否接受目錄中文件的更改。

所有者通常是在相關目錄中處理項目的開發人員，變更通常會從一位開發人員收到詳細的代碼審查開始，從而評估變更的質量，以及所有者的認可批準，評估變更對的適用性。

代碼 review 者會對代碼質量方面進行評論，包括設計，功能，復雜性，測試，命名，評論質量和代碼風格。

Google 已經編寫了一個名為 Critique 的代碼審查工具，允許審閱者查看代碼的演變，并對任何一行的更改進行評論。它鼓勵進一步的修改和 review，以達到所有者的要求。

Google 的靜態分析系統(Tricorder [10])和預提交基礎設施還可以在 Google 代碼審查工具中自動提供有關代碼質量，測試覆蓋率和測試結果的數據。這些計算密集型檢查被定期觸發，發送代碼修改以供 review。

Tricorder 還為許多錯誤提供了修改的建議，這些系統提供重要數據，以提高代碼審查的有效性，并保持 Google 代碼庫的健康。

Google 開發人員小組不時進行代碼清理，以進一步維護代碼庫的健康。執行這些更改的開發人員通常將過程分為兩個階段。

首先進行大的向后兼容的更改，一旦完成，可以進行第二個較小的更改以刪除不再引用的代碼，Rosie 工具支持這種大規模清理和代碼更改的第一階段。

使用 Rosie，開發人員可以創建一個大補丁。Rosie負責將大補丁分成較小的補丁，獨立測試，發送出去進行代碼 review，并在通過測試和代碼審查后自動提交。

Rosie 根據項目目錄行拆分補丁，依靠前面描述的代碼所有權層次結構將補丁發送給適當的審閱者。

圖7

圖 7 報告了每月通過 Rosie 進行的更改次數，表明 Rosie 作為 Google 大規模代碼更改的工具的重要性，使用Rosie需要注意其使用成本。

隨著 Rosie 的流行度和使用率的增長，顯而易見，必須建立一些控制措施，以將 Rosie 的用途限制高價值變化中。

2013 年，Google 通過了正式的大規模變化 review 流程，導致了從 2013 年到 2014 年的 Rosie 數量的減少。在評估 Rosie 變更時，評審委員會將變更的收益與審閱者時間和存儲庫流失的成本相平衡，我們稍后更仔細地研究類似的權衡。

總而言之，Google 開發了許多工具來支持其龐大的代碼庫，包括基于 trunk 的開發，分布式源代碼存儲庫 Piper，工作區客戶端 CitC 以及工作流支持工具 Critique，CodeSearch，Tricorder，和 Rosie，我們在這里討論這個模型的利弊。

分析

本節概述并擴展了單一代碼庫的優勢以及與維護此類模型規模相關的成本。

優點

支持超大規模的 Google 代碼庫，同時為成千上萬的用戶服務，保持良好的性能是一個挑戰，但由于其引人注目的優勢，Google 已經擁抱了單一代碼庫。

最重要的是它支持：

• 統一版本。
• 廣泛的代碼共享和重用。
• 簡化依賴關系管理。
• 原子變化。
• 大規模重構。
• 團隊合作。
• 靈活的團隊邊界和代碼所有權。
• 代碼可見性和清晰的樹結構，提供隱含的團隊命名空間。

單一代碼庫提供統一的版本控制和單一代碼來源。對于哪個存儲庫托管文件的權威版本，并不存在任何混淆。

如果一個團隊想要依賴另一個團隊的代碼，可以直接依賴，Google代碼庫包含大量有用的庫，而單一代碼庫可以引導廣泛的代碼共享和重用。

Google 構建系統[5]可以輕松地在目錄之間包含代碼，從而簡化依賴關系管理。對項目的依賴性的更改會觸發依賴代碼的重建，由于所有代碼都在相同的存儲庫中進行版本控制，所以只有一個版本，也不關心依賴關系的獨立版本。

圖8

最值得注意的是，該模型允許 Google 避免當 A 依賴于 B 和 C 時發生的“鉆石依賴”問題(見圖 8)，B 和 C 都依賴于 D，但 B 需要版本 D.1 和 C 需要版本 D 0.2。

在大多數情況下，可能很難在不導致破壞的情況下發布新版本，因為所有調用方必須同時更新，當庫調用者托管在不同的存儲庫中時，這種更新很困難。

在開源世界中，依賴關系通常被庫更新所破壞，查找所有共同工作的依賴庫版本都是一個挑戰。更新依賴關系的版本對于開發人員來說可能是痛苦的，延遲更新可能會變成非常昂貴的技術債務。

使用單一代碼庫，對于更新庫的人來說，在同一時間更新所有受影響的依賴關系更容易。依賴引起的技術性債務在作出變更時立即予以償還，基礎庫的更改將立即通過依賴關系鏈傳播到依賴于庫的最終產品中，而不需要單獨的同步或遷移步驟。

請注意，如下所述，在源/ API 級別以及二進制文件之間可能存在鉆石依賴問題。[12]在谷歌，通過使用靜態鏈接避免了二進制問題。

進行原子變化的能力也是整體模型的一個非常強大的特征，開發人員可以在一致的操作中，對代碼庫中的數百或數千個文件進行重大變更。例如，開發人員可以在單個提交中重命名類或函數，但不會破壞任何構建或測試。

在單一代碼庫中，或至少在集中式服務器上，所有源代碼的可用性使得核心庫的維護者在提交高影響力更改之前可以更輕松地執行測試和性能基準測試。

 

這種方法對于探索和測量高度破壞性變化的價值是有用的， 一個具體的例子是評估轉換 Google 數據中心以支持非 x86 機器架構的可行性的實驗。

由于 Google 代碼庫的結構，開發人員無需決定代碼庫邊界，工程師不需要“branch”共享庫的開發，或者跨倉庫合并來更新代碼。

團隊邊界是流動的，當項目所有權更改或計劃合并系統時，所有代碼都已在同一個庫中。這種環境使代碼庫的循環重構和重組變得容易，移動項目和更新依賴關系可以原子地應用于代碼庫，并且受影響代碼的開發歷史保持不變且可用。

單一代碼庫的另一個屬性是容易理解的代碼庫的布局，因為它被組織在單個樹中，每個團隊在主樹中都有一個目錄結構，有效地充當項目自己的命名空間。

每個源文件都可以通過單個字符串唯一標識，該文件路徑可選地包含修訂版本號，瀏覽代碼庫，很容易了解任何源文件如何適用于代碼庫。

Google 代碼庫不斷發展，更復雜的代碼庫現代化工作(例如將其更新為 C++ 11 或推出性能優化[9])通常由專用的代碼庫維護者集中管理。

這樣的努力可以觸及五十萬個變量聲明或函數調用點(分布在數十萬個源代碼文件中)，由于所有項目都集中存儲，所以專家團隊可以為整個公司做這項工作，而不是要求很多人開發自己的工具。

舉個例子

請考慮 Google 的編譯器團隊，他們會確保 Google 的開發人員使用最新的工具鏈，并從生成的代碼和“可調試性”的最新改進中獲益。

單一代碼庫使編譯團隊能夠全面了解 Google 如何使用各種語言，并允許他們進行代碼庫范圍的清理，以防止更改破壞構建。

這大大簡化了編譯器驗證，從而減少了編譯器發布周期，并使 Google 有可能安全地執行編譯器版本(通常每年對 C ++ 編譯器來說超過 20 個)升級。

通過對夜間運行性能測試和回歸測試產生的數據進行分析，編譯器團隊可以將默認編譯器設置調整為最佳。

例如，谷歌的 Java 開發人員都看到他們的垃圾回收(GC) CPU 消耗量下降了50%以上，而且 GC 停留時間從 2014 年到 2015 年下降了 10%-40%。另外，當軟件發現錯誤，編譯器團隊有可能添加新的警告以防止錯誤重復發生。

結合此更改，他們會掃描整個存儲庫以查找并修復正在存在該問題的其他實例，然后再轉到新的編譯器錯誤，過去的實踐證明編譯器拒絕有問題的代碼大大提升了 Google 的代碼運行狀況。

將所有源代碼存儲在通用版本控制存儲庫中可以使代碼庫維護者有效地分析和更改 Google 的源代碼。像 Refaster [11] 和 ClangMR [15] (通常與 Rosie 一起使用)這樣的工具利用 Google 源代碼的單一視圖來執行源代碼的高級轉換。

單一代碼庫捕獲所有依賴關系信息，可以放心地刪除舊的 API。因為可以使所有調用者使用新API，在任何給定時間，通過確保更改的原子性和整個存儲庫的單一全局視圖，單一代碼庫極大地簡化了這些工具的開發過程。

鼓勵代碼質量的 Google 文化其中一個重要方面是期望在提交到代碼庫之前對所有代碼進行審核。

成本和權衡

注意單一代碼庫絕不意味著整體化的軟件設計，使用這個模型涉及必須考慮一些缺點和權衡。

這些成本和權衡分為三類：

• 開發和執行的工具投資。
• 代碼庫復雜性，包括不必要的依賴性和代碼發現的困難。
• 達到代碼健壯性的努力。

在許多方面，單一代碼庫導致更簡單的工具。然而，還需要將工具規模擴展到代碼庫的規模。

例如，Google 已經為 Eclipse 集成開發環境(IDE)編寫了一個自定義插件，以使 IDE 能夠使用大型代碼庫。

Google 的代碼索引系統支持靜態分析，代碼瀏覽工具中的交叉引用，以及 Emacs，Vim 和其他開發環境的豐富的 IDE 功能，這些工具需要持續的投資來管理日益增長的 Google 代碼庫規模。

除了建立和維護可擴展工具的投資外，Google 還必須承擔運行這些系統的成本，其中一些是非常計算密集型的。

許多 Google 的內部開發人員工具套件，包括自動化測試基礎架構和高度可擴展的構建基礎設施，對于支持單一代碼庫的規模至關重要。因此，必須權衡如何運行這些工具以平衡執行成本與提供給開發人員的數據的好處。

單一代碼庫更容易理解代碼庫的結構，因為在依賴關系之間沒有跨倉庫邊界。然而，隨著規模的增加，代碼查找變得更加困難，因為像grep這樣的標準工具基本不可用。

開發人員必須能夠探索代碼庫，找到相關的庫，并了解如何使用它們以及誰編寫它們，庫作者經常需要了解他們的 API 如何被使用。

這需要對代碼搜索和瀏覽工具的重大投資，Google 已經發現這種投資非常有益，提高了所有開發人員的生產力。[9]

訪問整個代碼庫鼓勵廣泛的代碼共享和重用，有些人會認為，這種模式依賴于 Google 構建系統的可擴展性，使得添加依賴關系變得太容易，并且減少了軟件開發人員設計穩定且精心設計的 API 的動機。

由于創建依賴關系的輕松，通常團隊不要考慮其依賴關系圖，使代碼清理更容易出錯。不必要的依賴可能會增加項目對下游構建破壞的風險，導致二進制文件膨脹，并在構建和測試中創造額外的工作，此外，維護遺留項目會導致生產力下降。

Google 的試圖控制不必要的依賴，已經有工具幫助識別和刪除不需要依賴關系。還存在用于識別未充分利用的依賴關系或識別不需要的庫的工具。

工具 Clipper 依賴于一個自定義的 Java 編譯器來生成一個精確的交叉引用索引，然后，它使用索引構建可達性圖，并確定從不使用什么類。

Clipper 可以通過幫助開發人員找到相對容易刪除或分解的目標來指導依賴重構的工作。

開發人員可以在一個一致的操作中，通過存儲庫中的數百或數千個文件進行重大變更。

依賴重構和清理工具是有幫助的，但理想情況下，代碼所有者應該能夠防止創建不必要的依賴關系。

2011 年，Google 開始推廣 API 可見性的概念，將新 API 的默認可見性設置為“私有”，這迫使開發人員明確地標記 API，以供其他團隊使用。從 Google 的大型代碼庫的經驗中學到的教訓應該是盡快實施，以鼓勵更好的依賴結構。

大多數 Google 代碼可供所有 Google 開發人員使用，這導致了一種文化，一些團隊希望其他開發人員閱讀他們的代碼，而不是為他們提供單獨的 API 文檔。

這種做法有利與弊，開發人員有時會閱讀 API 代碼，最終依賴于底層的實現細節，這種行為可能會為那些不愿意向用戶暴露的細節的團隊提供一些維護負擔。

該模型還要求團隊在使用開源代碼時相互協作，存代碼的一個區域保留用于開源代碼(在 Google 開發或外部開發)。

為了防止依賴沖突，需要確保在任何給定的時間只有一個開源版本可用，使用開源代碼的團隊在進行依賴升級時，會花時間處理新版本的開源庫。

Google 投入巨大的努力來維護代碼健康，以解決與代碼庫復雜性和依賴關系管理相關的一些問題。

例如，專用工具會自動檢測和刪除死碼，分割大量重構，并自動分配代碼評估(如通過 Rosie)，并將 API 標記為不推薦使用。

需要人力運行這些工具并管理相應的大規模代碼更改，審查代碼庫范圍內的清理和其他工作引起的持續簡單重構也會產生成本。

備擇方案

隨著像 Git 這樣的分布式版本控制系統(DVCS)的普及和使用越來越多，Google 考慮是否將 Piper 轉移到 Git 作為其主要的版本控制系統。

Google 的一個團隊專注于支持 Git，Google 在 Google 主代碼庫之外由 Google 的 Android 和 Chrome 團隊使用，由于外部合作伙伴和開源協作，使用 Git 對于這些團隊很重要。

Git 社區強烈建議開發人員擁有越來越多的代碼庫，Git-clone 操作需要將所有內容復制到本地計算機，這是與大型存儲庫不兼容的過程。要轉移到基于 Git 的源代碼托管，有必要將 Google 的存儲庫拆分成數千個獨立的存儲庫，以實現合理的性能。

這樣的重組將需要 Google 開發人員的文化和工作流程更改。作為比較，Google 的 Git 托管的 Android 代碼分為超過 800 個獨立的代碼庫。

鑒于 Google 已經建立的現有工具所獲得的價值以及整體代碼庫結構的許多優勢，轉換到越來越多的代碼庫對于 Google 的主代碼庫來說是沒有意義的，移動到 Git 或需要代碼庫拆分對 Google 來說并不引人注目。

Google 源代碼團隊目前的投資主要集中在內部源代碼系統的持續可靠性，可擴展性和安全性上，該團隊還在與Mercurial進行實驗性工作，這是一款類似 Git 的開源DVCS。

目標是向 Mercurial 客戶端添加可伸縮性功能，以便高效地支持 Google 的規模。這將為 Google 開發人員提供一種與單一代碼庫庫一起使用流行的 DVCS 風格工作流的替代方案。

這一努力與開源的 Mercurial 社區合作，其中包括來自其他公司的貢獻者。

結論

Google 在 1999 年將現有的 Google 代碼庫從 CVS 遷移到 Perforce 時，選擇了單一源代碼管理策略，早期的 Google 工程師認為，單獨的代碼庫比多個代碼庫要嚴格得多，盡管當時他們沒有預料到代碼庫的未來規模以及所有支持的工具。

多年來，隨著繼續擴大集中式存儲庫所需的投資增長，Google 領導層偶爾會考慮從單模模式轉變是否有意義。盡管需要努力，但由于其優勢，Google 選擇堅持使用集中式單一代碼庫。

源代碼管理的單一模型不適合所有人，它最適合像 Google 這樣的組織，具有開放和協作的文化。對于代碼庫的大部分是私有的或組之間隱藏的組織來說，這不太適用。

在 Google 方面，我們發現通過一些投資，源代碼管理的整體模式可以成功擴展到具有超過十億個文件，3500 萬個提交和全球數千個開發者的代碼庫。

隨著 Google 和 Google 內部項目的規模和復雜性不斷增長，我們希望本文中描述的分析和工作流程可以使他們對其代碼庫的長期結構進行權衡決策。

致謝

我們希望感謝 Google 開發人員基礎架構團隊的所有當前和前任成員，他們致力于構建和維護本文中引用的系統，以及許多幫助審閱文章的人員。

特別是：Jon Perkins 和 Ingo Walther，當前的 Piper 技術引領者，凱爾Lippincott和Crutcher Dunnavant，Google 的大型重構大師 Hyrum Wright 和 Chris Colohan，Caitlin Sadowski，Morgan Ames，Rob Siemborski 以及 Piper 和 CitC 開發和支持團隊，提供有見地的評論意見。

• 1. Bloch, D. Still All on One Server: Perforce at Scale. Google White Paper, 2011; http://info.perforce.com/rs/perforce/images/GoogleWhitePaper-StillAllonOneServer-PerforceatScale.pdf
• 2. Chang, F., Dean, J., Ghemawat, S., Hsieh, W.C., Wallach, D.A., Burrows, M., Chandra, T., Fikes, A., and Gruber, R.E. Bigtable: A distributed storage system for structured data. ACM Transactions on Computer Systems 26, 2 (June 2008).
• 3. Corbett, J.C., Dean, J., Epstein, M., Fikes, A., Frost, C., Furman, J., Ghemawat, S., Gubarev, A., Heiser, C., Hochschild, P. et al. Spanner: Google's globally distributed database. ACM Transactions on Computer Systems 31, 3 (Aug. 2013).
• 4. Gabriel, R.P., Northrop, L., Schmidt, D.C., and Sullivan, K. Ultra-large-scale systems. In Companion to the 21st ACM SIGPLAN Symposium on Object-Oriented Programming Systems, Languages, and Applications(Portland, OR, Oct. 22-26). ACM Press, New York, 2006, 632–634.
• 5. Kemper, C. Build in the Cloud: How the Build System works. Google Engineering Tools blog post, 2011; http://google-engtools.blogspot.com/2011/08/build-in-cloud-how-build-system-works.html
• 6. Lamport, L. Paxos made simple. ACM Sigact News 32, 4 (Nov. 2001), 18–25.
• 7. Morgenthaler, J.D., Gridnev, M., Sauciuc, R., and Bhansali, S. Searching for build debt: Experiences managing technical debt at Google. In Proceedings of the Third International Workshop on Managing Technical Debt (Zürich, Switzerland, June 2-9). IEEE Press Piscataway, NJ, 2012, 1–6.
• 8. Ren, G., Tune, E., Moseley, T., Shi, Y., Rus, S., and Hundt, R. Google-wide profiling: A continuous profiling infrastructure for data centers. IEEE Micro 30, 4 (2010), 65–79.
• 9. Sadowski, C., Stolee, K., and Elbaum, S. How developers search for code: A case study. In Proceedings of the 10th Joint Meeting on Foundations of Software Engineering (Bergamo, Italy, Aug. 30-Sept. 4). ACM Press, New York, 2015, 191–201.
• 10. Sadowski, C., van Gogh, J., Jaspan, C., Soederberg, E., and Winter, C. Tricorder: Building a program analysis ecosystem. In Proceedings of the 37th International Conference on Software Engineering, Vol. 1(Firenze, Italy, May 16-24). IEEE Press Piscataway, NJ, 2015, 598–608.
• 11. Wasserman, L. Scalable, example-based refactorings with Refaster. In Proceedings of the 2013 ACM Workshop on Refactoring Tools (Indianapolis, IN, Oct. 26-31). ACM Press, New York, 2013, 25–28.
• 12. Wikipedia. Dependency hell. Accessed Jan. 20, 2015; http://en.wikipedia.org/w/index.php?title=Dependency_hell&oldid=634636715
• 13. Wikipedia. Filesystem in userspace. Accessed June, 4, 2015; http://en.wikipedia.org/w/index.php?title=Filesystem_in_Userspace&oldid=664776514
• 14. Wikipedia. Linux kernel. Accessed Jan. 20, 2015; http://en.wikipedia.org/w/index.php?title=Linux_kernel&oldid=643170399
• 15. Wright, H.K., Jasper, D., Klimek, M., Carruth, C., and Wan, Z. Large-scale automated refactoring using ClangMR. In Proceedings of the IEEE International Conference on Software Maintenance (Eindhoven, The Netherlands, Sept. 22-28). IEEE Press, 2013, 548–551.