關于代碼的管理問題已經討論多年，隨著企業業務的復雜度提高、軟體行業技術堆疊的選擇度變寬泛，現代軟體的代碼倉庫也變得越來越龐大和復雜，一個中型專案，將測驗代碼、核心業務代碼、編譯構建、部署打包等基礎設施的代碼全部加起來，幾十萬行都是家常便飯，并且一個專案往往由多個團隊進行協作，如何讓多團隊在對同一個專案的代碼進行協作時不會相互干擾、相互制約，也是每個企業研發團隊在實踐中不斷摸索的難題，
多倉庫與單倉庫
對于上文所說的一些問題，業界已經歸納了常見的代碼倉庫存放方式，常見的如單倉庫和多倉庫，大部分企業會針對不同的專案采用不同的倉庫管理機制，所以對于企業來說，經常會兩種方式并存：
- 單倉庫
將所有專案代碼存放在一個代碼倉庫當中，這個好處在于專案的所有開發者可以共享看到專案中的所有代碼；在專案規模較小的時候，一個庫可以更好地管理和維護，發版本只要統一發布即可；對于持續集成，也只需要針對一個庫維護若干條流水線，但再好的實踐以及工具都有它適用的范圍，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 多倉庫功能
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/5495.html
標籤：其他