【入門編】モノレポ対応の限界突破：CircleCIで特定のディレクトリ変更のみを検知し、対象ジョブだけを走らせる高度なフィルタリング設定 – バージョン管理・CI/CD活用バイブル

やあ、皆さん！今日も元気に開発してますか？

今日のテーマは、多くの開発者が頭を悩ませる「モノレポ」におけるCI/CDの最適化、特にCircleCIでの究極のフィルタリング設定について、僕の持てる知識のすべてを皆さんにお伝えします。

「モノレポ、便利なんだけど、CIのビルド時間が長すぎて…」「ちょっとした変更なのに、全部のサービスがビルドされちゃうんだよね…」

そんな悩みを抱えているあなた！もう大丈夫です。この記事を読み終える頃には、あなたのCI/CDパイプラインは劇的にスマートに、そして高速に生まれ変わっているはず。

一般的な`path-filtering orb`では実現しきれない、一歩先の「`git diff`を活用したカスタムスクリプト」による複雑な条件分岐の構築法を、優しい先輩エンジニアの口調で、じっくりと、そして丁寧に解説していきますね。これをマスターすれば、毎日の作業が劇的に楽になりますよ！

—

🚀 モノレポのビルド地獄に終止符を！CircleCIで`git diff`を活用した超効率的な条件付きジョブ実行術

1. モノレポ、最高！…でもCIがボトルネックになっていませんか？

最近では、フロントエンド、バックエンド、共有ライブラリなど、複数のプロジェクトを一つのリポジトリで管理する「モノレポ」を採用するチームが増えてきましたよね。コードの再利用性が高まったり、依存関係の管理が楽になったりと、多くのメリットがあります。

しかし、その一方で、モノレポ特有の課題も浮上してきます。その最たるものが、CI/CDの実行時間とコストの増大です。

  • フロントエンドの小さな修正をしただけなのに、バックエンドも、そして全てのマイクロサービスまでCIが走ってしまう…
  • プルリクエストを出すたびに、無関係なサービスまでビルド・テストが実行され、承認までに時間がかかる…
  • 結果的に、CI/CDの実行コストも膨れ上がり、開発者の生産性も落ちてしまう…

こんな経験、ありませんか？

僕もかつて、この問題に直面し、夜な夜なコーヒー片手に唸っていた時期がありました。でも、安心してください。CircleCIの力を最大限に引き出し、この課題をスマートに解決する方法があるんです。

2. CircleCIを始めよう！あなたの最初のCI/CD体験

まず、今回のテクニックに入る前に、CircleCIに初めて触れる方もいらっしゃるかもしれないので、CircleCIの基本をサクッと確認しておきましょう。

2.1. CircleCIって何？

CircleCIは、GitHubやBitbucketなどのバージョン管理システムと連携し、コードの変更がプッシュされるたびに自動でビルド、テスト、デプロイといった一連のプロセス（CI/CDパイプライン）を実行してくれるクラウドサービスです。これにより、開発者は品質の高いソフトウェアを、より迅速に、そして安定してリリースできるようになります。

2.2. アカウント開設とGitHub連携

1. CircleCIにアクセス: まずは[CircleCIの公式サイト](https://circleci.com/)にアクセスします。
2. サインアップ: 「Sign Up」ボタンから、GitHubまたはBitbucketアカウントを使ってサインアップします。通常、GitHubアカウントを使うのが最も簡単です。
3. GitHubリポジトリの選択: 連携したいGitHubのリポジトリを選択し、CircleCIがアクセスすることを許可します。これで、CircleCIがあなたのリポジトリの変更を検知できるようになります。

2.3. 最初の`config.yml`を書いてみよう（Hello World）

CircleCIは、リポジトリのルートディレクトリにある`.circleci/config.yml`というファイルの内容に基づいてパイプラインを実行します。これが、あなたのCI/CDパイプラインの設計図になります。

まずは、シンプルな「Hello World」プロジェクトで、基本的な動きを見てみましょう。

ステップ1: サンプルリポジトリの作成

GitHubに`my-monorepo-example`という名前の新しいリポジトリを作成してください。そして、以下のようなディレクトリ構成とファイルを作成します。

my-monorepo-example/
├── .circleci/
│ └── config.yml <-- ここに設定ファイルを書きます ├── frontend/ │ └── src/ │ └── App.js │ └── package.json ├── backend/ │ └── src/ │ └── index.js │ └── package.json └── shared-lib/ └── utils.js ステップ2: `.circleci/config.yml`の作成

`my-monorepo-example/.circleci/config.yml`ファイルに以下の内容を書き込み、コミットしてGitHubにプッシュしてください。

.circleci/config.yml
CircleCI設定ファイルのバージョンを指定します。現在の推奨は2.1です。
version: 2.1

ジョブの定義
jobs:
# frontend-buildという名前のジョブ
frontend-build:
# 実行環境としてNode.js 16のDockerイメージを使用します
docker:

  • image: cimg/node:16.10

# ジョブが実行されるディレクトリを指定します
working_directory: ~/repo/frontend
steps:
# GitHubからリポジトリのコードをチェックアウトします

  • checkout:

path: ~/repo
# frontendディレクトリに移動し、Node.jsの依存関係をインストールします

  • run:

name: Install Frontend Dependencies
command: |
cd frontend
npm install
# frontendのビルドコマンドを実行します（ここではダミーの表示）

  • run:

name: Build Frontend
command: |
cd frontend
echo “Building frontend application…”
# npm run build # 実際のプロジェクトではこのコマンドを実行します
echo “Frontend build completed!”

# backend-buildという名前のジョブ
backend-build:
docker:

  • image: cimg/node:16.10

working_directory: ~/repo/backend
steps:

  • checkout:

path: ~/repo

  • run:

name: Install Backend Dependencies
command: |
cd backend
npm install

  • run:

name: Build Backend
command: |
cd backend
echo “Building backend API…”
# npm run build # 実際のプロジェクトではこのコマンドを実行します
echo “Backend build completed!”

ワークフローの定義
複数のジョブの実行順序や条件を制御します
workflows:
# build_and_testという名前のワークフロー
build_and_test:
jobs:
# frontend-buildジョブを実行します

  • frontend-build

# backend-buildジョブを実行します

  • backend-build

この`config.yml`をコミットしてGitHubにプッシュすると、CircleCIが自動的に検知し、`frontend-build`と`backend-build`の2つのジョブを実行するはずです。CircleCIのダッシュボードで、パイプラインが成功するのを確認してください。

これで、CircleCIの基本的なセットアップは完了です！

3. 「とりあえず全部動かす」が通用しなくなる時：モノレポのCI課題

先ほどの例では、`frontend`のコードを変更しただけでも、`frontend-build`と`backend-build`の両方が実行されてしまいます。小規模なモノレポならまだ良いですが、サービスが増えれば増えるほど、この「無関係なジョブの実行」が大きな問題となってきます。

3.1. 増え続けるビルド時間とコスト

想像してみてください。10個のサービスを持つモノレポで、それぞれが10分かかるビルドジョブを持っているとします。一つの変更で全部が走ると、それだけで100分。これは開発者がプルリクエストをマージするのを待つ時間となり、生産性を大きく阻害します。さらに、CircleCIのクレジット消費も増大し、コストも跳ね上がります。

3.2. なぜ`path-filtering orb`だけでは不十分なのか？

CircleCIには、`path-filtering orb`という便利なツールがあります。これは、特定のパスに変更があった場合にのみ、ジョブを実行させるための公式のOrb（再利用可能な設定パッケージ）です。

例えば、以下のように設定できます。

path-filtering orb を使う場合の例 (参考)
.circleci/config.yml (一部抜粋)
orbs:
path-filtering: circleci/path-filtering@0.1.3

workflows:
build_and_test:
jobs:

  • frontend-build:

filters: path-filter-frontend

  • backend-build:

filters: path-filter-backend
# …

これは非常に便利で、多くのケースで十分な働きをしてくれます。しかし、以下のようなケースでは、`path-filtering orb`だけでは対応が難しいことがあります。

  • より複雑な条件: 特定のディレクトリだけでなく、ファイル名パターンや複数のディレクトリの組み合わせで条件を判定したい場合。
  • 動的なジョブ選択: 変更内容に応じて、実行するジョブのセットを動的に変更したい場合。例えば、`shared-lib`が変更されたら、それに依存する`frontend`と`backend`の両方を動かしたい、といった依存関係を考慮した実行。
  • パイプラインパラメータへの複雑な影響: 変更されたディレクトリの情報に基づいて、後続のジョブに動的なパラメータを渡したい場合。

さあ、ここからが本番です！これらの課題を解決し、CI/CDパイプラインを真にスマートにするための「限界突破」のテクニックを見ていきましょう。

4. 限界突破の鍵：`git diff`とカスタムスクリプトの融合

僕たちが目指すのは、「何が変更されたか」を正確に検知し、その情報に基づいて「必要なジョブだけを実行する」ことです。そのための鍵となるのが、バージョン管理システムであるGitの強力なコマンド`git diff`と、それをCircleCIのパイプラインに組み込むためのカスタムスクリプトです。

4.1. `git diff`の魔法：変更されたファイルだけを検知する

`git diff`コマンドは、Gitリポジトリ内の2つのコミット、ブランチ、または作業ツリー間の変更内容を表示するために使われます。特に、`–name-only`オプションを使うと、変更されたファイルの名前だけをリストアップできます。

今回のキモとなるのは、現在のブランチがベースブランチ（例えば`main`ブランチ）からどれだけ変更されたかを検知することです。

`git diff –name-only …HEAD`

  • ``: 比較対象となる基準のブランチ（例: `main`, `develop`）。
  • `…HEAD`: 現在のブランチの最新コミットと、ベースブランチの共通祖先以降の変更を比較します。これにより、プルリクエストでマージされる可能性のある変更のみを効率的に検出できます。

このコマンドで得られた変更ファイルリストを、カスタムスクリプトで解析し、「どのディレクトリに、どのような変更があったか」を判断します。

4.2. カスタムスクリプトの設計思想

カスタムスクリプトの役割は大きく分けて2つです。

1. 変更検知: `git diff`コマンドを使って、変更されたファイルをリストアップします。
2. 実行条件の判断と出力: リストアップされたファイルパスに基づいて、どのサービス（`frontend`, `backend`, `shared-lib`など）に変更があったかを判断し、その結果をCircleCIのパイプラインパラメータとして出力します。

このパイプラインパラメータを使うことで、`config.yml`内でジョブの実行条件を柔軟に制御できるようになります。

5. 実践！`check_changes.sh`スクリプトの構築

では、実際にカスタムスクリプトを作成してみましょう。ここでは、`check_changes.sh`という名前でスクリプトを作成します。

ステップ1: スクリプトファイルの作成

`my-monorepo-example`リポジトリのルートディレクトリに、`check_changes.sh`というファイルを作成します。

check_changes.sh
!/bin/bash

ベースとなるブランチ名を指定します。
通常は main や develop ブランチですが、環境に合わせて変更してください。
BASE_BRANCH=”main”

変更があったディレクトリを判定するためのフラグを初期化します。
デフォルトでは全てfalse（変更なし）とします。
FRONTEND_CHANGED=”false”
BACKEND_CHANGED=”false”
SHARED_LIB_CHANGED=”false”

echo “Detecting changes against branch: $BASE_BRANCH”

Git diff を使って、現在のブランチとベースブランチの差分を検知します。
–name-only: 変更されたファイル名のみを表示
$(git merge-base $BASE_BRANCH HEAD)…HEAD: ベースブランチとの共通祖先からの差分を比較
これは、プルリクエストのマージ元となるブランチの変更を正確に捉えるのに役立ちます。
CHANGED_FILES=$(git diff –name-only “$(git merge-base $BASE_BRANCH HEAD)” HEAD)

変更されたファイルがない場合
if [ -z “$CHANGED_FILES” ]; then
echo “No changes detected.”
else
echo “Changed files:”
echo “$CHANGED_FILES”
fi

変更されたファイルを一行ずつ処理し、どのサービスに変更があったかを判定します。
for FILE_PATH in $CHANGED_FILES; do
if [[ “$FILE_PATH” == frontend/ ]]; then
FRONTEND_CHANGED=”true”
elif [[ “$FILE_PATH” == backend/ ]]; then
BACKEND_CHANGED=”true”
elif [[ “$FILE_PATH” == shared-lib/ ]]; then
SHARED_LIB_CHANGED=”true”
fi
done

shared-lib に変更があった場合、それに依存する frontend と backend もビルド対象とします。
if [ “$SHARED_LIB_CHANGED” = “true” ]; then
FRONTEND_CHANGED=”true”
BACKEND_CHANGED=”true”
fi

echo “— Change Detection Summary —”
echo “Frontend Changed: $FRONTEND_CHANGED”
echo “Backend Changed: $BACKEND_CHANGED”
echo “Shared Lib Changed: $SHARED_LIB_CHANGED”
echo “——————————”

CircleCIのパイプラインパラメータとして結果を出力します。
これにより、config.yml内でこれらの値を受け取り、ジョブの実行条件として利用できます。
echo “export GITHUB_FRONTEND_CHANGED=$FRONTEND_CHANGED” >> $BASH_ENV
echo “export GITHUB_BACKEND_CHANGED=$BACKEND_CHANGED” >> $BASH_ENV
echo “export GITHUB_SHARED_LIB_CHANGED=$SHARED_LIB_CHANGED” >> $BASH_ENV

さらに、CircleCIのパイプラインパラメータとして直接値を渡すこともできます。
これはより動的なワークフローを構築する際に強力です。
ただし、実行時にパラメータを動的に設定するには、`setup`ワークフローが必要です。
例：echo “frontend_changed=$FRONTEND_CHANGED” >> /tmp/pipeline_parameters.txt
echo “backend_changed=$BACKEND_CHANGED” >> /tmp/pipeline_parameters.txt

スクリプトのポイント解説:

  • `BASE_BRANCH=”main”`: 比較対象とする基準ブランチを設定します。あなたのリポジトリのメインブランチに合わせて変更してください。
  • `git diff “$(git merge-base $BASE_BRANCH HEAD)” HEAD`: ここが非常に重要です。
  • `git merge-base $BASE_BRANCH HEAD`は、現在のブランチ(`HEAD`)と基準ブランチ(`$BASE_BRANCH`)の共通祖先（最も最近共通していたコミット）を特定します。
  • その共通祖先コミットから現在の`HEAD`までの差分を見ることで、プルリクエストでマージされることになる「純粋な変更」だけを正確に検出できます。これにより、無関係なコミットによる差分を拾うのを防ぎます。
  • `for FILE_PATH in $CHANGED_FILES; do … done`: 変更されたファイルリストをループで処理し、ファイルパスがどのディレクトリに属するかを`if [[ “$FILE_PATH” == / ]]`で判定しています。
  • `if [ “$SHARED_LIB_CHANGED” = “true” ]; then … fi`: `shared-lib`が変更された場合は、それに依存する`frontend`と`backend`も自動的にビルド対象とする、という依存関係ロジックを組み込んでいます。これはモノレポにおける重要な応用例です。
  • `echo “export GITHUB_FRONTEND_CHANGED=$FRONTEND_CHANGED” >> $BASH_ENV`: これがCircleCIに結果を伝えるキモです。`$BASH_ENV`はCircleCIが提供する特殊なファイルで、ここに`export`コマンドで環境変数を書き込むと、その後のステップやジョブでその環境変数が利用可能になります。

ステップ2: 実行権限の付与

このスクリプトが実行できるように、実行権限を付与しておくことを忘れずに。

chmod +x check_changes.sh

6. CircleCI `config.yml`の劇的進化：条件付きジョブ実行の実現

さあ、作成した`check_changes.sh`スクリプトを`config.yml`に組み込み、パイプラインを劇的に進化させましょう！

6.1. `parameters`でスクリプトの結果を受け取る

CircleCI 2.1では、ワークフローやジョブに`parameters`を定義できます。これを使って、スクリプトが判定した「変更フラグ」を動的に受け取ります。

6.2. `when`条件でジョブの実行を制御する

`when`条件を使うと、特定のパラメータが`true`の場合にのみジョブを実行する、といった制御が可能になります。これが、無駄なジョブ実行をなくすための直接的な手段です。

6.3. 具体的なワークフロー例（`frontend`と`backend`を持つモノレポ）

先ほどの`.circleci/config.yml`を以下のように更新します。

.circleci/config.yml
version: 2.1

パイプライン全体で利用できるパラメータを定義します。
これらのパラメータは、`setup`ワークフローの結果として動的に設定されます。
parameters:
run_frontend_build:
type: boolean
default: false
run_backend_build:
type: boolean
default: false

ジョブの定義
jobs:
# 変更検知用のジョブ
detect_changes:
docker:

  • image: cimg/node:16.10 # gitコマンドが使えるイメージであれば何でもOK

steps:

  • checkout

# スクリプトに実行権限を付与します

  • run:

name: Grant execute permission to check_changes.sh
command: chmod +x check_changes.sh
# 変更検知スクリプトを実行します。
# ここで $BASH_ENV に書き込まれた環境変数は、このジョブ内でのみ有効です。
# パイプラインパラメータに値を渡すために、`setup`ワークフローと連携させます。

  • run:

name: Run change detection script
command: |
./check_changes.sh
# スクリプトで設定した環境変数をパイプラインパラメータとして渡すための準備
# CircleCIのPipeLine Parametersに渡すためのJSONファイルを生成
echo “pipeline_parameters: { \”run_frontend_build\”: $GITHUB_FRONTEND_CHANGED, \”run_backend_build\”: $GITHUB_BACKEND_CHANGED }” > /tmp/pipeline_params.json
# 生成したJSONファイルをワークフローに渡します。

  • persist_to_workspace:

root: /tmp
paths:

  • pipeline_params.json

# frontend-build ジョブ
frontend-build:
docker:

  • image: cimg/node:16.10

working_directory: ~/repo/frontend
steps:

  • checkout:

path: ~/repo

  • run:

name: Install Frontend Dependencies
command: |
cd frontend
npm install

  • run:

name: Build Frontend
command: |
cd frontend
echo “Building frontend application…”
echo “Frontend build completed!”

# backend-build ジョブ
backend-build:
docker:

  • image: cimg/node:16.10

working_directory: ~/repo/backend
steps:

  • checkout:

path: ~/repo

  • run:

name: Install Backend Dependencies
command: |
cd backend
npm install

  • run:

name: Build Backend
command: |
cd backend
echo “Building backend API…”
echo “Backend build completed!”

ワークフローの定義
workflows:
# setup ワークフロー: パイプラインパラメータを動的に設定するために使用します。
# このワークフローは常に実行され、`detect_changes`ジョブの結果に基づいて
# 次の`build_and_test`ワークフローのパラメータを設定します。
setup:
# CircleCIの特殊な属性で、このワークフローがパイプラインパラメータを動的に設定することを示します。
# この`setup`ワークフローの実行後、`build_and_test`ワークフローが再実行されます。
when: << pipeline.in_setup >>
jobs:

  • detect_changes

# `continuation/continue`コマンドは、`detect_changes`ジョブで生成された
# `/tmp/pipeline_params.json`を読み込み、次のワークフローにパラメータを渡します。

  • continuation/continue:

requires:

  • detect_changes

parameters: /tmp/pipeline_params.json

# build_and_test ワークフロー: 実際のビルドとテストを実行します。
# このワークフローは`setup`ワークフローによってパラメータが設定された後に実行されます。
build_and_test:
# `setup`ワークフローが実行されていない場合、このワークフローはスキップされます。
when: << pipeline.continues_with_parameters >>
jobs:

  • frontend-build:

# `when`条件を使って、`run_frontend_build`パラメータがtrueの場合のみジョブを実行します。
when: << pipeline.parameters.run_frontend_build >>

  • backend-build:

when: << pipeline.parameters.run_backend_build >>

新しい`config.yml`のポイント解説:

  • `parameters`: パイプラインのトップレベルで`run_frontend_build`と`run_backend_build`というブーリアン型のパラメータを定義しました。これらが、各ジョブを実行するかどうかのフラグになります。
  • `detect_changes`ジョブ:
  • `checkout`でリポジトリをクローンします。
  • `chmod +x check_changes.sh`でスクリプトに実行権限を与えます。
  • `./check_changes.sh`でスクリプトを実行します。
  • `echo “pipeline_parameters: { … }” > /tmp/pipeline_params.json`: これが最も重要な部分です。スクリプトの結果（`$GITHUB_FRONTEND_CHANGED`, `$GITHUB_BACKEND_CHANGED`）を使って、`pipeline_parameters`というキーを持つJSONファイルを作成します。このJSONファイルは、CircleCIのパイプラインパラメータを動的に設定するために使われます。
  • `persist_to_workspace`: `/tmp/pipeline_params.json`をワークスペースに保存し、後続のジョブ（特に`continuation/continue`）で利用できるようにします。
  • `setup`ワークフローと`continuation/continue` Orb:
  • `when: << pipeline.in_setup >>`: このワークフローは、パイプラインが最初に開始されたときに自動的に実行されます。
  • `continuation/continue` Orbは、CircleCIの「パイプラインの継続」機能を使うための公式Orbです。`detect_changes`ジョブの後にこれを実行することで、`detect_changes`ジョブが生成したJSONファイル（`/tmp/pipeline_params.json`）を読み込み、その内容を次のワークフロー（`build_and_test`）のパイプラインパラメータとして渡します。これにより、`detect_changes`の結果に基づいて、後続のジョブの実行を制御できるようになります。
  • `build_and_test`ワークフロー:
  • `when: << pipeline.continues_with_parameters >>`: このワークフローは、`setup`ワークフローによってパラメータが設定され、パイプラインが継続された場合にのみ実行されます。
  • `frontend-build`と`backend-build`ジョブに、それぞれ`when: << pipeline.parameters.run_frontend_build >>`と`when: << pipeline.parameters.run_backend_build >>`という条件を追加しました。
  • これにより、`detect_changes`ジョブで`run_frontend_build`が`true`と判定された場合にのみ`frontend-build`が実行され、`false`の場合はスキップされます。`backend-build`も同様です。

動作確認:

1. `config.yml`と`check_changes.sh`をコミットしてGitHubにプッシュしてください。
2. CircleCIのダッシュボードで、`setup`ワークフローが実行され、その後`build_and_test`ワークフローが開始されることを確認します。最初は両方のジョブが実行されるはずです（`check_changes.sh`が初期コミットを検知するため）。
3. 次に、`frontend/src/App.js`だけを少し変更してコミットし、プッシュしてください。
4. CircleCIのダッシュボードで、`frontend-build`ジョブだけが実行され、`backend-build`ジョブがスキップされていることを確認できれば大成功です！
5. 同様に、`backend/src/index.js`だけを変更した場合、`backend-build`だけが実行されることを確認します。
6. `shared-lib/utils.js`を変更した場合、`frontend-build`と`backend-build`の両方が実行されることを確認します。

これで、あなたのモノレポは劇的に効率的なCI/CDパイプラインを手に入れました！

7. 先輩からのアドバイス：さらなる最適化と運用術

このテクニックは強力ですが、さらにCI/CDパイプラインを磨き上げ、チームでうまく運用していくためのポイントをいくつかご紹介しましょう。

7.1. ベースブランチの選び方

`check_changes.sh`で指定する`BASE_BRANCH`は重要です。

  • `main`や`develop`: これらは安定版や開発版の基準となるブランチです。プルリクエストのベースブランチとして適切です。
  • `origin/$BASE_BRANCH`: リモートリポジトリのブランチを指すことで、ローカルのブランチとの差分ではなく、常に最新の共有状態との差分を比較できます。通常はこちらを推奨します。

7.2. プルリクエスト時の特別な考慮

プルリクエスト（PR）では、PRのソースブランチとターゲットブランチ（例: `main`）との差分を比較することが重要です。今回の`git diff “$(git merge-base $BASE_BRANCH HEAD)” HEAD`は、まさにこのPRシナリオに最適化された比較方法です。CircleCIはPRが作成されるたびにパイプラインを実行するため、この設定で適切に機能します。

7.3. キャッシュと並列化で速度をさらに引き出す

  • 依存関係のキャッシュ: `npm install`や`yarn install`などのパッケージインストールは時間がかかります。`save_cache`と`restore_cache`ステップを使って、依存関係のダウンロード結果をキャッシュすることで、次回のビルド時間を大幅に短縮できます。
  • テストの並列化: `frontend`や`backend`のテストが長時間を要する場合、CircleCIの並列実行機能（`parallelism`）を活用し、テストを複数のコンテナで同時に実行することで、トータルのテスト時間を短縮できます。

7.4. スクリプトのテストとメンテナンス

カスタムスクリプトは、パイプラインの心臓部です。

  • ローカルでのテスト: コミットする前に、必ずローカルで`check_changes.sh`を実行し、期待通りの結果（どのフラグが`true`になるか）が得られるかを確認しましょう。
  • エラーハンドリング: スクリプト内でエラーが発生した場合に備え、適切なエラーメッセージを表示したり、`exit 1`でジョブを失敗させるなどのエラーハンドリングを強化することも重要です。
  • コメントとドキュメント: スクリプトが複雑になったら、コメントを増やしたり、リポジトリのREADMEに説明を追記したりして、他のチームメンバーが理解しやすいようにしましょう。

7.5. チームとの合意形成

この高度なフィルタリング設定は、チーム全体の開発フローに影響を与えます。

  • ルールの共有: 「`shared-lib`が変わったら、依存するサービスはすべてビルドされる」といったルールをチームで共有し、全員が理解しておくことが重要です。
  • 依存関係の明確化: サービス間の依存関係を明確に定義し、コードベースが成長してもスクリプトが正しく機能するように定期的に見直しましょう。

8. まとめ：これであなたのCI/CDはネクストレベルへ！

お疲れ様でした！今回は、CircleCIでモノレポのビルド時間を劇的に最適化するための、`git diff`とカスタムスクリプトを組み合わせた高度なフィルタリング設定について解説しました。

このテクニックを導入することで、以下のようなメリットが得られます。

  • CI/CD時間の劇的な短縮: 無関係なジョブが実行されなくなり、プルリクエストの承認プロセスが高速化します。
  • コストの削減: CI/CDの実行回数が減ることで、クラウドサービスのクレジット消費を抑えられます。
  • 開発者の満足度向上: 待機時間が減り、よりスムーズな開発体験が得られます。
  • スケーラブルなモノレポ運用: サービスが増えても、CI/CDパイプラインが破綻することなく、効率的にスケールできます。

最初は少し複雑に感じるかもしれませんが、一度構築してしまえば、あなたのチームの生産性は飛躍的に向上するはずです。

もし途中でつまずいたらいつでも僕を頼ってください。これをマスターすれば、毎日の作業が劇的に楽になりますよ。ぜひ、あなたのプロジェクトで試してみてくださいね！

それでは、Happy Hacking！

スポンサーリンク
タイトルとURLをコピーしました