CI/CDパイプラインのゲートと並行制御
CI/CDパイプラインのゲートと並行制御とは
[[CI/CD]] の基本は「pushしたらテストとビルドが自動で走る」ですが、実運用では複数のジョブ・複数のPRが同時に動くことで起きる問題への対処が必要になります。この記事では、パイプラインが複雑化したときに直面する運用上の制御について扱います。
並行実行のキャンセル(concurrency group)
同じブランチへ短時間に連続でpushすると、CIは「最新のpushだけテストできればいい」という考え方で、同じグループの古い実行を自動キャンセルすることがあります。無駄な計算を省く合理的な仕組みですが、落とし穴もあります。
- キャンセルされた実行の中に必須の後処理(デプロイ後の同期ジョブなど)が含まれていると、その処理ごと消えてしまう
- 連続でマージするワークフローでは、「最後の実行が最後まで完了したか」を個別に確認する必要がある
必須チェック(Required Status Checks)とブランチ保護
[[Git]] のホスティングサービスには、「指定したチェックが全部成功しないとマージボタンを押せない」設定があります。
| 仕組み | 内容 |
|---|---|
| 必須チェック | テスト・ビルドなど指定したジョブの成功をマージの条件にする |
| ブランチ保護 | 直接push禁止・[[コードレビュー]]必須・未解決コメントの解消必須などをブランチ単位で強制する |
| 管理者オーバーライド | 緊急時に必須チェック未達でも権限者だけはマージできる抜け道。乱用しないよう記録を残す運用が望ましい |
初学者向けポイント
- 「CIは全部緑なのにマージできない」は、未解決のレビューコメントなどチェック以外のブランチ保護ルールが原因のことがある
- 必須チェックが厳しすぎると開発が止まり、緩すぎると壊れたコードがmainに入る。プロジェクトの成熟度に応じて調整する対象
- パイプラインの一部を「最新のみ実行できればよい」ものと「1回1回を必ず完走させたい」ものに分けて考えると、concurrency設定の設計判断がしやすい
関連技術とのつながり
- [[CI/CD]] — この記事はCI/CDパイプラインが複雑化したときの運用上の落とし穴を扱う
- [[自動テスト]] — 必須チェックの中身そのもの
- [[Git]] — ブランチ保護・レビュー解決の対象となるバージョン管理システム
- [[ブランチ戦略]] — 保護ルールを設計する前提となるブランチの使い方
Q: concurrency groupによる並行実行キャンセルの落とし穴として本文で挙げたのはどれ?
- [ ] テストが必ず失敗するようになる
- [x] キャンセルされた実行に必須の後処理が含まれていると、それごと消えてしまう
- [ ] マージが自動的に禁止される
解説: 古い実行がキャンセルされると、その中にあったデプロイ後の同期処理なども実行されずに終わってしまうことがあります。
Q: 「CIは全部緑なのにマージできない」の原因として本文が挙げたのはどれ?
- [x] 未解決のレビューコメントなど、チェック以外のブランチ保護ルール
- [ ] concurrency groupの設定ミス
- [ ] テストの実行時間が長すぎること
解説: レビュー会話の解決必須など、ステータスチェック以外のブランチ保護ルールがマージをブロックすることがあります。
Q: 必須チェック(Required Status Checks)の役割はどれ?
- [x] 指定したジョブの成功をマージの条件にする
- [ ] デプロイ先のクラウド環境を自動選択する
- [ ] コミットメッセージの書式を自動修正する
解説: 必須チェックは、テストやビルドなど指定したジョブが成功しないとマージできないようにする仕組みです。