モノレポとは?
モノレポは、多数のプロジェクト - app、ライブラリ、サービス - を単一のリポジトリに、1つの履歴と1セットのtoolingとともに格納します。
プロジェクトごとにリポジトリを持つのではなく、モノレポはそれらすべてをまとめて保持します。これにより、プロジェクトをまたぐ変更がアトミックになり、toolingが一貫しますが、CIには実際に変更されたものだけをbuildする賢さが求められます。
モノレポとは何か
依存関係、build設定、そしてコミット履歴を共有する複数の異なるプロジェクトを含む、単一のバージョン管理されたリポジトリです。大企業や多くのオープンソースエコシステムがこのモデルを使用しています。
CIの課題: affected build
素朴なモノレポのpipelineは、すべての変更のたびにすべてを再buildして再テストします - 遅く、無駄が多いです。解決策は変更検出です: あるコミットがどのプロジェクトに影響するかを計算し、それらと依存先のみに対してCIを実行します。
小さな例
NxやTurborepoのようなツールは「affected」コマンドを提供します - nx affected --target=test はdiffで触れられたプロジェクトとその依存先のみでテストを実行するため、あるパッケージ内の1行の変更でリポジトリ全体を再テストすることはありません。
cachingの重要性が増す
モノレポのbuildは多数のプロジェクトに触れるため、共有されたremote build cacheは非常に大きな見返りをもたらします: 変更されていないプロジェクトは再buildされる代わりにcacheから復元され、pipelineの時間をリポジトリではなく変更に比例させ続けます。
検討すべきトレードオフ
モノレポはプロジェクトをまたぐアトミックな変更と統一されたtoolingをもたらしますが、大きくなり、クローンが遅くなることがあり、規律ある変更検出を必要とします。CIへの投資は大きくなりますが、スケールにおける見返りも大きくなります。
重要なポイント
- モノレポは多数のプロジェクトを、共有されたtoolingとともに1つのリポジトリに保持します。
- CIはaffectedなプロジェクトを検出し、それらと依存先のみをbuildする必要があります。
- 共有されたremote cachingはモノレポで特に価値があります。