ポリレポとは?

ポリレポ(マルチレポ)は、独立した履歴、バージョニング、そしてCIとともに、すべてのプロジェクトに独自のリポジトリを与えます。

ポリレポモデルは従来型のものです: サービスまたはライブラリごとに1つのリポジトリ。それぞれが独自のpipelineとreleaseのペースを持ちます。個々のリポジトリを小さく、pipelineを焦点の絞られたものに保ちますが、リポジトリをまたぐ変更を調整するコストがかかります。

ポリレポとは何か

各プロジェクトは、独自のCI、権限、そしてバージョニングを持つ別々のリポジトリに存在します。チームは1つの共有コードベースではなく、少数のリポジトリを所有することがよくあります。

CIへの影響

• 各リポジトリのpipelineは小さく、そのプロジェクトのみをbuildします - 自然にスコープが限定されます。
• リポジトリをまたぐ変更には調整が必要です: ライブラリを公開し、consumer側を更新します。
• 共有されたCI設定は、中央のテンプレートがないとリポジトリ間で乖離しがちです。

小さな例

ポリレポで共有ライブラリを変更することは次を意味します: ライブラリをmergeして公開し(それ自身のpipeline)、次に各consumerリポジトリでバージョンを更新するための2つ目のpull requestを開く - モノレポなら1つのアトミックな変更で行う2つの調整されたステップです。

pipelineの一貫性を保つ

単一の信頼できる情報源がないと、各リポジトリのworkflowは乖離します。reusable workflowや共有されたtemplate repoにより、多数のポリレポが1つのpipeline定義を継承でき、モノレポが無償で得る一貫性の一部を取り戻せます。

ポリレポ vs モノレポ

ポリレポは分離と独立したreleaseのペースをもたらし、モノレポはプロジェクトをまたぐアトミックな変更と統一されたtoolingをもたらします。どちらも普遍的に優れているわけではありません - 正しい選択は、プロジェクトがどれだけ密結合しているかによります。

重要なポイント

• ポリレポは各プロジェクトに独自のリポジトリとpipelineを与えます。
• pipelineは小さくスコープが限定されたままですが、リポジトリをまたぐ変更には調整が必要です。
• モノレポとのトレードオフは、分離 対 アトミックな変更です。

関連ガイド