merge queue とは何か？

merge queue は pull request を直列化し、merge の前に各 PR を最新の main branch に対してテストして、不意の破損を防ぎます。

忙しいリポジトリでは、2 つの pull request がそれぞれ単独で CI に合格しても、両方が着地すると壊れることがあります。どちらも互いに対してテストされていないからです。merge queue は、実際に merge される順序で変更をテストすることで、そのギャップを埋めます。

解決する問題

CI は通常、pull request を、PR が開かれた時点の main branch に対してテストします。main が進むか、別の PR が先に merge されると、テストされた組み合わせは実際に着地するものではなくなります。個別に緑の 2 つの変更が結合して赤い main になり、全員の build を壊すことがあります。

merge queue の仕組み

承認された PR は即座に merge せずキューに入る。
キューは各 PR を main の現在の先端とその前にあるものに対してテストする。
組み合わせが合格すれば、PR は自動的に merge される。
失敗すれば、その PR は取り除かれキューは継続する。

例

承認された 3 つの pull request がキューに入ります。キューは PR A を main に対して、次に PR B を main+A に対して、次に PR C を main+A+B に対して build しテストします。それぞれが着地する正確なコンテキストで検証されるため、merge された結果は合格が保証され、main が壊れません。

なぜ壊れた build を防ぐか

古いスナップショットではなく実際の merge 順序をテストすることで、merge queue は main に着地するものが実際に一緒に検証されたことを保証します。これは多くの変更が 1 時間に merge されても main branch を緑に保ち、大規模な trunk-based development に不可欠です。

コスト

merge queue はより多くの CI を実行します。キュー内の各変更がコンテキストでテストされるため、より多くの runner 時間を消費します。速く並列でコスト効率の良い runner がそのオーバーヘッドを妥当に保つのに役立ちます。これが大規模なチームが runner の性能を気にする理由の一部です。

重要なポイント

merge queue は各変更を実際の merge 順序に対してテストする。
2 つの緑の PR が結合して壊れた main になるのを防ぐ。
main を健全に保ちながら高い merge スループットを可能にする。