Testmanager gesucht? Kontaktiere mich!

Die Evolution der Merge Queues in der Softwareentwicklung Die Softwareentwicklung…

Blog Image

Die Evolution der Merge Queues in der Softwareentwicklung

Die Softwareentwicklung hat sich in den letzten Jahren stark weiterentwickelt. Von Bors und Homu über Bulldozer, Kodiak und Mergify bis hin zu GitHub und GitLab haben Merge Queues maßgeblich dazu beigetragen, wie wir Hauptzweige effektiv verwalten. Dieser Artikel beleuchtet die Geschichte, warum sie entstanden sind und wie sie zu einem Standard in der modernen Softwareentwicklung wurden.

Als die Idee der Merge Queue vor über zwei Jahrzehnten entstand, stand die Frage im Raum, wie man den Hauptzweig grün halten kann, wenn Dutzende von Entwicklern gleichzeitig Code zusammenführen. Die kontinuierliche Integration machte deutlich, dass "einfach zusammenführen und hoffen" nicht ausreicht. Die Lösung war kein neues Testframework, sondern ein neuer Workflow. Von frühen Skripten im Rust-Projekt (Bors, Homu) über Shopify's Shipit bis hin zu modernen SaaS-Angeboten wie Mergify und integrierten Warteschlangen von GitHub und GitLab haben sich Merge Queues aus der Notwendigkeit heraus entwickelt.

Der Erfolg von Bors im Rust-Projekt zeigte den Wert des Konzepts. Durch das Testen vor dem Zusammenführen auf den Hauptzweig konnte der Hauptzweig von Rust stabil gehalten werden, ohne menschliches Eingreifen zum Aktualisieren oder Zurücksetzen von Commits. Die Erfahrung von Rust bewies den Wert des Konzepts, das Hoare als "keine Raketenwissenschaft" bezeichnete – es ist nur mühsam, es manuell zu erledigen, daher reif für die Automatisierung.

Die Idee von Merge Queues breitete sich aus und wurde von anderen Entwicklern und Unternehmen aufgegriffen. Bulldozer, entwickelt von Palantir, automatisierte das Zusammenführen und Aktualisieren von Pull Requests. Mergify, von Julien Danjou und Mehdi Abaakouk entwickelt, wurde zu einem beliebten SaaS-Produkt und Unternehmen, das Merge Queues in jede GitHub-Repository brachte. Kodiak, von Christopher Blump erstellt, automatisierte das Aktualisieren und Zusammenführen von PRs und fand schnell Anklang in der Open-Source-Community.

Die Einführung von GitHub's eigenem Merge Queue war ein Wendepunkt. Es validierte den Ansatz, den Community-Tools pioniert hatten, und brachte ihn an ein viel breiteres Publikum. Organisationen auf GitHub Enterprise Cloud oder öffentlichen Open-Source-Projekten können jetzt einfach eine Merge Queue in den Einstellungen aktivieren, ohne einen externen Bot zu benötigen.

Quelle: https://mergify.com/blog/the-origin-story-of-merge-queues

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen