Mono Repo or Muti Repo? This is a question

在公司最近關於mono repo和multi repo的討論中，學習到了一些新知識，也觸發了一些感想。mono repo 顧名思義，就是公司全部的源代碼都在同一個代碼庫裏。固然並不必定這麼絕對，有的公司可能有若干個大的代碼庫，例如M公司的Windows, Office或F公司的前端和後端。multi repo則是指每一個項目，每一個服務都擁有本身單獨的的代碼庫。

當一個公司到達至關規模的的時候，公司最重要的資產--源代碼隨着體積的膨脹，會帶來一系列的工程挑戰：

1. 同步，編譯和構建時間可能變得沒法忍受。

2. 保證代碼的穩定變的困難。開發人員同步代碼後可能沒法成功編譯或運行

3. 單一代碼庫包含不一樣的編程語言。編譯工具的不一樣使得新建，更改構建過程變的很困難。

讓咱們先來看一下這個行星上最大的代碼庫——谷歌的代碼庫：Why Google Stores Billions of Lines of Code in a Single Repository

谷歌起始於perforce，後來遷移到自行研發的Piper和CitiC，
代碼庫包含3千五百萬commits， 二十億行代碼，85TB的代碼
兩萬五千工程師天天產生一萬六千個commit，另外包括兩萬五千個自動化系統的commit

這是一個極端的例子，可是咱們能夠看到，首先，85TB的代碼遠遠超過一臺開發機的硬盤，必需要支持可以只同步少部分代碼並構建。同時還要保證全部的依賴關係必須可以同時處理。例如，更改一部分代碼，全部依賴於它的模塊必須也要可以正確編譯構建。構建系統必須是分佈的和高效的。

每兩秒一個commit，必需要保證commit的質量。谷歌付出了巨大的人力物力來維護這樣一個單一代碼庫，到底是爲了什麼呢？原文的總結以下：
˲ 統一版本控制，代碼擁有一個惟一真實的view;
˲ 更容易支持代碼共享和重用;
˲ 簡化依賴關係管理;
˲ 每個變化都是，原子的變化;
˲ 更容易的支持大型重構;
˲ 更容易的支持協做跨團隊;
˲ 團隊邊界和代碼全部權的轉移變得更容易靈活。
˲ 代碼結構更清晰，樹結構提供隱含團隊命名空間便於管理

這一切都很美好，但對於通常公司意味着須要付出巨大的投入。不少系統，好比分佈式構建有着很大的技術挑戰, 須要極強的依賴分析和緩存構建。

與mono repo對應的是，multirepo，也就是代碼庫是分散管理的，每一個項目，每一個服務擁有本身的代碼庫。這樣項目組能夠很快的推動，彼此之間的影響會很小。開源項目能夠看做是這種方式。成名公司中，Amazon能夠說是最成功的例子配合它們鬆耦合的SOA架構，也取得了巨大的成功。採用這種方式，最大的挑戰是代碼共享和依賴管理。因爲每一個代碼庫自由選擇本身所依賴的版本號，一旦試圖共享代碼，版本之間的衝突變的很難避免。好比 A 依賴於B，C， B，C都依賴於D，但它們依賴於不一樣版本的D。這時的處理就變得很困難。固然咱們可使用開發工具去檢查發現這種狀況。但有時當必須須要B或C升級時，額外的溝通成本就不可避免。

如何選擇，這是一個問題。在一家難以投入大量人力於構建系統的時候，可能multi repo 在短時間內更有助於生產力。但從長期來看，單一， 高效的構建系統和創建專業的團隊支持系統是更好的選擇。而今天，谷歌開源了Bazel，Twitter開源了Pants，Facebook開源了buck, 在必定程度上下降了門檻。