polyrepo アーキテクチャとは？ 1プロジェクトにつき1 repository

polyrepo アーキテクチャは、各プロジェクト、サービス、library に、別々の repository、履歴、パイプラインを与えます。

monorepo の反対である polyrepo（または multi-repo）の構成は、各サービスや library が独自の CI を持つ独自の repository に置かれるようにコードを分割します。完全に独立したチームとサービスに自然に適合しますが、協調の問題、共有コード、横断的な変更、version skew を、tooling がもはやアトミックに見られない repo の外へ押し出します。

1プロジェクト、1 repo

各コンポーネントが独自の repository、アクセス制御、履歴、パイプラインを持ちます。共有コードは、monorepo のように直接参照されるのではなく、他の repo が依存するバージョン管理されたパッケージとして公開されます。

なぜチームが選ぶのか

強い分離と repo ごとのアクセス制御。
各 repo が小さく焦点の定まった高速なパイプラインを持つ。
チームが自分の repo を所有し、独自の頻度でリリースする。
clone や探索のための巨大な共有履歴がない。

repo 横断のコスト

サービスにまたがる変更は、今や repository にまたがります。複数の PR、慎重な順序付け、そしてアトミックな commit の不在。共有 library はバージョン管理して公開しなければならず、version skew、すなわち repo が異なるバージョンに依存すること、が現実の協調の負担になります。

repository ごとの CI

各 repo は独自の小さく高速なパイプラインを持ち、単独では単純です。難しいのは統合です。独立してビルドされたサービスが今も一緒に動くことを検証することであり、通常は単一のパイプラインの外での repo 横断の integration テストや contract テストを必要とします。

リリースの協調

アトミックな repo 横断の変更がないため、複数のサービスに触れる機能をリリースするには、deploy を順序付け、契約を backward compatible に保つ必要があります。マイクロサービスを安全にする規律が、polyrepo の協調に直接適用されます。

多数の小さなパイプラインを同時に

polyrepo の構成は、チーム間で並行して発火する多数の独立したパイプラインを意味します。スケールアウトするマネージド runner の fleet（Latchkey など）は、それらの並行する repo ごとのビルドが互いの後ろで待たされないようにします。

重要なポイント

polyrepo アーキテクチャは、各プロジェクトに独自の repository とパイプラインを与える。
repo 横断の協調を代償に、チームごとの独立性を最大化する。
共有コードと横断的な変更には、versioning と慎重なリリース順序が必要になる。