Architecture Decision Recordモノレポ対マルチレポ
目次:
概要
課題
私たちのプロジェクトでは、3 つの主要なカテゴリのソフトウェアを開発します:
- フロントエンド GUI
- ミドルウェアサービス
- バックエンドサーバー
開発の際、私たちのソースコード管理(SCM)のバージョン管理システム(VCS)は git です。
コードを整理するために git をどのように使用するかを選択する必要があります。
最上位の選択は、「モノレポ」、「ポリレポ」、または「ハイブリッド」として整理することです:
- モノレポは、すべての部分を 1 つの大きなリポジトリに入れることを意味します
- ポリレポは、各部分をそれぞれのリポジトリに入れることを意味します
- ハイブリッドは、モノレポとポリレポをある程度混ぜることを意味します
詳細については、https://github.com/joelparkerhenderson/monorepo-vs-polyrepo をご覧ください
決定
組織/チーム/プロジェクトが比較的小さく、安定性の維持よりも素早い反復が優先される場合は、モノレポ。
組織/チーム/プロジェクトが比較的大きく、素早い反復よりも安定性の維持が優先される場合は、ポリレポ。
状態
決定済み。モノレポやポリレポを管理するための新しいツールが利用可能になったときには、見直しに対してオープンです。
詳細
前提
私たちが開発しているすべてのコードは、一般向けではなく、1 つの組織の提供物のためのものです。つまり、ブローカー・ディーラーは、一般のボランティア開発者のようなものを持つことを目指していません。
制約
制約は https://github.com/joelparkerhenderson/monorepo-vs-polyrepo に十分に文書化されています
ポジション
Google、Facebook などのスタイルのモノレポを検討しました。モノレポのスケーリングの問題は非常に遠い将来のことであり、それが必要になる頃には、Google や Facebook と同じ実践を活用できるだろうと考えています。
典型的な Git オープンソースプロジェクト、たとえば Google Android、Facebook React などのスタイルのポリレポを検討しました。これらは、一般の参加(たとえば、世界中の誰もがコードに取り組める)と個別の利用可能性(たとえば、プロジェクトが他の部分なしにそれ単体で使用される)にとって最善の選択だと考えています。
論拠
組織/チーム/プロジェクトが比較的小さい場合、安定性の維持よりも素早い反復の方が優先度が大幅に高いため、モノレポを選択します
組織/チーム/プロジェクトが比較的大きい場合、素早い反復よりも安定性の維持の方が優先度が大幅に高いため、ポリレポを選択します。
影響
CI+CD の既存のパイプラインがある場合は、1 つのリポジトリ内の複数のプロジェクトをテストするために、それを調整する必要があるかもしれません。
モノレポでは、CI+CD がモノレポ内のすべてのプロジェクトをビルドする可能性があるため、フルビルドに時間がかかる可能性があります。
組織/チーム/プロジェクトが成長すると、モノレポにはスケーリングの問題が生じます。
モノレポのスケーリングの問題により、ポリレポへの移行がますます価値を持つようになるかもしれません。
モノレポからポリレポへの移行は重要な devops タスクであり、計画、管理、プログラミングが必要になります。
関連
関連する決定
モノレポ(例: Google Bazel)とポリレポ(例: Lyft Refactorator)を管理するための関連ツールについての決定を作成します。
関連する要件
git とうまく連携するように CI+CD パイプラインを開発する必要があります。
関連する成果物
リポジトリの構成には、プロビジョニング、構成管理、テスト、および同様の devops 領域のための関連する成果物があることを期待しています。
関連する原則
容易に元に戻せる。モノレポが実際にはうまくいかない場合、または経営陣が望まない場合、ポリレポに変更するのは簡単です。
顧客へのこだわり。私たちは、プロジェクトを顧客の手に届けることを重視しており、モノレポの方がポリレポよりも早くそれを実現でき、より速い反復にも役立つと信じています。
大きく考える。Google と Facebook は、すべてのコア製品を協調して開発/テスト/デプロイできるため、ポリレポよりもモノレポを強く支持しています。
メモ
ここにメモを追加してください。