UberのSubmitQueue、投機的マージキューでtrunkを常にグリーンに保つ
Uber SubmitQueue: a high-performance speculative merge queue
Uberが公開したSubmitQueueは、高パフォーマンスな投機的マージキューです。複数のPRを並行してテストし、マージの競合やテスト失敗を事前に検出することで、trunkブランチを常にグリーンな状態に保ちます。大規模な開発チームでのCI/CDパイプラインの効率化に貢献する、実践的なツールです。
SubmitQueueは、trunkをスケールでも一貫してグリーンに保つ、高性能な投機的マージキューです。
HNでの議論
60- esprehn
Airbnbにもこれと似た内部ツールがあって、Evergreenという名前で、Uberの論文をベースにしていて、かなり素晴らしかった。
もっと多くの企業がモノレポのインフラをオープンソースにしてくれればいいのに。うまく設計されたモノレポは大規模組織にとって大きな力の増幅器になるが、OSSの世界にはそのインフラが不足しているため、みんな苦しい状況から始めて、徐々に改善していくか、モノレポに対する悪い印象を持ってしまう。GoogleのPiperも、オープンソース化または販売していれば業界に大きな貢献をしていただろう。エージェントが非常に速くコードを投入する時代において、Piperはすでに想像を絶するコミット速度を誇っていたため、非常によくスケールしている。一方、他の人たちは追いつくためにソース管理を再構築しようとしている。
- sdfhbdf
リポジトリから読んでいるが、何が革新的なのか少し困惑している。
> SubmitQueueは、HEADの予測される将来の状態に対して、複数の変更を並行して投機的にリベースし、検証する。検証が成功すると、変更は自動的にマージされる。失敗した場合、SubmitQueueは問題のある変更を分離し、残りを再試行する。これらはすべて人間の介入なしに行われる。
これはGitHubの機能（古いエンタープライズサーバーインストールにある）と同じことをしているように思える：
> プルリクエストがマージキューに追加されると、その変更はベースブランチの最新版と、キュー内の先行するプルリクエストの変更とともに、merge_groupにグループ化される。GitHubは、ベースブランチのブランチ保護で必要なチェックが成功すると、これらすべての変更をベースブランチにマージする。
https://docs.github.com/en/repositories/configuring-branches...
GitHubを使っていない人もいるのは理解しているが、他のプロバイダーにも同様の機能があるはずだ。例：https://docs.gitlab.com/ci/pipelines/merge_trains/#enforce-m...
では、Uberのものは何が違うのか、特別なのか？
- kccqzy
大規模にtrunkを常にグリーンに保つのは、おそらくコストがかかりすぎる。Googleでさえ、google3モノレポを常にビルド可能に保つことはできず、ましてやグリーンに保つことはできない。trunkをほぼグリーンに保ち、最後の0.1%を追い求めるのをやめ、代わりに原因を迅速に特定して自動的にロールバックするツールを開発する方が価値がある。
- jedberg
調整問題の解決策は、優れたモノレポツール（OPのような）と、コードベース全体を理解し、エンジニアが自分の部分がどのように適合するかを理解するのを助けるAIの組み合わせだと思います。
私はマイクロサービスの最大の支持者の一人で、世界中を旅してマイクロサービスの福音を広め、大規模な技術カンファレンスで基調講演を行ってきました。マイクロサービスは大規模な開発チームをスケールするための最良の解決策であり、小さなチームが小さな問題に取り組み、APIが唯一の契約であると信じていました。
しかし、その時でさえ、オーバーヘッドのために小規模チームには価値がないと警告していました。つまり、大規模組織の調整問題に対する解決策であると。そして、Googleは彼らがモノレポツールに多大なリソースを費やしてきたため、反例ではないと。
しかし、計算を変える新しい要素があります：
AIは、マイクロサービスのクラスターよりもモノレポをはるかに簡単に理解できます。AIはここでの計算を変えます。AIにより、開発者は最大のモノレポでもうまく作業でき、すべてのコードが一箇所にあると、AI自身もより良い結果を出します。
- wasmperson
別の方法：trunkを「グリーン」に保つことを気にしない。代わりに「stable」のような名前の2番目のブランチを作り、trunkがグリーンになるたびに最新のtrunkに自動的に早送りする。stableをチェックアウトし、新しい変更をtrunkにプッシュし、CIを壊さないようにするが、CIを壊しても気にせず、修正をプッシュするだけ。
trunkを常にデプロイ可能でなければならない「神聖な」ものとして扱うと、結局は長命なブランチやPRがたくさんでき、それに伴うマージ競合やオーバーヘッドが発生する。