マージキューとは？
マージキューはプルリクエストのマージをシリアライズし、それぞれを最新の main に対してテストするため、main ブランチが同時マージによって壊れることはありません。
マージキューは、混雑したリポジトリにおける微妙な問題を解決します。2 つのプルリクエストはそれぞれ単独では CI をパスしても、互いに対してテストされていないため、両方がマージされると main を壊すことがあります。マージキューは、変更を最新の main に対して 1 つずつテストしてからランドさせることで、そのギャップを埋めます。
解決する問題
多くの PR が並列で CI をパスするとき、それぞれは古い main に対してテストされています。それらを立て続けにマージすると、どの pipeline も実行したことのない組み合わせが生じ、ブランチを壊すことがあります。この競合は、チームとそのマージレートがスケールするにつれて悪化します。
マージキューの仕組み
直接マージする代わりに、承認された PR はキューに入ります。システムは各 PR を現在の main（およびその前に並んだ変更）の上に build し、CI を実行し、パスした場合のみマージします。失敗したエントリはブランチを壊せないよう排除されます。
なぜ重要か
マージキューは、main にランドするものが、マージ先の正確な状態に対して実際にテストされたことを保証します。その結果、重い同時マージの下でも main ブランチはグリーンを保ち、単一の PR が原因ではない突然の破壊による火消し作業がなくなります。
マージキューと CI/CD
マージキューは、並んだエントリを検証する際に多くの投機的な CI 実行をファンアウトできるため、runner に実際の負荷をかけます。遅い、あるいはキャパシティの限られた runner はキューをボトルネックに変えます。Latchkey のようなマネージドプラットフォームが提供する、十分で高速な runner キャパシティは、混雑したキューを流し続け、マージが停滞しないようにします。
いつ導入すべきか
- 同時マージが main を壊し始めたら有用です。
- 必須の status check とブランチ保護と組み合わせます。
- 並んだエントリを迅速に検証するのに十分な CI キャパシティが必要です。
- 高速に動くチームのために main をグリーンに保ちます。
Applying this to your pipeline
- Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
- Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
- Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
- Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.
重要なポイント
- マージキューはマージをシリアライズし、それぞれを最新の main に対してテストします。
- 独立した PR が引き起こしうる main 破壊の競合を防ぎます。
- キューを流し続けるには、十分で高速な CI キャパシティが必要です。