Die richtige Deployment-Strategie wählen: Neue Versionen ausrollen ohne Schaden anzurichten

Du hast gerade ein neues Feature fertiggestellt. Der Code hat alle Checks bestanden, die Tests sind grün, das Artefakt ist bereit. Jetzt kommt die eigentliche Frage: Wie bringst du diese neue Version auf den Server, ohne deine Nutzer zu verärgern?

Die einfachste Antwort ist: Server stoppen, Dateien ersetzen, Server wieder starten. Das funktioniert gut, wenn deine Anwendung von einer Handvoll Leuten genutzt wird, die wissen, dass eine Ausfallzeit ansteht. Aber für alles, was echte Nutzer bedient, bricht dieser Ansatz sofort zusammen. Leute sehen Fehlerseiten. Requests scheitern. Vertrauen schwindet.

Das Kernproblem ist, dass du neuen Code in die Produktion bringen musst, während der alte Code noch Traffic bedient. Du kannst nicht einfach alles auf einmal austauschen. Du brauchst eine Strategie, die den Übergang von einer Version zur nächsten ermöglicht, ohne den Dienst zu unterbrechen.

Es gibt drei gängige Strategien dafür: Rolling Update, Blue/Green Deployment und Canary Deployment. Jede löst das gleiche Problem auf unterschiedliche Weise und jede passt zu einer anderen Situation.

Rolling Update: Ein Server nach dem anderen ersetzen

Das Rolling Update ist die am weitesten verbreitete Strategie. Die Idee ist einfach: Statt alle Server auf einmal zu ersetzen, werden sie nacheinander oder in kleinen Gruppen ausgetauscht.

Stell dir vor, du hast zehn Server, die deine Anwendung ausführen. Bei einem Rolling Update nimmst du zwei Server offline, installierst die neue Version auf ihnen und bringst sie wieder online. Sobald diese beiden die neue Version ausführen, gehst du zu den nächsten beiden über. Das wiederholst du, bis alle zehn Server die neue Version ausführen.

Der große Vorteil hier ist, dass du keine zusätzlichen Server brauchst. Du nutzt die gleiche Infrastruktur wieder. Die Kosten sind minimal, weil du keine doppelten Umgebungen bereitstellst.

So sieht ein Rolling Update in einem Kubernetes Deployment Manifest aus:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: my-app:2.0.0

Diese Konfiguration stellt sicher, dass immer nur ein neuer Pod erstellt wird (maxSurge: 1) und kein alter Pod heruntergefahren wird, bis der neue bereit ist (maxUnavailable: 0). Das Update erfolgt Pod für Pod, wobei der Dienst durchgehend verfügbar bleibt.

Aber es gibt einen Haken. Während des Updates laufen zwei Versionen deiner Anwendung gleichzeitig. Einige Nutzer treffen auf die alte Version, andere auf die neue. Wenn sich der API-Vertrag zwischen den Versionen geändert hat, können Requests fehlschlagen. Ein Nutzer sendet vielleicht einen Request, der vom alten Server verarbeitet wird, aber das Antwortformat hat sich geändert. Oder der neue Server erwartet ein Feld, das der alte Client nicht sendet.

Rolling Update funktioniert gut, wenn die Änderungen abwärtskompatibel sind. Wenn du ein Feld hinzufügst, nicht entfernst. Wenn du eine API erweiterst, nicht ihre Struktur änderst. Wenn deine Datenbankschema-Änderungen additiv sind, nicht destruktiv. Für kleine, sichere Änderungen ist Rolling Update effizient und einfach.

Blue/Green Deployment: Zwei vollständige Umgebungen

Blue/Green Deployment verfolgt einen anderen Ansatz. Du betreibst zwei identische Umgebungen. Nenne sie Blau und Grün. Zu jedem Zeitpunkt bedient nur eine davon den Live-Traffic. Die andere ist im Leerlauf oder läuft mit der vorherigen Version.

So funktioniert es. Deine Nutzer treffen gerade auf die blaue Umgebung. Du stellst die neue Version in der grünen Umgebung bereit. Sobald die grüne Umgebung vollständig bereit ist und du überprüft hast, dass sie funktioniert, schaltest du den Traffic um. Alle Nutzer treffen jetzt auf die grüne Umgebung. Wenn etwas schiefgeht, schaltest du zurück auf Blau. Der Rollback ist sofort.

Diese Strategie ist sicherer, weil es nie eine Mischung von Versionen gibt. Nutzer wechseln von einer vollständigen Version zur anderen. Es gibt keine Phase, in der die Hälfte der Server alten Code und die Hälfte neuen Code ausführt. Der Übergang ist sauber.

Der Nachteil sind die Kosten. Du brauchst die doppelten Ressourcen. Zwei vollständige Umgebungen, jede mit der gleichen Kapazität, die gleichzeitig laufen. Für kleine Anwendungen mag das erschwinglich sein. Für große können die Kosten beträchtlich sein.

Blue/Green ist ideal für kritische Anwendungen, bei denen Ausfallzeiten inakzeptabel sind und der Rollback schnell sein muss. Wenn du eine größere Änderung, eine Datenbankmigration oder etwas bereitstellst, das viele Teile des Systems betrifft, gibt dir Blue/Green ein Sicherheitsnetz.

Canary Deployment: Zuerst in einer kleinen Gruppe testen

Canary Deployment ist wie ein Rolling Update, aber vorsichtiger. Statt Server in Gruppen zu ersetzen, beginnst du mit einem sehr kleinen Prozentsatz. Vielleicht 5 Prozent deiner Server bekommen die neue Version. Der Rest bleibt auf der alten Version.

Du beobachtest diese kleine Gruppe eine Weile. Wenn die Fehlerrate normal bleibt, die Antwortzeiten in Ordnung sind und niemand Probleme meldet, erhöhst du den Prozentsatz. Vielleicht auf 20 Prozent. Dann 50 Prozent. Dann 100 Prozent.

Die Idee ist, den Schadensradius zu begrenzen. Wenn die neue Version einen Fehler hat, erleben ihn nur wenige Nutzer. Du erkennst das Problem, bevor es zu einem vollständigen Ausfall wird.

Canary Deployment erfordert gutes Monitoring. Du musst wissen, wie Normalzustand aussieht. Du brauchst Dashboards, die Fehlerraten, Latenz und Durchsatz in Echtzeit anzeigen. Ohne diese Sichtbarkeit fliegst du blind. Du wirst nicht wissen, ob der Canary gesund ist oder nicht.

Diese Strategie funktioniert gut, wenn du eine Änderung in der Produktion validieren möchtest, bevor du dich vollständig darauf festlegst. Sie ist besonders nützlich für Leistungsänderungen, neue Algorithmen oder alles, bei dem das Verhalten unter echtem Traffic unsicher ist.

Die richtige Strategie wählen

Es gibt keine einzelne beste Strategie. Jede passt zu einer anderen Situation.

Das folgende Flussdiagramm kann dir helfen zu entscheiden, welche Strategie zu deiner Situation passt.

flowchart TD A[Welche Deployment-Strategie?] --> B{Kannst du dir doppelte Infrastruktur leisten?} B -->|Ja| C{Brauchst du sofortigen Rollback?} B -->|Nein| D{Ist die Änderung abwaertskompatibel?} C -->|Ja| E[Blue/Green Deployment] C -->|Nein| F{Hast du Echtzeit-Monitoring?} F -->|Ja| G[Canary Deployment] F -->|Nein| E D -->|Ja| H[Rolling Update] D -->|Nein| I{Hast du Echtzeit-Monitoring?} I -->|Ja| G I -->|Nein| E

Rolling Update ist der Standard für die meisten Teams. Es ist ressourceneffizient und funktioniert gut für Routineänderungen. Verwende es, wenn deine Änderungen abwärtskompatibel sind und du keinen sofortigen Rollback brauchst.

Blue/Green ist die sicherste Wahl. Verwende es für kritische Deployments, größere Versionswechsel oder wenn du sofort zurückrollen können musst. Sei bereit, für die zusätzliche Infrastruktur zu bezahlen.

Canary ist die vorsichtigste. Verwende es, wenn du die Auswirkungen einer Änderung beobachten möchtest, bevor du dich festlegst. Es erfordert gutes Monitoring und einen Prozess, um zu entscheiden, wann der Prozentsatz erhöht wird.

Viele Teams beginnen mit Rolling Updates und wechseln zu Blue/Green oder Canary, wenn ihre Anwendung kritischer wird und ihre Nutzerbasis wächst. Die Strategie, die du heute wählst, muss nicht die sein, die du für immer verwendest.

Praktische Checkliste vor der Wahl

  • Ist die Änderung abwärtskompatibel? Wenn ja, ist Rolling Update in Ordnung.
  • Brauchst du sofortigen Rollback? Wenn ja, ist Blue/Green sicherer.
  • Hast du Echtzeit-Monitoring? Wenn nein, ist Canary riskant.
  • Kannst du dir doppelte Infrastruktur leisten? Wenn nein, vermeide Blue/Green.
  • Möchtest du unter echtem Traffic testen? Wenn ja, bietet dir Canary das.

Was am meisten zählt

Die Strategie ist nicht der schwierige Teil. Der schwierige Teil ist zu verstehen, wie sich deine Anwendung während eines Übergangs verhält. Kommt sie mit zwei gleichzeitig laufenden Versionen klar? Kann sie eine kurze Phase mit gemischten API-Verträgen tolerieren? Hast du die Beobachtbarkeit, um Probleme zu erkennen, bevor Nutzer sie melden?

Wähle eine Strategie, die zu deiner Risikotoleranz und deinem Infrastrukturbudget passt. Teste sie dann. Nicht nur im Staging, sondern in der Produktion mit echten Traffic-Mustern. Das erste Mal, wenn du einen Blue/Green-Wechsel oder ein Canary-Rollout durchführst, mach es bei geringem Traffic. Beobachte die Metriken. Lerne, wie Normalzustand aussieht.

Deployment bedeutet nicht, Bits von einem Ort zum anderen zu verschieben. Es bedeutet, deine Nutzer zufrieden zu stellen, während du das Produkt verbesserst. Die richtige Strategie macht das möglich. Die falsche macht es schmerzhaft.