Uber veröffentlicht SubmitQueue: Spekulative Merge-Queue für stets grünen Trunk
Uber SubmitQueue: a high-performance speculative merge queue
Uber hat SubmitQueue als Open Source veröffentlicht, eine hochperformante, spekulative Merge-Queue, die den Hauptentwicklungszweig (Trunk) auch bei großem Maßstab kontinuierlich grün hält. Das Tool führt Merges parallel und spekulativ aus, um Wartezeiten zu reduzieren und die CI-Effizienz zu steigern. Es ist auf GitHub verfügbar und richtet sich an Teams, die viele Pull Requests verwalten und eine zuverlässige Integration sicherstellen möchten.
SubmitQueue ist eine hochperformante, spekulative Merge-Queue, die Ihren Trunk bei großem Maßstab konstant grün hält.
- esprehn
Airbnb hat intern eine Version davon, die ziemlich genial war und Evergreen hieß, basierend auf dem Uber-Paper. Ich wünschte, mehr Unternehmen würden ihre Monorepo-Infrastruktur als Open Source veröffentlichen. Ein gut gemachtes Monorepo ist ein enormer Multiplikator für große Organisationen, aber der Open-Source-Welt fehlt ein Großteil der Infrastruktur, sodass jeder von einem schmerzhaften Punkt aus startet und sich hocharbeitet oder einen schlechten Eindruck von Monorepos hat. Googles Piper ist ein weiteres Beispiel, wo Open-Sourcing oder Verkauf Wunder für die Branche bewirkt hätte. In einem Zeitalter, in dem Agents sehr schnell Code landen, hat Piper sehr gut skaliert, da es bereits eine unvorstellbare Commit-Geschwindigkeit hatte, während alle anderen versuchen, die Versionskontrolle neu aufzubauen, um Schritt zu halten.
- sdfhbdf
Ich lese das Repo und bin etwas verwirrt, was die Innovation sein soll.
> SubmitQueue rebased und validiert spekulativ mehrere Änderungen parallel gegen vorhergesagte zukünftige Zustände von HEAD. Wenn die Validierungen bestehen, werden die Änderungen automatisch übernommen. Wenn sie fehlschlagen, isoliert SubmitQueue die problematische Änderung und versucht den Rest erneut – ganz ohne menschliches Eingreifen.
Das scheint eine Funktion von GitHub zu sein (wir haben sie in einer alten Enterprise-Server-Installation), die dasselbe tut:
> Wenn ein Pull Request zur Merge-Queue hinzugefügt wird, werden die Änderungen im Pull Request in einer merge_group mit der neuesten Version des base_branch sowie Änderungen von Pull Requests, die vor ihm in der Warteschlange stehen, gruppiert. GitHub wird alle diese Änderungen in den base_branch mergen, sobald die Checks, die von den Branch-Protections des base_branch benötigt werden, bestehen.
https://docs.github.com/en/repositories/configuring-branches...
Ich verstehe, dass nicht jeder GitHub nutzt, aber ich bin mir ziemlich sicher, dass andere Anbieter ähnliche Funktionen haben, z. B. https://docs.gitlab.com/ci/pipelines/merge_trains/#enforce-m...
Was ist also anders/besonders an Ubers Sache?
- kccqzy
Den Trunk durchgehend grün zu halten, ist im großen Maßstab wahrscheinlich zu kostspielig. Nicht einmal Google kann sein google3-Monorepo durchgehend baubar halten, geschweige denn grün. Es ist sinnvoller, den Trunk meistens grün zu halten, nicht den letzten 0,1 % hinterherzujagen, und stattdessen Werkzeuge zu entwickeln, um schnell die Übeltäter zu identifizieren, die automatisch zurückgerollt werden können.
- jedberg
Ich glaube, die Lösung für das Koordinationsproblem ist gutes Monorepo-Tooling (wie im OP) plus KI, um die gesamte Codebasis zu verstehen und den Entwicklern zu helfen, zu verstehen, wie ihr Teil hineinpasst.
Ich war einer der größten Befürworter von Microservices und bin sogar um die Welt gereist, um das Evangelium der Microservices zu verbreiten und auf großen Tech-Konferenzen Keynotes zu halten. Ich glaubte, dass Microservices die beste Lösung zur Skalierung großer Entwicklerteams seien, sodass kleine Teams an kleinen Problemen arbeiten könnten, wobei die API der einzige Vertrag zwischen ihnen sei.
Aber selbst damals warnte ich, dass der Overhead es für kleine Teams nicht lohnenswert mache – dass es eine Lösung für das Koordinationsproblem großer Organisationen sei. Und dass Google kein Gegenbeispiel sei, weil sie so viele Ressourcen in ihr Monorepo-Tooling gesteckt hätten.
Aber es gibt einen neuen Faktor, der die Rechnung ändert:
KIs können Monorepos viel einfacher erfassen als einen Cluster von Microservices. KIs ändern hier die Rechnung. Sie ermöglichen es dem Entwickler, auch in den größten Monorepos erfolgreich zu arbeiten, und die KIs selbst liefern bessere Ergebnisse, wenn der gesamte Code an einem Ort ist.
- wasmperson
Alternativ: Mach dir keine Sorgen darum, den Trunk „grün“ zu halten. Habe einen zweiten Branch namens „stable“ oder so, der automatisch auf den neuesten Trunk vorspult, wann immer der Trunk grün ist. Checkout stable, pushe neue Änderungen auf trunk, vermeide es, CI zu brechen, aber wenn du CI brichst, mach dir keine Sorgen, pushe einfach einen Fix.
Wenn du tust, als wäre der Trunk dieses „heilige“ Ding, das immer bereit zum Deployen sein muss, dann bekommst du am Ende eine Menge langlebiger Branches und PRs und all die Merge-Konflikte und den Overhead, die damit einhergehen.