Ein Release am Freitag sollte kein Showstopper sein

translationKey: "friday-releases"

Das ist eine kleine Änderung, ich rolle sie einfach aus

Es war 2021, Donnerstagabend. Ich hatte gerade ein kleineres Feature fertiggestellt und das Gefühl, es gibt keinen Grund, es zurückzuhalten. Gemergt, Release gestartet, alles OK, ins Bett gegangen. Ein paar Minuten später schlug das unbeaufsichtigte Release fehl – und aufgrund meiner damaligen Naivität hatte ich keinerlei Monitoring. Das Projekt war für die nächsten 8 Stunden down (bis zum Morgen, als die Telefone zu klingeln begannen).

Das Release-Vertrauen

Das war mir vorher (und danach) noch nie passiert – aber dieser Fehler hallte jahrelang in meinem Kopf nach. Und er führte zu grundlegenden Verbesserungen, die ich im Release-Prozess umsetzen musste. Heute releasen wir ziemlich oft an Freitagen, aber bis dahin war es ein langer Weg.

Der Grund, warum wir keine Releases an Freitagen machen wollten, war weder mangelnde Kapazität noch Faulheit. Es war schlicht fehlendes Release-Vertrauen. Wir wollten das Ergebnis im Auge behalten und rechneten damit, dass etwas schiefläuft. Und es lief schief. Das ist ein klares Zeichen für eine schlechte Release-Strategie – vielleicht sogar für den gesamten Entwicklungsprozess.

Aber es gibt Wege, das zu lösen.

Der Zwiebel-Ansatz

Um unser Release-Vertrauen zurückzugewinnen, mussten wir viele unserer Prozesse auf den Kopf stellen. Und wir haben lange iteriert, bevor wir einen Zustand erreicht haben, in dem die Welt am Freitagnachmittag nicht mehr in Flammen steht.

Wir begannen mit der Definition von Rollen und der Release-Strategie. Ich nenne diesen Ansatz „Die Zwiebel". Es gibt Schichten, die wir bei jedem neuen Feature-Release abschälen können. So funktioniert jede Schicht:

Developer

Im Zentrum steht der Entwickler. Jemand, der Anforderungen (und Kaffee) in etwas verwandelt, das wir ein Produkt nennen könnten. Wenn wir davon ausgehen, dass alle Entwickler diszipliniert und gut ausgebildet sind und alle Best Practices in Software-Design und Architektur übernommen haben, gibt es dennoch ein sehr wichtiges Detail, das wir oft übersehen. Testen.

Ein Entwickler sollte viel testen. Immer und überall. Wie Sebastian Bergmann einmal sagte:

At 100% coverage the fun begins

Wir sollten nach der höchstmöglichen Abdeckung streben – nicht nur in Unit-Tests, sondern generell. Denn nur ein gut getestetes Produkt gibt einem Selbstvertrauen. Das kann dein Code sein, ein neues Design oder ein physischer Knopf. Aber mangelndes Testen kann deine Bemühungen zunichtemachen.

Also schreiben wir Tests. Viele davon.

Staging

Unsere Staging-Releases konzentrieren sich auf Code-Formatierung, Unit-Testing und das Bereitstellen des Features in einer gemeinsamen Umgebung, wo andere Teammitglieder mit dem neuen Spielzeug spielen können.

Product Owner / Project Manager

Es kann ein Project Owner, Project Manager, Product Manager oder eine beliebige andere Kombination sein, die du dir vorstellen kannst. Es muss jemanden geben, der überprüfen kann, was du gerade gemacht hast. Diese Person kennt wahrscheinlich die Aufgabe und sollte auch wissen, was erwartet wird. Genau diese Person sollte dir das erste Feedback geben.

Users

In dieser Phase ist das Feature bereits irgendwie verfügbar. Lass echte Nutzer aus deiner kontrollierten Gruppe (das kann die Vertriebsabteilung deines Unternehmens, der Kundensupport oder jemand anderes sein) es testen und Feedback geben. Und hör auf sie — sie sind den End-Nutzern viel näher als du (als Entwickler) es bist. Und oft haben sie recht, auch wenn es einem nicht gefällt. Wenn das Feedback nicht gut ist, geh zurück zur ersten Schicht und wiederhole den Prozess.

PR

Code Review ist der letzte menschliche Kontrollpunkt, bevor der Code in die Pipeline geht. Irgendwo auf Reddit gibt es ein Meme:

4 of 5 developers enjoy code review

Und das stimmt tatsächlich. Der PR ist eine weitere Schicht, die du abschälen kannst — wir haben leicht erweiterte PRs eingeführt, bei denen die Beschreibung Links (falls vorhanden) enthält, um die neue Funktionalität einfach testen zu können. Diese Gruppe von Menschen wird dir technische Einblicke geben und deine Architektur mit einem Lächeln im Gesicht zerlegen. Aber es ist meistens der beste Weg, etwas zu produzieren, das besser ist, als du es alleine hinbekommen hättest. Wir haben die Regel „mindestens zwei Reviewer" eingeführt. Erst dann kann das Feature raus.

Release Pipeline

Dein neues Baby ist endlich geboren — es hat geduldig in einem Git-Branch gewartet, und jetzt wird es ausgerollt. Wir verwenden Pipelines mit vielen Schritten (Testing, Docs-Generierung, E2E-Testing usw.), abhängig vom Projekt. Ein wichtiger Teil des Puzzles ist es, informiert zu werden, wenn etwas schiefläuft. Das kann eine Slack-Benachrichtigung, eine E-Mail oder eine Brieftaube sein. Und wenn die Pipeline fehlschlägt, bist du noch immer sicher, da das Produkt die Produktion noch nicht beeinflusst hat.

Aber was, wenn wir doch ein Problem in der Produktion finden? Klar, das passiert. Dann musst du eine robuste Rollback-Strategie haben — eine Möglichkeit, schnell und einfach zur vorherigen Version zurückzukehren. Schwer richtig umzusetzen (besonders bei Embedded- oder Desktop-Software), aber sie sollte vorhanden sein, und du musst von Anfang an daran denken.

---

translationKey: "friday-releases"

Also, sollte man am Freitag deployen?

Es ist Freitag — lass uns etwas releasen. Oder denk über deine Release-Architektur nach — was blockiert die eigentliche Kontinuität in deiner CI/CD-Pipeline? Dein Release-Vertrauen zurückzugewinnen ist gar nicht so schwer.