Architecture Decision Record單一倉庫（Monorepo）定多倉庫（Multirepo）
內容：
摘要
問題
我哋嘅項目涉及開發三大類軟件：
- 前端圖形用戶介面（GUI）
- 中介軟件服務
- 後端伺服器
開發嗰陣，我哋嘅原始碼管理（SCM）版本控制系統（VCS）係 git。
我哋需要揀選點樣用 git 組織程式碼。
最頂層嘅選擇係組織成「monorepo」、「polyrepo」或者「混合」：
- Monorepo 即係我哋將所有部分放入一個大儲存庫
- Polyrepo 即係我哋將每個部分放入自己嘅儲存庫
- 混合即係 monorepo 同 polyrepo 嘅某種混合
詳情請參閱 https://github.com/joelparkerhenderson/monorepo-vs-polyrepo
決策
當組織／團隊／項目相對較細，而快速迭代嘅優先次序高於維持穩定時，用 monorepo。
當組織／團隊／項目相對較大，而維持穩定嘅優先次序高於快速迭代時，用 polyrepo。
狀態
已決定。如果日後有管理 monorepo 及／或 polyrepo 嘅新工具出現，我哋持開放態度重新檢討。
詳情
假設
我哋開發嘅所有程式碼都係為一個組織嘅產品而設，並非為廣大公眾。即係話，經紀交易商並無打算有類似廣大公眾志願開發者嘅東西。
限制
限制已喺 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）嘅相關工具建立決策。
相關需求
我哋需要開發 CI+CD 管線，令其同 git 配合良好。
相關工件
我哋預期儲存庫組織會有相關工件，用於調配、配置管理、測試同類似嘅 devops 範疇。
相關原則
容易回復。如果 monorepo 喺實際應用中行不通，或者領導層唔想要，轉為 polyrepo 好簡單。
顧客至上。我哋重視令項目盡快到達客戶手中，並相信 monorepo 可以比 polyrepo 更快達到目標，亦有助我哋更快迭代。
志存高遠。Google 同 Facebook 非常強烈支持 monorepo 多於 polyrepo，因為所有核心產品都可以協同開發／測試／部署。
備註
喺呢度加入任何備註。