Kleine Releases

XP setzt sich für kleine, häufige Releases ein. Das war 1999 radikal, als jährliche Releases normal waren. In vielen Organisationen ist es immer noch radikal.

Vorteile kleiner Releases:

Schnelleres Feedback: Kunden sehen echte Software früher. Sie können dir sagen, was falsch ist, bevor du zu viel vom Falschen gebaut hast.

Reduziertes Risiko: Jedes Release ist eine kleine Wette. Wenn es fehlschlägt, hast du Wochen verloren, nicht Monate. Du kannst schnell korrigieren.

Schnellere Wertlieferung: Fertige Features werden genutzt. Ein heute veröffentlichtes Feature ist besser als ein Feature, das auf ein großes Release in sechs Monaten wartet.

Verbesserte Moral: Das Team sieht, wie seine Arbeit genutzt wird. Ausliefern ist befriedigend. Lange Release-Zyklen zehren an der Motivation.

Bessere Qualität: Kleinere Releases bedeuten kleinere Änderungen. Kleinere Änderungen sind einfacher zu testen, einfacher zu debuggen und verursachen seltener Probleme.

Die richtige Release-Frequenz hängt vom Kontext ab, aber strebe kleinere und häufigere Releases an, als sich komfortabel anfühlt.

Frequenz-Beispiele:

• Täglich (Continuous Deployment): Jeder Commit geht in Produktion
• Wöchentlich: Release am Ende jeder Iteration
• Zweiwöchentlich: Release nach jeder zweiten Iteration
• Monatlich: Monatlicher Release-Zyklus

Jeder Schritt kleiner ist besser, bis zu dem Punkt, an dem der Release-Overhead dominiert. Wenn ein Release einen ganzen Tag manuelle Arbeit erfordert, ist tägliches Releasen unpraktisch. Verbessere zuerst den Release-Prozess.

Anzeichen, dass du zu selten releast:

• Releases sind beängstigend (zu viel hat sich geändert)
• Integrationsprobleme sind häufig (große Batches)
• Kunden warten Monate auf Fixes
• Das Team hat „Merge-Wochen"

Kleine Releases erfordern technische Investitionen:

Automatisierte Tests: Du kannst nicht häufig releasen, wenn Testen Wochen dauert. Schnelle, umfassende automatisierte Tests sind essenziell.

Continuous Integration: Code muss reibungslos integrieren. Langlebige Branches sind mit häufigen Releases unvereinbar.

Deployment-Automatisierung: Releases müssen per Knopfdruck erfolgen. Manuelle Deployment-Schritte verlangsamen dich und führen zu Fehlern.

Feature Flags: Unvollständige Features können gemergt, aber vor Nutzern verborgen werden. Das ermöglicht kleine Releases, selbst wenn Features mehrere Iterationen umfassen.

Datenbank-Migrationsstrategie: Schema-Änderungen müssen deploybar sein, ohne bestehenden Code zu brechen. Normalerweise bedeutet das vorwärtskompatible Migrationen.

Monitoring und Rollback: Wenn etwas schiefgeht, musst du es sofort wissen. Und du musst schnell zurückrollen können.

Das sind nicht per se XP-Praktiken – es sind moderne DevOps-Praktiken, die XPs ursprüngliche Vision von Continuous Delivery ermöglichen.

Das logische Extrem kleiner Releases ist Continuous Deployment: Jeder Commit, der Tests besteht, geht direkt in Produktion.

Das klingt beängstigend. Aber mit den richtigen Praktiken ist es tatsächlich sicherer als große Releases:

• Jede Änderung ist winzig und leicht zu verstehen
• Wenn etwas kaputtgeht, weißt du genau, was es verursacht hat
• Rollback ist trivial (das letzte Deployment war vor Minuten)
• Kein „Release-Day"-Stress oder nächtliche Pushes

Continuous Deployment erfordert:

• Sehr hohe Testabdeckung
• Sehr schnelle Builds (maximal 10 Minuten)
• Robuste Feature Flags
• Exzellentes Monitoring
• Eine Kultur der Qualität (keine Abkürzungen)

Nicht jedes Team ist dafür bereit. Aber jedes Team kann sich in Richtung kleinerer, häufigerer Releases bewegen. Beginne damit, doppelt so oft zu releasen. Dann wieder doppelt so oft. Schau, wie weit du kommst.