Merge Trains in GitLab: wann sie sich lohnen

1. Das Problem gleichzeitiger Merges auf einen Branch

Selbst wenn zwei Merge Requests jeweils einzeln eine erfolgreiche Merge-Request-Pipeline durchlaufen haben, ist damit nicht garantiert, dass beide zusammen funktionieren, sobald sie nacheinander in denselben Ziel-Branch gemerged werden. Merge Request A testet gegen den aktuellen Stand von main, Merge Request B testet ebenfalls gegen den aktuellen Stand von main, aber keiner der beiden Tests beruecksichtigt, wie main aussieht, nachdem beide gemerged wurden. Wenn beide Aenderungen an derselben Stelle im Code ansetzen oder sich gegenseitig in ihrer Logik beeinflussen, kann main nach beiden Merges kaputt sein, obwohl jeder einzelne Merge Request fuer sich genommen eine gruene Pipeline hatte.

Dieses Problem, oft als Semantic Merge Conflict bezeichnet, tritt umso haeufiger auf, je mehr Merge Requests gleichzeitig gegen denselben Branch antreten und je hoeher die Merge-Frequenz ist. In Teams, die mehrmals taeglich mehrere Merge Requests gegen main mergen, insbesondere bei geschuetzten Branches mit strikten Anforderungen an eine gruene Pipeline vor jedem Merge, wird dieses Problem schnell zu einem echten operativen Aergernis, weil der Ziel-Branch trotz aller Einzelchecks regelmaessig in einen kaputten Zustand geraet und ein nachtraeglicher Fix-Commit noetig wird.

2. Wie ein Merge Train tatsaechlich funktioniert

Ein Merge Train ist eine geordnete Warteschlange von Merge Requests, die alle fuer denselben geschuetzten Branch vorgesehen sind. Sobald ein Merge Request in den Merge Train aufgenommen wird, erstellt GitLab einen simulierten Zustand, der nicht nur den Feature-Branch mit dem aktuellen Ziel-Branch zusammenfuehrt, sondern zusaetzlich alle bereits vor ihm im Zug eingereihten, noch nicht gemergten Merge Requests beruecksichtigt. Der zweite Merge Request im Zug wird also nicht gegen den heutigen main getestet, sondern gegen einen main-Zustand, der so aussieht, als waere bereits der erste Merge Request im Zug erfolgreich gemerged worden.

Erst wenn die Pipeline fuer diesen kombinierten, simulierten Zustand erfolgreich durchlaeuft, wird der Merge Request tatsaechlich in den echten Ziel-Branch gemerged, und der naechste Merge Request im Zug ruueckt entsprechend nach. Faellt die Pipeline fuer einen Merge Request im Zug fehl, wird genau dieser Merge Request aus dem Zug entfernt, und alle nachfolgenden Merge Requests im Zug werden automatisch neu getestet, jetzt ohne den fehlgeschlagenen Merge Request in ihrer simulierten Basis, damit ein fehlerhafter Merge Request nicht die gesamte Warteschlange blockiert oder gar zu einem kaputten Ziel-Branch fuehrt.

workflow:
  rules:
    - if: '$CI_MERGE_REQUEST_EVENT_TYPE == "merge_train"'
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

test_in_train:
  stage: test
  script:
    - vendor/bin/phpunit
  rules:
    - if: '$CI_MERGE_REQUEST_EVENT_TYPE == "merge_train"'

3. Aktivierung und Voraussetzungen

Merge Trains sind ein Feature der GitLab Premium- und Ultimate-Stufe und stehen in der kostenlosen Free-Stufe nicht zur Verfuegung, was bei der Bewertung des Aufwand-Nutzen-Verhaeltnisses eine wichtige Randbedingung ist. Aktiviert wird die Funktion in den Projekteinstellungen unter Merge requests durch die Option Enable merged results pipelines gefolgt von Enable merge trains, wobei Merged-Results-Pipelines eine technische Voraussetzung fuer Merge Trains sind, weil beide auf demselben Mechanismus zur Berechnung eines simulierten Merge-Zustands basieren.

Zusaetzlich muss der Ziel-Branch als geschuetzter Branch konfiguriert sein und die Pipeline-Erfolgs-Anforderung fuer Merges aktiviert haben, weil ein Merge Train ohne diese Voraussetzung keinen Sinn ergibt: Der gesamte Mechanismus existiert ja gerade, um automatisiert sicherzustellen, dass nur gruen getestete Aenderungen in den geschuetzten Branch gelangen. Fuer Runner-Kapazitaet bedeutet die Aktivierung zudem, dass bei hoher Merge-Frequenz mehrere vollstaendige Pipeline-Laeufe gleichzeitig oder kurz hintereinander laufen koennen, was ausreichend Runner-Kapazitaet voraussetzt, damit sich Merge-Request-Autoren nicht durch lange Warteschlangen auf freie Runner zusaetzlich ausgebremst fuehlen.

4. Semi-lineare Historie als Nebeneffekt

Ein oft unterschaetzter Vorteil von Merge Trains ist ihr Effekt auf die Git-Historie des Ziel-Branches: Weil jeder Merge Request im Zug nacheinander und nicht parallel gemergt wird, entsteht auf dem Ziel-Branch eine semi-lineare Historie, in der jeder Merge-Commit tatsaechlich auf dem direkt vorherigen Commit aufbaut, statt mehrere gleichzeitig entstandene, parallele Merge-Commits zu verschachteln. Diese Eigenschaft erleichtert spaeteres Bisecting bei der Fehlersuche erheblich, weil git bisect auf einer semi-linearen Historie deutlich zuverlaessiger funktioniert als auf einer Historie mit vielen ueberlappenden Merge-Commits, deren gegenseitige Reihenfolge nicht eindeutig ist.

Diese semi-lineare Historie ist auch fuer Audits und Compliance-Anforderungen wertvoll, weil sich fuer jeden Commit auf dem geschuetzten Branch eindeutig nachvollziehen laesst, in welchem Zustand sich der Branch zum Zeitpunkt dieses Merges befand und welche Pipeline genau diesen Zustand getestet hat. In Branchen mit strengen Nachvollziehbarkeitsanforderungen, etwa im Finanz- oder Gesundheitssektor, ist dieser Nebeneffekt manchmal sogar der eigentliche Hauptgrund fuer die Einfuehrung von Merge Trains, wichtiger noch als die reine Vermeidung von Semantic Merge Conflicts.

5. Der tatsaechliche Kostenaufwand von Merge Trains

Der offensichtlichste Kostenfaktor ist, dass ein Merge Train fuer jeden Merge Request im Zug eine vollstaendige Pipeline gegen den kombinierten simulierten Zustand ausfuehrt, und diese Pipelines muessen bei einer Aenderung am Zug, etwa wenn ein frueherer Merge Request fehlschlaegt, teilweise neu ausgefuehrt werden. Bei einem Zug mit fuenf wartenden Merge Requests und einer typischen Pipeline-Laufzeit von zehn Minuten kann sich die effektive Wartezeit fuer den letzten Merge Request im Zug deutlich verlaengern, verglichen mit einem einzelnen, isolierten Merge-Request-Pipeline-Lauf ohne Warteschlange.

Dieser Effekt verstaerkt sich, wenn Pipelines in der Praxis regelmaessig fehlschlagen, weil jeder Fehlschlag im Zug eine Neuberechnung fuer alle nachfolgenden Merge Requests ausloest. Teams mit einer instabilen Test-Suite, die haeufig flaky Tests enthaelt, also Tests, die ohne inhaltliche Aenderung mal erfolgreich und mal fehlschlagend sind, erleben mit Merge Trains oft eine deutlich schlechtere Erfahrung als ohne, weil sich die Instabilitaet der Tests durch die Kettenreaktion im Zug potenziert statt isoliert zu bleiben. Merge Trains lohnen sich deshalb erst, wenn die zugrunde liegende Pipeline bereits verlaesslich und schnell ist.

6. Wann sich Merge Trains tatsaechlich lohnen

Merge Trains entfalten ihren groessten Nutzen in Teams mit mehreren aktiven Contributor, einer hohen taeglichen Merge-Frequenz auf einen einzigen geschuetzten Branch und einer bereits stabilen, vergleichsweise schnellen Pipeline von wenigen Minuten bis maximal zehn bis fünfzehn Minuten Laufzeit. In dieser Konstellation ist das Risiko von Semantic Merge Conflicts real und die Kosten fuer den zusaetzlichen sequenziellen Testlauf pro Merge Request sind ueberschaubar, weil die Warteschlange durch die kurze Pipeline-Laufzeit nicht ausufert.

Ein zusaetzliches, oft entscheidendes Kriterium ist die tatsaechliche Historie von kaputten main-Branches: Teams, die bereits mehrfach erlebt haben, dass main trotz aller einzeln gruenen Merge-Request-Pipelines kaputt ging, weil sich zwei parallel gemergte Aenderungen gegenseitig gestoert haben, haben den klarsten Beleg fuer den Nutzen von Merge Trains. Wer dieses Problem noch nie erlebt hat, weil die Merge-Frequenz ohnehin niedrig ist oder Merges meist zeitlich weit auseinanderliegen, sollte den zusaetzlichen Konfigurations- und Wartezeit-Aufwand kritisch hinterfragen, bevor Merge Trains eingefuehrt werden.

7. Wann sich Merge Trains nicht lohnen

Bei kleinen Teams mit wenigen Contributor, niedriger Merge-Frequenz oder Pipelines, die laenger als fuenfzehn bis zwanzig Minuten laufen, ist der Aufwand fuer Merge Trains meist nicht gerechtfertigt. Lange Pipeline-Laufzeiten kombiniert mit einer Warteschlange fuehren dazu, dass Entwickler am Ende eines Zuges mehrere Stunden auf ihren tatsaechlichen Merge warten muessen, was die Motivation, ueberhaupt kleine, haeufige Merge Requests einzureichen, untergraebt und paradoxerweise zu groesseren, seltener eingereichten Merge Requests fuehrt, die das urspruengliche Problem eher verschaerfen als loesen.

Auch fuer Projekte ohne echte Premium- oder Ultimate-Lizenz entfaellt die Option ohnehin, und eine Umstellung der GitLab-Lizenzstufe ausschliesslich wegen Merge Trains ist selten wirtschaftlich sinnvoll, wenn nicht ohnehin schon andere Premium-Features wie erweiterte Code-Owner-Regeln oder Epics genutzt werden sollen. In solchen Faellen sind einfachere Alternativen oft ausreichend, etwa eine Teamvereinbarung, Merge Requests zeitlich zu staffeln, oder eine strengere Pflicht, den Feature-Branch unmittelbar vor dem Merge noch einmal gegen den aktuellen Ziel-Branch zu rebasen und die Pipeline erneut laufen zu lassen.

8. Alternativen und Zwischenstufen

Fuer Teams, die den vollen Merge-Train-Mechanismus scheuen, aber trotzdem etwas gegen Semantic Merge Conflicts tun wollen, bietet sich eine einfachere Zwischenstufe an: Merged-Results-Pipelines ohne die eigentliche Zug-Warteschlange testen bereits jeden einzelnen Merge Request gegen einen simulierten Merge-Zustand, ohne die zusaetzliche Sequenzierung mehrerer gleichzeitiger Merge Requests. Dieser Zwischenschritt reduziert das Risiko von Merge-Konflikten, die durch den Ziel-Branch selbst entstehen, deckt aber weiterhin keine Konflikte zwischen zwei gleichzeitig laufenden Merge Requests ab.

Eine weitere pragmatische Alternative ist eine organisatorische Regel, bei der Merge Requests fuer besonders sensible Codebereiche, etwa Datenbank-Migrationen oder zentrale Konfigurationsdateien, manuell nacheinander gemergt werden, waehrend fuer den Rest des Codes das normale, parallele Merge-Request-Pipeline-Verfahren ohne Merge Train ausreicht. Diese selektive Anwendung reduziert den Wartezeit-Overhead auf genau die Bereiche, in denen Semantic Merge Conflicts tatsaechlich am wahrscheinlichsten und am teuersten sind, statt pauschal jeden Merge Request durch die Zug-Warteschlange zu schicken.

9. Fazit: Merge Trains als gezieltes Werkzeug, nicht als Standardeinstellung

Merge Trains loesen ein reales Problem, naemlich Semantic Merge Conflicts zwischen gleichzeitig gemergten Aenderungen auf stark frequentierten geschuetzten Branches, und liefern als Nebeneffekt eine besser nachvollziehbare, semi-lineare Git-Historie. Der Nutzen haengt aber direkt von zwei Faktoren ab: einer bereits stabilen und schnellen Pipeline sowie einer tatsaechlich hohen Merge-Frequenz mit mehreren aktiven Contributor. Fehlen diese Voraussetzungen, erzeugt der Mechanismus vor allem zusaetzliche Wartezeit und Komplexitaet ohne entsprechenden Gegenwert.

Die folgende Tabelle fasst die wichtigsten Entscheidungskriterien fuer oder gegen Merge Trains als praktische Checkliste zusammen.

10. Zusammenfassung

11. FAQ: Merge Trains: Das Wichtigste auf einen Blick