93 % des Codes wurden nie geprüft. Wir haben die Tür geschlossen.

Bevor wir irgendetwas entschieden haben, haben wir gezählt. Diese Gewohnheit erspart viele Debatten: Bauchgefühle darüber, „wie wir arbeiten“, stimmen selten, und sie lassen sich mit einer Abfrage überprüfen.

In neunzig Tagen, über alle unsere aktiven Repositorys hinweg:

• 63 Commits kamen über einen Merge Request auf den Hauptzweig,
• 855 Commits kamen über einen direkten Push dorthin,
• also 721 direkte Pushes, von denen 41 die CI-Pipeline zum Scheitern brachten.

93 % dessen, was den Hauptzweig erreichte, war nie durch ein Review gegangen. Und dieser Zweig löst die Produktivsetzung aus: Was dort ankommt, geht online.

Was schon schützte und was das nicht abdeckte #

Ganz wirkungslos war der vorhandene Schutzmechanismus nicht. Die Deployment-Stufe hängt von den Stufen Build und Tests ab: Ein kaputter Commit wird nicht ausgeliefert. Von den 41 Pushes, die die Pipeline rot gefärbt haben, ist keiner in die Produktion gegangen.

Aber der Hauptzweig blieb rot, das heißt, die gemeinsame Referenz des Teams war kaputt, manchmal mehrere Stunden lang, bis es jemand bemerkte. Und vor allem schützt dieser Aufbau nur vor Code, der scheitert. Er schützt nicht vor Code, der durchläuft und den man gar nicht pushen wollte.

Die Entscheidung: schließen, ohne Zeremonie hinzuzufügen #

Wir haben den direkten Push auf den Hauptzweig aller aktiven Repositorys verboten, mit der Vorgabe, dass die Tests vor dem Merge grün sein müssen, und die Regel gilt auch für Administratoren.

Dagegen ist keine Freigabe erforderlich. Das verdient eine Erklärung, denn es ist der Reflex, den alle haben, und in kleinen Teams fast immer ein Fehler.

Die meisten Git-Plattformen verbieten es, den eigenen Merge Request freizugeben. Wer in einem Team, in dem eine Person allein an einem Projekt arbeitet, eine Freigabe verlangt, schafft eine Sackgasse: Nichts lässt sich mehr mergen. Der Schutz soll hier sicherstellen, dass die Tests bestanden sind, und kein Peer-Review vortäuschen, das es nicht gibt.

Im Alltag sieht das so aus: Man arbeitet auf einem Zweig, öffnet einen Merge Request, die Tests laufen, man klickt. Kein Warten, keine Abhängigkeit von Dritten. Unmöglich wird nur eines: direkt in das zu schreiben, was in die Produktion geht.

Vier Fallstricke, und wir sind auf alle gestoßen #

Diese Einrichtung gilt als trivial. Sie ist es nicht, und die folgenden vier Fallstricke ähneln sich alle: Sie erzeugen eine Konfiguration, die gut aussieht und nicht tut, was man glaubt.

1. Der Name der Prüfung enthält das Ereignis #

Die Prüfung heißt nicht „tests“, sondern „tests (pull_request)“. Wer den Namen ohne Suffix verlangt, verweist ins Leere: Der Merge Request bleibt für immer blockiert, ohne hilfreiche Meldung. Wir haben die genauen Namen in der Datenbank der Git-Plattform nachgesehen, statt sie zu raten.

2. Eine übersprungene Stufe ist keine erfolgreiche Stufe #

Die Deployment-Stufe wird bei einem Merge Request absichtlich übersprungen. Sie meldet also den Status „übersprungen“, nicht „erfolgreich“. Wer sie in der Liste der Prüfungen verlangt, blockiert alle Merges, endgültig.

3. Repositorys ohne CI-Pipeline #

Nicht jedes Repository hat eine CI-Pipeline: interne Werkzeuge, gemeinsame Bibliothek, Dokumentations-Repository. Dort eine grüne Prüfung zu verlangen, hieße, es einzufrieren. Diese Repositorys werden ohne Testvorgabe geschützt: Der direkte Push wird abgelehnt, der Merge erfolgt sofort. Der Schutz passt sich dem Repository an, sonst wendet er sich gegen das, was er schützen soll.

4. Ohne „auf Administratoren anwenden“ ist die Regel nur Dekoration #

Das ist der teuerste Fallstrick, weil er unsichtbar ist. Ohne dieses Häkchen gilt der Schutz nicht für Administratorkonten, also genau für die Konten, die am meisten pushen. Man glaubt, die Tür geschlossen zu haben; für die, die am häufigsten hindurchgehen, steht sie offen.

Was sich für Sie ändert #

Für einen Kunden ist diese Entscheidung kein Detail der internen Organisation. Sie hat drei direkte Auswirkungen:

• Nichts kann mehr in die Produktion gehen, ohne dass die Tests vorher bestanden sind. Früher liefen sie erst, als der Code schon unterwegs war: Sie stellten fest, sie schützten nicht.
• Jede Änderung hinterlässt eine Spur. Ein Merge Request trägt einen Titel, eine Beschreibung, ein Testergebnis und ein Datum. Genau das will ein Audit (oder eine Zertifizierung) sehen, und genau das liefert eine Historie direkter Pushes nicht.
• Ein Unfall durch einen versehentlichen Push ist unmöglich geworden. Das ist keine Frage individueller Wachsamkeit mehr, sondern eine Ablehnung durch den Server.

Und all das kostet das Team einen zusätzlichen Klick pro Änderung. Von allem, was wir in diesem Quartal eingeführt haben, hat diese Maßnahme das beste Verhältnis von Nutzen und Aufwand.