關于代碼的管理問題已經讨論多年，随着企業業務的複雜度提高、軟體行業技術棧的選擇度變寬泛，現代軟體的代碼倉庫也變得越來越龐大和複雜。一個中型項目，将測試代碼、核心業務代碼、編譯建構、部署打包等基礎設施的代碼全部加起來，幾十萬行都是家常便飯。并且一個項目往往由多個團隊進行協作，如何讓多團隊在對同一個項目的代碼進行協作時不會互相幹擾、互相制約，也是每個企業研發團隊在實踐中不斷摸索的難題。
多倉庫與單倉庫
對于上文所說的一些問題，業界已經歸納了常見的代碼倉庫存放方式，常見的如單倉庫和多倉庫。大部分企業會針對不同的項目采用不同的倉庫管理機制，是以對于企業來說，經常會兩種方式并存：
- 單倉庫
将所有項目代碼存放在一個代碼倉庫當中，這個好處在于項目的所有開發者可以共享看到項目中的所有代碼；在項目規模較小的時候，一個庫可以更好地管理和維護，發版本隻要統一釋出即可；對于持續內建，也隻需要針對一個庫維護若幹條流水線。但再好的實踐以及工具都有它适用的範圍。Git 已經是非常流行的代碼托管工具，但 Git 會把所有曆史記錄以及代碼同步到各個使用者的本地機器，是以對于大型項目而言，如果使用單倉庫，就意味着某個子產品開發者的本地可能有大量備援代碼和送出記錄的資訊，這個時候拆分成更小的庫顯得更加合适。
谷歌與 Facebook 就是業界典型的單倉庫派代表。作為代碼行數已經超過數十億行、commit 數量累計達到千萬次的團隊（2015 年的統計資料），如果沒有強悍的基礎設施，也很難運轉順利。Google 曾發表論文介紹其強大的代碼管理系統 Piper 以及用戶端工具 CitC，但對于大部分企業來說是否有必要投入如此之大的研發成本去自研一個代碼管理系統值得商榷，是以谷歌的實踐對于大部分企業來說不一定具備參考性。
*谷歌代碼倉庫每周的送出數量
- 多倉庫
将項目代碼進行一定的拆分放在多個庫當中，好處就是将代碼進行一定的解耦，對于體型較為龐大的項目來說管理上會更加清晰和富有彈性。将代碼按照一定邏輯分庫之後，倉庫與子產品有了自描述的特征，讓一起協作的開發者可以一目了然。釋出源碼版本、持續內建建構時，負責各倉庫的研發組織可以按照自己的節奏來釋出，同時将一些“壞代碼”的影響控制在某個倉庫中，而不會影響項目全部代碼。分庫也有要注意的地方，在同一個項目裡的代碼多多少少都有業務上或者是技術上的聯系，比如編譯依賴：以一個Java 項目為例，用戶端接口的調用代碼究竟是直接依賴服務端接口代碼的定義，還是間接依賴？如果是間接依賴，那麼分庫管理是非常友善的，但同時用戶端就無法快速感覺到服務端接口定義的變化。是以在進行多倉庫劃分時，要注意劃分的一些常用原則。
多倉庫在業界使用的非常廣泛，在騰訊、華為、阿裡的開源項目中我們都能看到，比如騰訊的 Tars 開源項目（RPC 開發架構）就按照不同程式設計語言以及技術棧進行了分庫：包括 Java、Go、PHP 等子項目。作為開源項目，一個清晰的分庫可以讓開發者更好地協作，避免不必要的溝通成本。
*Tars 的開源項目子倉庫
CODING 的多倉庫實踐
CODING 在多倉庫實踐上也遇到過問題。由于前端、後端、git-server 三個子產品的代碼放置在同一倉庫中，以至于代碼版本的 tag 需要保持同步，制約了各個團隊的開發節奏。每個子產品的進度都得齊頭并進，才能保證最終版本是一緻的。盡管它們在業務上緊密相連，但實際上這幾個子產品本身沒有編譯依賴，是以在沒有多倉庫功能時，我們隻能建立了三個項目，使用三個項目的代碼倉庫能力，隻集中在一個項目當中進行項目管理工作。
在千呼萬喚中，CODING 近期終于正式上線了多倉庫功能，我們的開發人員也終于可以告别傻乎乎地使用一個項目進行管理，又用多個項目進行代碼倉庫管理的尴尬問題，我們将那些沒有編譯依賴的項目，但在業務上又有聯系的代碼倉庫，放置在同一項目的多倉庫下，開發人員無需在多個項目中切換。
多倉庫功能一直是 CODING 想要投入做的一個特性。随着近幾年 CODING 企業使用者的快速增長，CODING 的架構也面臨着持續的挑戰。如何讓傳遞更加順滑，讓特性更快、更好地服務開發者，是我們進行架構演進的初衷。是以我們在很早之前就開始了容器化、微服務化的規劃與實施，而在微服務化的過程當中，包括代碼倉庫管理在内的研發流程與組織方式也在配套前進着。多倉庫這項基本能力就可以讓多個微服務獨立存放在獨立的代碼倉庫當中，配套獨立的持續內建流水線，讓架構演進變得水道渠成。我們知道很多企業使用者對多倉庫有很大訴求，CODING 的多倉庫已正式上線，歡迎大家前去體驗。
業界常用實踐
綜上我們可以看到，代碼倉庫的組織方式往往和人員組織架構息息相關，而且代碼庫的拆分也往往和軟體架構的演進息息相關。在現代軟體架構逐漸由單體朝着分布式、微服務演化時，代碼倉庫和研發團隊的粒度也在逐漸變小，從以前的集中式慢慢變為網狀。但無論是單倉庫還是多倉庫，最終目的都是為了讓開發者更加高效地進行研發。那究竟該如何選擇？筆者總結了幾條業界的通用實踐來供大家思考：
- 技術棧不同的子產品建議多庫存放
不同技術棧的編譯環境、建構環境、釋出環境往往不同，代碼之間的硬性依賴也不大，可以考慮分庫存放。大部分的開發者還是傾向于在工作中持續使用某一種熟悉的程式設計語言，是以按照技術棧劃分是一個常用的實踐。
- 倉庫的粒度最好群組織架構相比對
拆庫要拆到什麼粒度呢？有些研發組織微服務化後，給每個微服務都配置設定了一個代碼庫，随着拆分深入，一個項目積攢了幾百個代碼庫。但一個 two-pizza 團隊往往會負責多個微服務，不僅僅是一個。是以建議不要盲目使用大量代碼庫，避免到後期難以管理，可以考慮按照團隊組織來劃分代碼倉庫。
- 拆庫并不意味着建立部門牆
不少企業代碼拆分之後可能順便就把團隊之間的代碼權限也做了劃分，建議研發團隊慎重考慮。關閉了代碼權限就意味着，團隊與團隊之間不再互相 review 代碼，相應的工作上的交流也會逐漸減少。如果讀者的企業屬于内部開放型氛圍的公司，或者想要成為開放型的公司，那麼關于此點請三思。
reference：
https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
點選立即體驗 CODING 多倉庫功能