一千萬個為什麽

搜索

對於大型代碼庫,monorepo需要什麽?



從某個規模的代碼庫開始,你還會有Git還是有更專業的解決方案?

(另外只是檢查代碼庫的一部分)

轉載註明原文: 對於大型代碼庫,monorepo需要什麽?

一共有 4 個回答:

Git適用於monorepos,但它有一些問題:

  1. 您必須查看整個倉庫。
  2. 您必須獲取整個歷史記錄(通常 - 淺克隆是一個選項,但通常在實際開發工作中沒用)。
  3. 在本地,如果每個目錄都擁有它,每個人都有讀/寫訪問權。

谷歌,可能是最著名的monorepo用戶,開發了 Piper 來滿足他們的需求。但你不是谷歌,所以他們的解決方案可能不是你的。

monorepo的一個關鍵優勢是你可以進行全局原子更改(即你不需要對很多東西進行版本化,因為你可以在同一次提交中更改調用者和被調用者)。為了實現這一目標,您真的希望擁有一個統一的構建系統來跟蹤整個倉庫中的依賴關系。 Bazel 是Google構建系統Blaze的開源解壓縮程序,它試圖這樣做(雖然它很年輕,不成熟,缺少許多非谷歌使用所必需的功能)。 Pants 是一個類似於Twitter的系統。

如果在進行這樣的原子更改時構建大量代碼,那麽您可能還需要一個構建服務器場,允許您不在本地計算機上執行此操作。同樣,您需要一個功能強大的CI系統來在更新時處理所有內容的運行測試。

答案是:兩者兼而有之。為了滿足“使用git”和“管理龐大的代碼庫”的限制,Microsoft 開發了一個新的文件系統(之前他們使用的是Perforce的變種,稱為SourceDepot)。這是開源,但我沒有使用它的個人經驗。

你為什麽要一個單調?最明顯的原因是您可以在原子提交中修改API和該API的所有調用者。能夠在整個代碼庫中進行 git log 搜索也是有優勢的......

關於什麽是大型代碼庫的意見不同。如果你在談論一家擁有100名工程師的公司,我會認為Git應該仍然​​可以處理它。它是為Linux內核的需求而開發的,Linux內核本身並不是一個小項目。

與存儲存儲庫的方式無關,可能會遇到問題。例如,如果您正在使用大型Java代碼庫並且正在使用Eclipse或IntelliJ等工具,那麽它們將使用更多內存並且通常會變慢。

另一方面,可以選擇一次操作所有代碼(例如,在應用重構或源代碼轉換時)是單片存儲庫的主要優點之一。

當您詢問是否需要專門的工具,然後提高某個代碼大小時,答案是肯定的。谷歌稱,世界上最大的C ++代碼庫,所有可用的工具(開源或商業)都無法滿足他們的要求。他們最終開發了一個名為Piper的內部系統:

如果我理解正確的話,monorepo的“需要”只是應用於包含多個松散相關組件/子項目的軟件項目的單一/連貫版本控制方案的基本需求,這些組件/子項目可以/可以獨立地管理/版本化單獨的存儲庫。

類似地,如果您願意,需要使用常規源存儲庫為多個源文件提供單個/一致的版本控制方案,每個源文件都有自己獨立的修改歷史記錄。

使用實際的單一解決方案肯定是一個,但恕我直言不是解決這一需求的唯一方法。

另一種可能的方法是使用包含一個或多個清單文件的傘狀項目存儲庫,其中包含每個單獨項目組件存儲庫的確切版本。

即使組件存儲庫的版本通過獨立的非原子提交進行了修改,也可以簡單地通過將所有相關的組件存儲庫版本更改組合到傘庫中的清單文件的單個提交中來連貫地管理項目本身。

與遷移到實際的單一解決方案相比,這種方法有幾個優點:

  • 無需更改現有的組件存儲庫
  • 可以支持具有不同存儲庫技術的組件混合
  • 每個組件存儲庫仍然可以獨立開發和管理
  • 添加/刪除項目組件幾乎是微不足道的
  • 整合第三方(上遊)組件非常容易
  • 項目歷史可以保持更清潔,不會受到每個單獨組件庫更改的所有細節的汙染(通常與其他組件無關)
  • 無需擔心單個存儲庫的大小/性能/可伸縮性,解決方案本身具有高度可擴展性。