こんにちは。大規模開発の現場で、毎日「CIの完了待ち」にコーヒーを何杯も飲んでいませんか？
モノレポ（単一リポジトリ）はコードの共有や依存関係の管理には最高ですが、肥大化すると「たった一行の修正で、プロジェクト全体をビルドし直す」という拷問のような時間が待っています。
今日は、GitLab CIの奥義「Parent-Child Pipelines」を使って、この地獄から脱却し、必要な箇所だけをピンポイントで超速ビルドする設計術を伝授します。これをマスターすれば、あなたのチームの開発サイクルは別次元の速さに進化します。
—
1. なぜ「Parent-Child Pipelines」なのか？
従来の単一パイプラインでは、どれだけ頑張って `rules:changes` を設定しても、YAMLファイルが数千行に膨れ上がり、管理不能になります。
Parent-Child Pipelinesの本質は、「親パイプライン（指揮官）」が「子パイプライン（専門チーム）」を動かす構造にあります。
- 親: 変更されたディレクトリを検知し、適切な子パイプラインを呼び出す。
- 子: 自分の担当領域（ディレクトリ）のテストとビルドだけを完結させる。
これにより、CIの設定が疎結合になり、特定のプロジェクトでエラーが起きても全体に影響しにくくなります。
—
2. まずはここから：極小セットアップ
まずは、構造を理解するための最小構成を作ってみましょう。
構成図
/
├── .gitlab-ci.yml (親)
├── services/
│ ├── auth/
│ │ ├── .gitlab-ci.yml (子)
│ │ └── …
│ └── payment/
│ ├── .gitlab-ci.yml (子)
│ └── …
親パイプラインの設定 (`.gitlab-ci.yml`)
ここでは「どのディレクトリが変わったか」を検知し、動的にパイプラインを生成します。
親パイプラインの設定
stages:
- trigger
trigger-auth:
stage: trigger
trigger:
include: services/auth/.gitlab-ci.yml # 子を呼び出す
strategy: depend # 子の完了を待つ設定
rules:
- changes:
- services/auth// # auth配下が変わった時だけ実行！
子パイプラインの設定 (`services/auth/.gitlab-ci.yml`)
子側は、自分自身が実行されることだけを考えればOKです。
子パイプラインの設定
stages:
- test
- build
test-auth:
stage: test
script:
- echo “authサービスのテストを実行中…”
# ここに実際のテストコマンドを記述
—
3. 【現場の知見】劇的に速くするための3つのハック
ここからが、現場で差がつくポイントです。ただ分割するだけでなく、以下の戦略を組み込んでください。
① `strategy: depend` の使い分け
親パイプラインで `strategy: depend` を使うと、子パイプラインが失敗した時に親も失敗扱いになります。厳格なリリースフローでは必須ですが、並列実行を優先したい場合は外すことも検討してください。
② `rules:changes` と `paths` の最適化
モノレポでは、共通ライブラリが変更された際に「全サービスをリビルドする」必要があります。
親の設定例：共通ライブラリが変わったら全サブシステムを走らせる
trigger-all:
trigger:
include: services/auth/.gitlab-ci.yml
rules:
- changes:
- libs/common//
- services/auth//
このように、`changes` に依存関係を記述することで、無駄なCI時間を徹底的に削ぎ落とせます。
③ キャッシュとアーティファクトの共有
子パイプライン間は独立しているため、`cache` をうまく活用しましょう。S3などの外部ストレージを `cache` のバックエンドに設定しておけば、別ブランチ間でもキャッシュが効き、ビルド時間が数分から数秒に短縮されます。
—
4. 導入のステップと確認のコツ
1. まずは1つのサービスから: いきなり全ディレクトリを移行せず、最もCIが重いサービスを1つ選び、子パイプライン化してください。
2. GitLab UIでの確認: GitLabのパイプライン画面を見てください。親パイプラインのグラフの中に、さらに階層化されたパイプラインが表示されるはずです。これが成功のサインです。
3. 変数の受け渡し: 親から子へ変数を渡したい場合は `trigger:forward` を活用します。`yaml_variables: true` を使うと、動的に生成した変数を子に渡すことが可能です。
—
最後に：エンジニアとして一番大切なこと
大規模モノレポでのCI高速化は、単なる「時短」ではありません。「開発者のフィードバックループを速くする」ことこそが、プロダクトの品質を劇的に高めます。
待たされる時間が減れば、エンジニアはコードの改善や設計の深い思考に集中できます。今日紹介したこの「階層化」という武器を使って、あなたのリポジトリを世界で一番速いCI環境へと育て上げてみてください。
もし、設定で行き詰まったら、いつでもGitLabの公式ドキュメントにある「Parent-Child Pipelines」の深淵を覗いてみてください。今日お話ししたことが、より深く理解できるはずです。
さあ、次はあなたの番です。最高のCI環境を構築しましょう！