parent-childパイプラインとは何か？大きなパイプラインを分割する

parent-childパイプラインは、大きなパイプラインを、1つ以上のchildパイプラインを起動するparentに分解します。通常はコンポーネントまたはエリアごとに1つです。

大きなリポジトリが行うすべてを記述する単一のパイプラインファイルは、読みにくく、メンテナンスが遅くなります。parent-childパターンはそれを分割します。小さなparentパイプラインが何が変わったかを判断し、影響を受けたコンポーネントのために焦点を絞ったchildパイプラインを起動します。各childはよりシンプルで、影響を受けないコンポーネントは実行されません。

分割の仕組み

parentパイプラインが最初に実行され、ディスパッチャーとして機能します。何が変わったかを検査し、関連するchildパイプラインだけを動的に起動できます。各childはコードベースの1部分のための自己完結したパイプラインです。

なぜこう分割するのか

コンポーネントごとの小さく読みやすいconfig。
変更の影響を受けたchildだけを実行する。
チームが自分のchildパイプラインを独立してオーナーとして持つ。

簡単な例

frontend/、backend/、infra/ を持つmonorepoでは、parentがどのフォルダが変わったかを検出し、それらのchildパイプラインだけを起動します。docsのみの変更は、backendとinfraのchildを完全にスキップします。

parent-child vs ダウンストリーム

parent-childパイプラインは通常同じプロジェクトに存在し、組織化のために分割されます。ダウンストリームパイプラインは多くの場合別のプロジェクトへ渡ります。メカニズムは重なりますが、意図は異なります。構造化 vs プロジェクト間の連鎖です。

コスト面の利点

影響を受けないchildは実行されないため、このパターンは大きなリポジトリでの無駄な計算を削ります。計測されるランナー（Latchkey）と組み合わせれば、各childパイプラインがいくらかかるかを見て、めったに何も捕捉しないものを刈り取れます。

重要なポイント

parent-childパイプラインは、大きなパイプラインをディスパッチャーとchildに分割します。
parentは、変更の影響を受けたchildパイプラインだけを起動します。
configを読みやすく保ち、無関係なコンポーネントの実行を避けます。