Ein Team, mit dem wir arbeiten, wollte schneller releasen. Ein berechtigter Anspruch, und der übliche Reflex ist, etwas zu kaufen, das Entwicklern hilft, schneller Code zu schreiben.
Bevor wir etwas änderten, haben wir also kartiert, wo eine Änderung ihr Leben verbringt, vom ersten Commit bis zum Betrieb in der Produktion. Der größte Teil dieses Lebens war Warten. Warten auf einen Reviewer mit Zeit, weil alle, die erfahren genug zum Reviewen waren, mit eigener Arbeit beschäftigt waren. Warten auf Tests, die eher nach dem Review geschrieben wurden als davor. Warten auf das nächste Release-Fenster, weil das Releasen manuell genug war, um geplant werden zu müssen.
Das Schreiben war nie der langsame Teil. Die Warteschlange war es.
Was wir geändert haben
Sobald man es als Warteschlangenproblem sieht, schreibt sich die Einkaufsliste von selbst: Hilfe dorthin stellen, wo die Arbeit wartet, und die Tastatur in Ruhe lassen.
GitHub Copilot im Editor war bereits da, und ehrlich gesagt ist das der uninteressanteste Teil dieser Geschichte. Es macht das Schreiben schneller, und das Schreiben ging ohnehin schnell.
Claude reviewt jeden Pull Request zuerst. Das ist die Änderung, die alles Übrige finanziert hat. Sobald ein Pull Request geöffnet wird, liest Claude Fable den Diff und hinterlässt Kommentare: das nicht behandelte Null, die verschluckte Exception, die Funktion, die kopiert und halb bearbeitet wurde. Es genehmigt nichts. Wenn ein menschlicher Reviewer den Pull Request öffnet, ist diese Schicht bereits erledigt, sodass er dort beginnen kann, wo sein Urteil zählt: beim Entwurf. Reviewen wurde von einer aufgeschobenen Pflicht zu einer kurzen Aufgabe zwischendurch, und die Warteschlange davor schrumpfte entsprechend.
Playwright-Tests, aus dem Diff entworfen. Die Testsuite war genau dort am dünnsten, wo sich das Produkt am meisten veränderte, wie üblich. Jetzt gehen der Diff und die Spec-Konventionen des Teams an ein Modell, sobald ein Pull Request geöffnet wird, und es entwirft Playwright-Tests für die geänderten Pfade. Etliche werden vor dem Merge überarbeitet, manche weggeworfen. Das ist in Ordnung. Das Entwerfen war der Teil, den niemand machen wollte, und er kostet jetzt nichts, also wächst die Abdeckung dort, wo sich das Produkt bewegt. Regressionen werden in der CI gefangen statt in einem Support-Ticket.
Dependabot und CodeQL, an einem Nachmittag eingeschaltet. Natives GitHub, kein neuer Anbieter, kein Glanz. Eine schnellere Pipeline liefert auch Fehler schneller aus, und diese beiden fangen eine ganze Kategorie davon ab, ohne dass jemand an einem Freitag scharfsichtig sein muss.
GitHub Actions führt das Release aus. Builds liefen früher in Azure DevOps, und das Team konsolidierte ohnehin auf GitHub. Mit Review, Tests, Scanning und Deployment an einem Ort gibt es einen einzigen Audit-Trail. Dieser Trail zählt mehr, sobald ein Modell mitwirkt, denn man will genau beantworten können, was gelaufen ist und welche Person freigegeben hat.
Den Merge menschlich halten
Ein Modell kann hier Code schreiben, Code reviewen und Tests entwerfen. Es kann keinen Pull Request genehmigen und nicht deployen. Das ist als Repository-Berechtigung erzwungen, hängt also nicht von der Disziplin einzelner in einer vollen Woche ab.
Alles vor dem Merge ist ein Entwurf, und Entwürfe darf man billig falsch machen. Alles nach dem Merge ist Produktion. Die Grenze dort zu halten bedeutet, dass die Geschwindigkeit dort landet, wo Fehler behebbar sind, und dass sich jedes Release weiterhin auf eine namentlich benannte Person zurückführen lässt, die Ja gesagt hat. Wenn Security oder eine Prüferin fragt, wer freigegeben hat, gibt es einen Namen.
Das Ergebnis
Releases haben aufgehört, Ereignisse zu sein. Aus einem geplanten Anlass wurde etwas, das mehrmals pro Woche passiert, wenn eine Änderung fertig ist statt wenn der Kalender es sagt.
Die Qualität bewegte sich in dieselbe Richtung, was jene überraschte, die einen Zielkonflikt erwartet hatten. Mehr Regressionen sterben in der CI, weil die Tests nun existieren, und Rollbacks sind selten geworden.
Und die Änderung, die niemand vorhergesagt hat: Reviewen war nicht länger die Aufgabe, die alle sich für das Ende des Tages aufhoben. Kürzere, interessantere Arbeit wird früher aufgegriffen. Ein guter Teil des Tempogewinns liegt vermutlich genau darin.
Wie Sie anfangen
Messen Sie, wo eine Änderung wartet, bevor Sie etwas kaufen. Wenn die Review-Latenz Ihr Engpass ist, ändert schnelleres Tippen daran nichts. Beginnen Sie mit KI-Review, weil es billig auszuprobieren, leicht abzuschalten ist und ein Mensch die Ausgabe ohnehin liest. Lassen Sie ein Modell Ihre Tests entwerfen und behandeln Sie die Entwürfe als Entwürfe. Und machen Sie den Merge vom ersten Tag an zu einer menschlichen Berechtigung, denn diese Grenze ist es, die Ihnen erlaubt, zu allem anderen Ja zu sagen.
Es gibt keinen Einheitsansatz für die Cloud. Deshalb holen wir Sie dort ab, wo Sie stehen.
