Jede Änderung direkt in Produktion zu deployen, kann beängstigend sein – aber nicht direkt in Produktion zu deployen, ist noch beängstigender.
Genau diesen Prozess habe ich bei Amazon umgesetzt, wo ich ein Team geleitet habe, das für Hunderte Millionen Kunden deployed hat. In meiner Beratungstätigkeit habe ich Engineering-Teams von zweiwöchentlich geplanten Releases hin zu Deployments bei jedem einzelnen Merge geführt.
Fangen wir mit dem Offensichtlichen an:
Du wirst einen Ausfall verursachen. Es ist keine Frage des Ob, sondern des Wann.
Egal wie viel Unit-Testing, Integrationstests, Dogfooding, End-to-End-was-auch-immer oder Opfergaben an die Deploy-Götter – kein Test wird jeden Bug finden.
Das Testing, das du vor einer Woche für dein Feature gemacht hast, wurde nicht mit den neuesten Änderungen deiner Teamkollegen getestet. Dein Testing lief gegen die Pre-Prod-Version des Services deiner Teamkollegen. Inzwischen hat sich der Service geändert und enthält eine abwärtsinkompatible Änderung.
Je länger du wartest, desto mehr Änderungen stapeln sich in einem Release. Falls du ein Rollback brauchst, musst du zwei Wochen Änderungen zurückrollen statt nur 1–2 Stunden.
Wenn wir akzeptieren, dass ein Ausfall unvermeidlich ist, ergibt es viel weniger Sinn, massive Ressourcen in das QA eines Releases zu stecken. Stattdessen sollten wir unsere Ressourcen darauf konzentrieren, ein Release zu überwachen und zu beobachten – und darauf vorbereitet zu sein, einen Ausfall zu beheben, wenn er passiert.
Jetzt dazu, wie wir dorthin kommen:
Voraussetzungen:
CI/CD
Testing ist viel weniger wichtig, als du denkst. Tests können nicht beweisen, dass deine Änderung in Produktion sicher ist. Nichts kann das. Was Tests bewirken: Sie machen Fehler günstig. Ein Bug, der in CI auffällt, kostet Minuten. Ein Bug in Produktion kostet dich den Abend mit Rollback.
Also lass die komplette Testsuite bei jedem Merge laufen – oder zumindest als Teil der Pipeline: Unit-, Integrations- und End-to-End-Tests. Je weiter der Bug durch die Pipeline wandert, desto teurer wird seine Behebung.
Monitoring/Observability
Das A und O ist es, eine Regression so früh wie möglich zu erkennen. Dafür brauchst du exzellentes Monitoring. Das umfasst:
- Metriken: Fehler, Latenz, Verfügbarkeit
- Logs mit Korrelations-IDs
- Alarme für Sev-3 und Sev-2 (Paging), die auf den beiden oben genannten basieren
Die Feinabstimmung deiner Alarmschwellwerte ist eine Mischung aus Kunst und Wissenschaft. Es ist ein Balanceakt zwischen Sensibilität und der Geschwindigkeit, mit der du auf einen echten Vorfall reagierst. Die Zeit bis zur Sev-2-Alarmierung sollte bei 5–10 Minuten liegen.
Anfangs wirst du wahrscheinlich falsch liegen und wahrscheinlich zu sensibel eingestellt sein. Leider lernt man das vor allem durch Trial and Error, also wirst du anfangs wahrscheinlich ein paar Mal um 2 Uhr nachts geweckt.
Feature Flags
Jede Änderung mit Risiko solltest du hinter einem Feature Flag / Remote Config ausliefern. Mit einem Feature Flag kannst du jede Änderung innerhalb weniger Minuten zurückrollen oder abschalten, statt das gesamte Deployment zurückrollen zu müssen. Außerdem kannst du – falls dein Feature-Flag-Dienst es unterstützt (und das sollte er) – das Feature prozentual oder kohortenbasiert ausrollen, was die Auswirkungen einer schlechten Änderung weiter reduziert.
Dadurch lässt sich das Deployen von Code vom Aktivieren des Codes entkoppeln. Subtiler Unterschied, aber ein Game Changer, wenn es um Risikoreduzierung geht.
Hinweis: Du brauchst einen Prozess, um diese wieder aufzuräumen. Idealerweise erstellst du für jedes angelegte Flag ein Ticket zur Entfernung. Sonst hast du eine erhebliche Regression, wenn dein Feature-Flag-Dienst ausfällt (und er wird ausfallen). Frag mich, woher ich das weiß.
Automatisches Rollback (Deploy-Time-Circuit-Breaker)
Ein Deploy-Time-Circuit-Breaker ist eine Funktion, mit der du das Deployment zurückrollen kannst, wenn du beim Ausrollen über die Fleet eine bestimmte Anzahl oder einen Prozentsatz an Fehlern siehst. Die meisten Cloud-Provider bieten das inzwischen mit einem einfachen Kontrollkästchen an.
Abwärtskompatible Änderungen
Das solltest du eigentlich schon längst machen, aber das Deployen bei jedem Commit erzwingt die Praxis. Während eines Rolling Deployments laufen die alte und die neue Version gleichzeitig. Jede Änderung muss mit der vorherigen Version zusammenarbeiten können. Dein Trick, um Mitternacht zu deployen, um das zu umgehen, funktioniert nicht mehr.
Deployment-Strategien
Nachdem diese Voraussetzungen stehen, schauen wir uns ein paar verschiedene Deployment-Strategien an, die das Risiko beim Ausrollen deiner Änderungen reduzieren.
One Box (Canary)
Bei einem One-Box-Deployment werden deine Änderungen auf eine einzige Box in der gesamten Fleet deployed. So beschränken sich die Auswirkungen schlechter Änderungen auf nur einen Host. Du deployst und lässt das Ganze eine Weile laufen, während die Box einen kleinen Bruchteil des gesamten Traffics abbekommt. Auf dieser Box hast du dein Monitoring und Alerting so konfiguriert, dass du alarmiert wirst, wenn etwas kaputtgeht.
Rolling Deployments
Ein Rolling Deployment erlaubt es dir, prozentual über einen Zeitraum auszurollen. Wenn also ein katastrophaler Fehler auftritt, fängst du ihn ab, bevor er alle Maschinen betrifft, und kannst dann mit dem Zurückrollen beginnen.
Regional Rollout
Wenn dein Unternehmen wächst, wirst du zwangsläufig Multi-Region-Deployments haben. Statt in alle Regionen gleichzeitig zu deployen, kannst du zuerst in eine bestimmte Region deployen – typischerweise die mit dem geringsten Traffic.
Fälle, in denen das nicht gilt
App Store
Das Ausliefern einer Mobile App ist mit dieser Vorgehensweise nicht vollständig kompatibel. Die Review-Queue des App Stores drosselt deinen Deployment-Rhythmus und erfordert eine andere Strategie.
Zertifizierte Umgebungen
Medizingeräte, Avionik, industrielle Steuerungssysteme usw. Du kannst nicht kontinuierlich deployen, wenn eine Aufsichtsbehörde den Build zertifizieren muss.
On-prem / Self-hosted
Du hast keine Kontrolle über das Upgrade. Du kannst zwar auf allem, was du betreibst, kontinuierlich deployen, aber du musst jede Änderung versionieren – und dein Kunde entscheidet, wann sie übernommen wird.
Wo du anfangen solltest
Mach nicht alles auf einmal. Die Reihenfolge ist entscheidend:
- Mach CI grün und schnell. Idealerweise unter 15 Minuten
- Richte Metriken und Alarme für Fehlerrate, Latenz und Verfügbarkeit ein. Das ist der wichtigste Teil der Übung
- Setze jede riskante Änderung hinter ein Flag
- Füge One-Box + automatisiertes Rollback hinzu
- Streiche den Release-Kalender
- Finde eine neue Verwendung für deine ganze zusätzliche Zeit, jetzt wo du keine Releases mehr planst
Die meisten Teams, mit denen ich gearbeitet habe, brauchen etwa ein Quartal, um das durchzuziehen. Das Tooling ist der einfache Teil. Der organisatorische Prozess und das Zerstören der Illusion, dass geplante Releases sicher sind, sind der harte Teil.
Wenn dein Team auf einem Release-Kalender steht und runter möchte, ist das genau die Arbeit, die ich mache. Schreib mir eine DM.
