维基百科

Monorepo

在版本控制系統中，Monorepo（“mono”意為“單一”，“repo”是“存儲庫”的縮寫）是一種軟體開發策略，其中多個專案的程式碼存儲在同一個存儲庫裡面。[1] 這種做法至少可以回溯到 2000 年代初期，當時這種做法通常被稱為共享程式碼庫。[2] Google,[3] Meta,[4] Microsoft,[5] Uber,[6] Airbnb, 以及Twitter[7] 所有這些公司都採用非常大的單一儲存庫（Monorepo），採用不同的策略來擴充具有大量程式碼和日常改版的建置系統和版本控制軟體。

一個相關的概念是龐大應用程式，但是龐大應用程式將其子專案組合成一個大專案，而單一存儲庫（Monorepo）可能包含多個獨立專案。[8][9][10]

優點

與個體存儲庫相比，單一存儲庫有許多潛在優勢：[3][11]

方便重複利用程式碼
類似的功能或溝通協定可以抽像到共享工具庫中並直接包含在專案中，而不需要依靠套件管理器。
簡化相依性套件管理
在多個專案依賴於第三方相依性套件的多存儲庫環境中，該相依性套件可能會被多次下載或構建。在 monorepo 中，可以輕鬆優化構建，因為所引用的相依性套件都儲存於同一程式碼庫中。
原子化提交（Atomic commit）
當一起運作的專案包含在單獨的存儲庫中時，發布需要同步一個專案的哪些版本與另一個專案一起運作。在相當龐大的專案中，管理相依套性件之間的相容版本可能會變成相依套件地獄（Dependencies hell）。在 monorepo 中，這個問題可以被解決，因為開發者可以原子化的方式修改多個專案。[12]
大規模程式碼重構
由於開發者可以存取整個專案，重構可以確保專案的每一個地方在重構之後可以繼續運作。
跨團隊協作
在使用原始相依性套件（從原始程式碼編譯的相依性套件）的 monorepo 中，團隊可以改善其他團隊正在進行的專案。這樣能讓程式碼所有人更富有彈性。

限制與缺點

損失版本資訊
雖然不是必要的，但一些 monorepo 構建在存儲庫中的所有專案中使用同一個版本號。 將會導致損失每個專案的語義版本控制。[13]
缺乏每個專案的存取控制
使用分離式存儲庫，可以根據需要授予對存儲庫的存取權限。 monorepo 可以對項目中的所有軟體進行讀取，可能會帶來新的安全問題。[14] 要注意的是在某些版本控制系統中，此限制不是問題。 例如，當使用 Subversion 時，可以下載存儲庫的任何部分（甚至是單個目錄），並且可以使用基於路徑的授權來限制對存儲庫某些部分的存取。
預設需要更多存儲空間
使用分離式存儲庫，在預設的情況下只能接收感興趣的專案。使用 monorepo，在預設情況下您可以取出（check out）所有專案。 這樣將會佔用大量存儲空間。 雖然所有版本都有執行部份取出（partial checkout）的機制[15][16] 但這樣的做法會破壞 monorepo 的一些優點。

可擴充性的挑戰

擁有大型專案的公司都會遇到了 monorepos 的障礙，特別是與構建工具和版本控制系統有關。 Google的monorepo被認為是世界上最龐大，符合超大規模系統的分類[3] ，每天必須在超過 80 TB 的存儲庫中處理數萬個貢獻提交。[17]

擴充版本控制軟體

参见：Version control

使用或改用現有版本控制軟體的公司發現，該軟體無法有效處理大型 monorepo 所需的資料量。 Facebook 和微軟分別選擇貢獻或對現有的版本控制軟件 Mercurial 和 Git建立分叉版本，而谷歌最終建立了自己的版本控制系統。十多年來，Google 一直依靠託管在單一機器上的 Perforce。 2005 年，Google 的構建伺服器可能一次被鎖定長達 10 分鐘。谷歌在 2010 年將其改進為 30 秒 - 1 分鐘。[18] 因為擴充問題，Google 最終開發自己的內部分散式版本控制系統，稱為 Piper。[3]

Facebook 遇到了版本控制系統 Mercurial 的性能問題，並為客戶端做出了上游貢獻，[19] 並在 2014 年 1 月使該系統比起 Git 中的競爭解決方案更快。[20]

2017 年 5 月，Microsoft 宣布幾乎所有 Windows 工程師都使用 Git monorepo。[5] 在過渡期內，Microsoft 對 Git 客戶端做出了大量的上游貢獻，移除不必要的檔案存取並改善使用 Git 虛擬檔案系統處理大型檔案的能力。[21]

擴充構建軟體

参见：Build automation

很少有構建工具在 monorepo 中有良好表現-[7]，並且在存入時執行整個存儲庫的構建和持續整合測試的流程會導致的性能問題。[13][14] 有定向式圖型構建 Buck、Bazel、Pants 和 Please 等系統，通過將構建和測試劃分到活躍的開發區域來解決這個問題。[22]

Twitter 於 2011 年開始開發 Pants，因為在當時 Facebook 的 Buck 和谷歌的 Bazel 都是不是開始原始程式碼的工具。[23] Twitter 以 Apache 2.0 授權的方式於 2012 年開放 Pants 的原始程式碼。[24]

Please 是一款基於 Go 語言的構建系統，由 Thought Machine 在 2016 年開發，Thought Machine 也是受到 Google 的 Bazel 的啟發，同時也是因為對 Facebook 的 Buck 不滿。[25]

參考文獻

  1. ^ Infrastructure as Code | Second edition. Thoughtworks. 2021-02-25 [2022-12-01]. （原始内容存档于2023-06-02） （美国英语）. 
  2. ^ Mark "Nurgle." Collins. Linux Game Programming. Prima Tech. 2001 [2023-04-11]. ISBN 978-0-7615-3255-2. OCLC 1044194694. （原始内容存档于2023-05-01） （美国英语）. 
  3. ^ 3.0 3.1 3.2 3.3 Levenberg, Rachel Potvin, Josh. Why Google Stores Billions of Lines of Code in a Single Repository. Communications of the ACM. July 2016 [20 July 2018]. （原始内容存档于2020-05-28）. 
  4. ^ 引用错误：没有为名为scaling_mercurial的参考文献提供内容
  5. ^ 5.0 5.1 Lardinois, Frederic. Microsoft now uses Git and GVFS to develop Windows. TechCrunch. 24 March 2017 [20 July 2018]. （原始内容存档于2023-04-15） （美国英语）. 
  6. ^ Aimee Lucido. Uber Technology Day: Monorepo to Multirepo and Back Again. 7 April 2017 [24 July 2018]. （原始内容存档于2023-05-06）. 
  7. ^ 7.0 7.1 Dorothy Ordogh. Pants and Monorepos. 5 April 2018 [24 July 2018]. （原始内容存档于2023-05-03）. 
  8. ^ Reece, Brock. From Monolith to Monorepo. From Monolith to Monorepo. Since starting at Croud. November 7, 2017 [March 19, 2019] （美国英语）. 
  9. ^ Savkin, Victor. Misconceptions about Monorepos: Monorepo != Monolith. blog.nrwl.io. August 14, 2019 [June 16, 2020] （美国英语）. 
  10. ^ Oberlehner, Markus. Monorepos in the Wild. Jun 12, 2017 [July 25, 2018]. （原始内容存档于2020-05-11） （美国英语）. 
  11. ^ Brousse, Nicolas. The issue of monorepo and polyrepo in large enterprises. Proceedings of the Conference Companion of the 3rd International Conference on Art, Science, and Engineering of Programming. ACM Digital Library. 2019: 1–4 [7 September 2019]. ISBN 9781450362573. S2CID 201670751. doi:10.1145/3328433.3328435. 
  12. ^ Santacroce, Ferdinando; Olsson, Aske; Voss, Rasmus; Narebski, Jakub. Git: Mastering Version Control. Packt Publishing Ltd. 2016: 756 [2023-04-11]. ISBN 9781787122796. （原始内容存档于2023-05-26） （英语）. 
  13. ^ 13.0 13.1 Farina, Matt. Dangers of Monorepo Projects - DZone DevOps. DZone. [20 July 2018]. （原始内容存档于2023-05-07） （英语）. 
  14. ^ 14.0 14.1 点融黑帮. 浅谈monorepo [Talking about monorepo]. Sohu. 16 August 2017 [20 July 2018]. （原始内容存档于2023-04-16） （Chinese）. 
  15. ^ Svn Book: Sparse Directories. [2023-04-11]. （原始内容存档于2023-04-16）. 
  16. ^ Perforce: Clone. [2023-04-11]. （原始内容存档于2023-04-19）. 
  17. ^ Metz, Cade. Google Is 2 Billion Lines of Code—And It's All in One Place. WIRED. 16 September 2015 [20 July 2018]. （原始内容存档于2016-10-23）. 
  18. ^ Bloch, Dan. Still All on One Server: Perforce at Scale (PDF). [23 July 2018]. （原始内容存档 (PDF)于2021-05-13）. 
  19. ^ Claburn, Thomas. Facebook is writing a Mercurial server in Rust. This is not a drill. The Register. [20 July 2018]. （原始内容存档于2019-05-03） （英语）. 
  20. ^ Blewitt, Alex. Facebook makes Mercurial faster than Git. InfoQ. 9 Jan 2014 [24 July 2018]. （原始内容存档于2023-04-16）. 
  21. ^ Bright, Peter. Windows switch to Git almost complete: 8,500 commits and 1,760 builds each day. Ars Technica. 24 May 2017 [20 July 2018]. （原始内容存档于2017-05-24） （美国英语）. 
  22. ^ Hammant, Paul; Smith, Steve. Trunk Based Development. trunkbaseddevelopment. [24 July 2018]. （原始内容存档于2020-04-14）. 
  23. ^ Mohilo, Dominik. 8 Build-Tools im Vergleich: Ant – Buildr – Maven – Bazel – Buck – Gradle – Pants – sbt - JAXenter [8 build tools compared: Ant - Buildr - Maven - Bazel - Buck - Gradle - Pants - sbt]. JAXenter. 10 June 2016 [20 July 2018]. （原始内容存档于2020-08-11） （de-DE）. 
  24. ^ Moore, Madison. GitLab releases security fixes, Pants 1.0, and Sauce Labs integration for JIRA—SD Times news digest: May 3, 2016 - SD Times. SD Times. 3 May 2016 [20 July 2018]. （原始内容存档于2020-05-11）. 
  25. ^ Ebden, Peter. Please - the Thought Machine Build System. Blog. Thought Machine. December 2017. （原始内容存档于2019-12-28）. 
检索自“https://zh.wikipedia.org/w/index.php?title=Monorepo&oldid=79732700”