Ich habe lange geglaubt, eine Pipeline sei fertig, wenn sie einmal durchläuft. Das war ein Irrtum, der mich mehrere Wochenenden gekostet hat. Eine Pipeline, die einmal grün ist, beweist gar nichts. Sie beweist nur, dass in genau diesem Moment, mit genau diesem Cache und genau dieser Reihenfolge, zufällig alles gepasst hat.
Mein Anspruch ist heute ein anderer. Eine Pipeline gilt bei mir erst dann als fertig, wenn ich sie zehnmal hintereinander anstoßen kann und zehnmal dasselbe Ergebnis bekomme. Kein Flackern, keine Tests, die mal laufen und mal nicht, keine Schritte, die vom Zustand des vorherigen Laufs abhängen. Diese Disziplin klingt übertrieben, bis man das erste Mal um drei Uhr morgens einen Release nicht ausliefern kann, weil ein Job „manchmal" fehlschlägt.
Konkret bedeutet das für mich drei Dinge. Erstens: jeder Lauf startet aus einem sauberen, definierten Zustand. Ich verlasse mich nicht auf Caches, um korrekt zu sein, sondern nur, um schneller zu sein. Fällt der Cache weg, muss der Build trotzdem grün sein. Zweitens: Tests dürfen keine versteckte Reihenfolge voraussetzen. Ich mische die Reihenfolge bewusst durch, und wenn dann etwas bricht, habe ich einen echten Fehler gefunden, kein Timing-Glück. Drittens: ein instabiler Test wird nicht wiederholt, bis er grün ist. Er wird repariert oder er fliegt raus. Ein Retry, der einen kaputten Test versteckt, ist eine Lüge, die man später teuer bezahlt.
Diese Haltung hat meine Arbeit langsamer gemacht und gleichzeitig ruhiger. Ich baue weniger Pipelines pro Woche, aber die, die stehen, halten. Ich werde nicht mehr mitten in der Nacht von einem Job geweckt, der sich anders verhält als am Nachmittag.
Der eigentliche Wert einer Pipeline liegt nicht in ihrer Geschwindigkeit. Er liegt in ihrer Vorhersagbarkeit. Eine schnelle Pipeline, der ich nicht trauen kann, zwingt mich, jedes Ergebnis von Hand nachzuprüfen, und damit ist sie langsamer als gar keine. Wiederholbarkeit ist keine Kür. Sie ist die einzige Eigenschaft, die eine Automatisierung überhaupt zur Automatisierung macht.
– Sergey Shinder
Top comments (0)