單體儲存庫與多儲存庫

目錄:

• 摘要
  • 問題
  • 決策
  • 狀態
• 詳情
  • 假設
  • 約束
  • 立場
  • 論證
  • 影響
• 相關內容
  • 相關決策
  • 相關需求
  • 相關製品
  • 相關原則
• 備註

摘要

問題

我們的專案涉及開發三大類軟體:

• 前端圖形介面(GUI)
• 中介軟體服務
• 後端伺服器

在開發時,我們的原始碼管理(SCM)版本控制系統(VCS)是 git。

我們需要選擇如何使用 git 來組織我們的程式碼。

最高層的選擇是組織成「monorepo(單體儲存庫)」、「polyrepo(多儲存庫)」或「混合」:

• Monorepo 意味著我們把所有部分放進一個大儲存庫
• Polyrepo 意味著我們把每個部分放進各自的儲存庫
• 混合意味著 monorepo 與 polyrepo 的某種組合

更多資訊請參見 https://github.com/joelparkerhenderson/monorepo-vs-polyrepo

決策

當組織/團隊/專案相對較小,且快速迭代的優先順序高於維持穩定性時,選擇 monorepo。

當組織/團隊/專案相對較大,且維持穩定性的優先順序高於快速迭代時,選擇 polyrepo。

狀態

已決定。如果/當出現用於管理 monorepo 和/或 polyrepo 的新工具時,願意重新審視。

詳情

假設

我們開發的所有程式碼都是為某一個組織的產品服務的,而不是面向公眾的。也就是說,這家券商(Broker-Dealer)並不打算擁有任何類似公眾志願開發者的群體。

約束

約束在 https://github.com/joelparkerhenderson/monorepo-vs-polyrepo 中有詳細記錄。

立場

我們考慮了 Google、Facebook 等風格的 monorepo。我們認為,任何 monorepo 的擴充套件問題都出現在遙遠的將來,到我們需要的時候,我們將能夠利用與 Google 和 Facebook 相同的實踐。

我們考慮了典型 Git 開源專案風格的 polyrepo,例如 Google Android、Facebook React 等。我們認為,對於公眾參與(例如全世界任何人都可以參與程式碼工作)和單獨可用性(例如專案可以獨立使用,不依賴任何其他部分),這些是最佳選擇。

論證

當組織/團隊/專案相對較小時,我們選擇 monorepo,因為快速迭代的優先順序明顯高於維持穩定性。

當組織/團隊/專案相對較大時,我們選擇 polyrepo,因為維持穩定性的優先順序明顯高於快速迭代。

影響

如果已有 CI+CD 流水線,我們可能需要對其進行調整,以便在一個儲存庫內測試多個專案。

對於 monorepo,CI+CD 的完整構建可能耗時更長,因為 CI+CD 可能會構建 monorepo 中的所有專案。

如果組織/團隊/專案不斷增長,monorepo 將出現擴充套件問題。

monorepo 的擴充套件問題可能使過渡到 polyrepo 變得越來越有價值。

從 monorepo 過渡到 polyrepo 是一項重大的 DevOps 任務,需要計劃、管理和程式設計實現。

相關內容

相關決策

我們將為管理 monorepo(例如 Google Bazel)和 polyrepo(例如 Lyft Refactorator)的相關工具建立決策。

相關需求

我們需要開發能夠與 git 良好協作的 CI+CD 流水線。

相關製品

我們預計儲存庫組織將帶有用於資源供應、配置管理、測試以及類似 DevOps 領域的相關製品。

相關原則

易於撤銷。如果 monorepo 在實踐中行不通,或者領導層不想要,可以很容易地改為 polyrepo。

痴迷於客戶(Customer Obsession)。我們重視讓專案儘快送到客戶手中,並且相信 monorepo 比 polyrepo 能更快地做到這一點,也有助於我們更快地迭代。

志存高遠(Think big)。Google 和 Facebook 是 monorepo 優於 polyrepo 的強力倡導者,因為所有核心產品可以協同開發/測試/部署。

備註

在此新增任何備註。