モノレポで複数のアプリケーションを管理していると、こんな悩みはありませんか？
- App1を修正しただけなのに全アプリのテストが走る
- Unit TestやIntegration Testに1時間以上かかる
- PRごとに長時間待たされ、開発効率が落ちる
- 品質は担保したいが、CIコストも抑えたい
今回は、GitHub ActionsとMerge Queueを利用して、「変更したアプリだけをマージ直前にテストする」運用を紹介します。
前提
今回のリポジトリ構成は以下のようなモノレポです。
apps/
├── App1
├── App2
└── App3
shared/
-
apps：各アプリケーション -
shared：共通ライブラリ
各アプリにはそれぞれテストプロジェクトがあります。
やりたいこと
App2だけ修正した場合は
App2
↓
App2のテストだけ実行
共通ライブラリを修正した場合は
shared
↓
App1
App2
App3
すべてテスト
つまり、影響のあるアプリだけを検証したいわけです。
最初に考えた方法
最初は
main
├── dev-app1
├── dev-app2
└── dev-app3
のようにアプリごとに開発ブランチを分けようと考えました。
しかし、この方法には問題があります。
- ブランチ運用が複雑になる
- 複数アプリを跨ぐ修正に弱い
- 共通ライブラリ変更時の扱いが難しい
結果として、ブランチ戦略ではなくCI側で解決した方がシンプルでした。
PRでは軽量チェックだけ
PR作成時には
- Build
- Formatter
- Analyzer
程度の軽量チェックのみ実施します。
この時点では1時間かかるテストは実行しません。
Merge Queueで重いテストを実施
GitHubのMerge Queueを利用すると、
PR
↓
レビュー
↓
Merge Queue
↓
GitHubが一時マージブランチを作成
↓
GitHub Actions実行
↓
成功
↓
mainへ自動マージ
という流れになります。
ここで初めて重いテストを実行します。
これにより、
- 開発者はPRのたびに1時間待たなくて済む
- mainへ入るコードの品質は保証できる
というメリットがあります。
変更されたアプリだけテストする
ここで利用するのが dorny/paths-filter です。
例えば
- uses: dorny/paths-filter@v3
id: filter
with:
filters: |
app1:
- 'apps/App1/**'
- 'shared/**'
app2:
- 'apps/App2/**'
- 'shared/**'
これだけで
- App1が変更されたか
- App2が変更されたか
を判定できます。
その結果を利用して
App2変更
↓
App2のテスト実行
App1変更なし
↓
スキップ
という制御ができます。
Required Checkは1つだけ
最初は
app1-test
app2-test
app3-test
のようにジョブを分けようと考えました。
しかし、アプリが増えるほどBranch Protectionの設定も増えてしまいます。
そこでおすすめなのが
detect
↓
test
という2ジョブ構成です。
detectで変更箇所を判定し、
testで必要なテストだけを実行します。
Branch Protectionでは
test
だけをRequired Checkに設定すればよく、GitHub側の設定も非常にシンプルになります。
Branch Protection設定
mainブランチには以下を設定します。
- Require a pull request before merging
- Require merge queue
- Require status checks to pass before merging
Required Checkにはtestジョブのみを登録します。
これで
テスト成功
↓
自動マージ
テスト失敗
↓
マージされない
という運用が実現できます。
この構成のメリット
- PR作成時は高速
- 重いテストはMerge Queueだけ
- 変更したアプリだけテスト
- 共通ライブラリ変更時だけ全体テスト
- Branch Protectionの設定がシンプル
- アプリが増えてもスケールしやすい
まとめ
モノレポでは「ブランチでアプリを分ける」のではなく、「CIで影響範囲を判定する」方が運用しやすいケースが多いと感じました。
GitHub Merge Queueとdorny/paths-filterを組み合わせることで、
- 開発速度
- 品質
- CIコスト
のバランスを取りながら運用できます。
テスト時間が長いモノレポを運用している方は、ぜひ一度試してみてください。
▼実践編