monorepo アーキテクチャとは？多数のプロジェクトを1つの repository に

monorepo アーキテクチャは、多数のプロジェクト、サービス、あるいは library を、共有された tooling と履歴とともに1つのバージョン管理された repository に保ちます。

monorepo はすべてを1つの repository に置きます。複数のサービス、共有 library、tooling を、すべて一緒にバージョン管理します。これは monolith（1つのデプロイ単位）とは同じではありません。monorepo は独立してデプロイ可能な多数のサービスを保持できます。このアーキテクチャの選択は CI の構成に大きく直接的な影響を与えます。素朴な CI は変更のたびに全体を rebuild してしまうからです。

1つの repo、多数のプロジェクト

複数のプロジェクトが、1つの repository、統一された履歴、共通の tooling を共有します。1つの変更が複数のプロジェクトにまたがって1つのアトミックな commit になりうるし、共有 library は repo 間で公開・バージョン管理されるのではなく直接使われます。

なぜチームが選ぶのか

1つの commit でのアトミックなプロジェクト横断の変更。
共有コード、tooling、標準のための1か所。
多数のプロジェクトにまたがる大規模なリファクタが容易。
別々の依存 repo 間の version skew の駆け引きがない。

CI の課題

monorepo の CI を特徴づける問題は選択的なビルドです。commit のたびにすべてを rebuild してテストするのは無駄で遅いのです。変更がどのプロジェクトに影響するかを判定し、build graph と変更検出を使ってそれだけをビルドする必要があります。

影響を受けるプロジェクトの検出

monorepo の build ツールは依存グラフを計算し、変更されたファイルから影響を受けるプロジェクトの集合を導きます。パイプラインはその集合だけをビルドしテストします。これを正しく行うことが、大きな monorepo の CI を過酷ではなく高速に保ちます。

cache と並列性

リモートの build cache とタスクの並列性は大規模では不可欠です。変更されていないプロジェクトは cache された結果を再利用し、独立したタスクは並行して動きます。それらがなければ、monorepo の CI 時間は変更ではなく repo 全体とともに増えます。

monorepo の CI をスケールさせる

選択的なビルドに cache と並列性を加えることで monorepo のパイプラインは高速に保たれますが、それらはウォームで cache を備えた runner に強く依存します。Latchkey の runner は依存と build の cache をウォームに保つため、影響を受けるプロジェクトのビルドはコールドから始めるのではなく以前の作業を再利用します。

重要なポイント

monorepo アーキテクチャは、多数のプロジェクトを共有 tooling とともに1つの repository に保つ。
monolith ではない。独立してデプロイ可能な多数のサービスを含みうる。
選択的なビルド、cache、並列性こそが、monorepo の CI を高速に保つ。