Deployment vs Release: Wann Nutzer tatsächlich Ihre neue Version erhalten

Ihr Team hat gerade Version 1.2.0 in Produktion deployed. Das Artefakt liegt auf dem Server, die Anwendung läuft, und alle Health-Checks zeigen Grün. Bedeutet das, dass alle Ihre Nutzer jetzt die neuen Funktionen verwenden? Wahrscheinlich nicht.

Vielleicht hat Ihr Team bestimmte Features bewusst versteckt, während es die Stabilität überwacht. Vielleicht wurde das Deployment auf einen neuen Server durchgeführt, der noch nicht mit den Nutzern verbunden ist. Die Lücke zwischen „der Code läuft“ und „Nutzer können ihn verwenden“ ist größer, als die meisten Teams annehmen.

Der Unterschied zwischen Deployment und Release

Ein Deployment ist eine technische Aktion. Sie platzieren ein Artefakt in einer Umgebung und bringen es zum Laufen. Der Server akzeptiert das neue Binary, die Datenbankmigration wird abgeschlossen, die Anwendung beginnt, auf Anfragen zu antworten. Aus Infrastruktursicht ist die Aufgabe erledigt.

Das folgende Flussdiagramm veranschaulicht, wie Deployment und Release auseinanderdriften:

flowchart TD A[Code Commit] --> B[Build & Test] B --> C[Deploy to Production] C --> D{Release-Strategie?} D -->|Feature Flags| E[Feature Flag Aus] D -->|Canary| F[5% Traffic routen] D -->|Blue-Green| G[In inaktive Umgebung deployen] E --> H[Flag für Nutzer aktivieren] F --> I[Überwachen & % erhöhen] G --> J[Traffic umschalten] H --> K[Nutzer greifen auf Feature zu] I --> K J --> K style C fill:#4a90d9,color:#fff style K fill:#27ae60,color:#fff

Ein Release ist eine geschäftliche Entscheidung. Es ist der Moment, in dem ein Feature oder Fix tatsächlich für Nutzer zugänglich wird. Ein Deployment kann ohne Release stattfinden, aber ein Release kann nicht ohne Deployment stattfinden.

Diese Unterscheidung ist wichtig, weil sie Ihre Sicht auf Risiken verändert. Wenn Deployment und Release dasselbe sind, trägt jedes Deployment das volle Gewicht der Nutzerauswirkungen. Wenn Sie sie trennen, gewinnen Sie Spielraum.

Feature Flags: Die einfachste Trennung

Feature Flags sind der häufigste Weg, Deployment von Release zu entkoppeln. Sie fügen Code hinzu, der Funktionen ein- oder ausschalten kann, ohne ein erneutes Deployment durchzuführen. Die neue Version geht mit mehreren Features in Produktion, aber nur eines ist für eine kleine Nutzergruppe aktiv.

Hier ist ein einfaches Beispiel, wie eine Feature-Flag-Konfiguration in einer YAML-Datei aussehen könnte:

# config/feature-flags.yaml
features:
  new-checkout:
    enabled: false
    description: "Neuer Checkout-Ablauf mit einseitiger Zahlung"
    rollout_percentage: 0
  dark-mode:
    enabled: true
    description: "Dark-Mode-Umschalter für alle Nutzer"
    rollout_percentage: 100

Wenn das Team bereit ist, den neuen Checkout zu releasen, ändern sie enabled: false in enabled: true und aktualisieren den Rollout-Prozentsatz. Keine Codeänderung, kein erneutes Deployment – nur eine Konfigurationsaktualisierung, die sofort wirksam wird.

Wenn das Feature gut funktioniert, öffnen Sie es für mehr Nutzer. Wenn etwas kaputt geht, schalten Sie das Flag aus. Kein Rollback nötig, kein Notfall-Deployment. Der Rest der Anwendung läuft normal weiter.

Dieses Muster eignet sich besonders gut für Teams, die häufig deployen. Sie können mehrmals täglich Code deployen, ohne sich Sorgen machen zu müssen, unfertige Funktionen freizugeben. Das Flag wird zu Ihrem Sicherheitsschalter.

Canary Releases: Mit echtem Traffic testen

Canary Releases gehen bei der Trennung noch weiter. Sie deployen die neue Version in Produktion, leiten aber nur einen kleinen Prozentsatz der Nutzer dorthin – sagen wir 5 Prozent. Diese Gruppe bekommt den neuen Code, während alle anderen auf der alten Version bleiben.

Sie überwachen Fehlerraten, Antwortzeiten und das Nutzerverhalten für diese kleine Gruppe. Wenn alles normal aussieht, erhöhen Sie den Prozentsatz schrittweise. Wenn etwas schiefgeht, leiten Sie den gesamten Traffic zurück zur alten Version. Kein Rollback nötig, keine Ausfallzeit.

Der entscheidende Vorteil ist, dass Sie mit echtem Traffic testen, nicht mit synthetischen Tests. Echte Nutzer haben echte Browser, echte Netzwerkbedingungen und echte Nutzungsmuster. Ein Canary erkennt Probleme, die Staging-Umgebungen niemals aufdecken würden.

Blue-Green-Deployment: Trennung auf Infrastrukturebene

Blue-Green-Deployment trennt Release und Deployment auf Infrastrukturebene. Sie betreiben zwei identische Produktionsumgebungen: Blue und Green. Die alte Version läuft auf Blue. Sie deployen die neue Version auf Green, während Blue weiterhin alle Nutzer bedient.

Wenn Sie sicher sind, dass Green stabil ist, schalten Sie den Traffic von Blue auf Green um. Der Release erfolgt im Moment der Traffic-Umschaltung, nicht beim Abschluss des Deployments. Wenn nach der Umschaltung etwas schiefgeht, schalten Sie den Traffic zurück zu Blue.

Dieses Muster ist nützlich für Anwendungen, bei denen Sie nicht einfach Feature Flags verwenden können oder bei denen die Änderungen zu grundlegend sind, um sie mit einem Flag zu schalten. Datenbankschema-Änderungen, große Framework-Upgrades oder Infrastrukturmodifikationen profitieren oft von Blue-Green-Deployment.

Warum die Trennung von Deployment und Release wichtig ist

Die Trennung gibt Ihnen Kontrolle über das Timing. Sie können um 2 Uhr morgens deployen, wenn der Traffic niedrig ist, aber das Release bis zum Morgen verzögern, wenn Ihr Team bereit ist, zu überwachen. Sie können mehrmals täglich deployen, ohne sich Sorgen machen zu müssen, Nutzer zu stören, weil das Release eine separate Entscheidung ist.

Es verändert auch, wie Sie mit Problemen umgehen. Wenn Deployment und Release gekoppelt sind, sehen Nutzer bei einem schlechten Deployment sofort Fehler. Wenn sie getrennt sind, haben Sie Zeit, Probleme zu erkennen, bevor Nutzer betroffen sind. Die Health-Signale vom Deployment sagen Ihnen, dass der Server läuft. Die Signale nach dem Release sagen Ihnen, dass die Nutzer zufrieden sind.

Worauf Sie nach dem Release achten sollten

Ein Release ist der Moment, in dem Nutzer Ihre Änderungen erleben. Vor dem Release liegt alles in Ihrer Kontrolle. Nach dem Release sind die Nutzer involviert. Wenn es ein Problem gibt, spüren sie es zuerst.

Health-Checks, die während des Deployments grün aussahen, erzählen möglicherweise nicht die ganze Geschichte. Die Anwendung läuft, aber erledigen die Nutzer ihre Aufgaben? Sind die Fehlerraten wirklich niedrig, oder treten Fehler in Teilen der Anwendung auf, die Ihr Monitoring nicht abdeckt? Ist die Leistung unter realer Nutzerlast stabil?

Sie müssen nach dem Release anders überwachen. Beobachten Sie nutzerorientierte Metriken: Seitenladezeiten, Abschlussraten von Transaktionen, Fehlerraten nach Feature. Vergleichen Sie sie mit der Baseline vor dem Release. Ein grünes Deployment mit einem schlechten Release ist immer noch ein schlechtes Ergebnis.

Praktische Checkliste für Ihr nächstes Release

Bevor Sie ein Release als abgeschlossen bezeichnen, gehen Sie diese Punkte durch:

  • Können Sie ohne erneutes Deployment zurückrollen? Wenn nicht, wie lautet Ihr Rollback-Plan?
  • Wissen Sie, welche Nutzer die neue Version sehen? Wenn Sie ein Canary durchführen, bestätigen Sie, dass die Traffic-Aufteilung funktioniert.
  • Überwachen Sie nutzerorientierte Metriken, nicht nur die Server-Gesundheit? Die Server-Gesundheit sagt Ihnen, dass die App läuft. Nutzermetriken sagen Ihnen, dass die App funktioniert.
  • Haben Sie eine Möglichkeit, das Feature ohne erneutes Deployment zu deaktivieren? Wenn Sie keine Feature Flags verwenden, sollten Sie sie vor dem nächsten Release hinzufügen.
  • Wer muss über das Release informiert werden? Support-Teams, Dokumentationsautoren und andere Stakeholder sollten benachrichtigt werden.

Das Fazit

Deployment bringt Code auf Server. Release bringt Features in die Hände der Nutzer. Behandeln Sie sie als separate Entscheidungen, und Sie gewinnen die Fähigkeit, selbstbewusst zu deployen, sorgfältig zu releasen und sich schnell zu erholen, wenn etwas schiefgeht. Die besten Teams deployen nicht nur gut – sie releasen gut, weil sie wissen, dass die beiden Dinge nicht dasselbe sind.