Deployment vs Release: Warum Ihr neuer Code die Nutzer noch nicht erreicht
Sie haben gerade ein Deployment abgeschlossen. Die Pipeline ist grün, das Artefakt liegt auf dem Produktionsserver, und Ihr Team ist bereit, den Vorgang als erledigt zu betrachten. Aber wenn Sie die Anwendung überprüfen, sehen die Nutzer immer noch die alte Version. Auf ihrer Seite hat sich nichts geändert.
Dieser Moment verwirrt viele Teams. Sie haben alles richtig gemacht. Der Code ist da. Der Server führt die neue Binärdatei aus. Warum erhalten die Nutzer dann kein Update?
Die Antwort ist einfach: Deployment und Release sind zwei verschiedene Dinge. Und das Verständnis dieses Unterschieds verändert Ihre Sichtweise auf das Ausliefern von Software.
Deployment bedeutet, dass der Code auf dem Server ist
Deployment ist der Vorgang, eine neue Version Ihrer Anwendung auf einem Server zu platzieren. Das Artefakt kommt aus Ihrer Registry, wird in die Zielumgebung kopiert, und der Server beginnt mit der Ausführung. Wenn Sie in die Produktion deployed haben, ist die neue Version physisch auf den Produktionsservern vorhanden.
Das war's. Deployment ist eine technische Aktion. Es sagt nichts darüber aus, ob Nutzer die neue Version tatsächlich verwenden können.
Stellen Sie es sich so vor: Sie haben einen neuen Film in den Projektor eines Kinos eingelegt. Der Film ist eingefädelt, die Spulen sind bereit, und der Projektor ist eingeschaltet. Aber der Film läuft noch nicht. Das Publikum sieht immer noch den vorherigen Film.
Das folgende Diagramm zeigt den zeitlichen Ablauf und den Traffic-Fluss zwischen alter und neuer Version während Deployment, Release und Canary-Release:
Release bedeutet, dass Nutzer die neue Version erhalten
Release ist der Moment, in dem die neue Version beginnt, echten Nutzer-Traffic zu bedienen. Traffic bedeutet die Anfragen, die von Nutzern an Ihre Anwendung gesendet werden. Solange der Traffic noch zur alten Version geleitet wird, spüren die Nutzer keine Auswirkungen des neuen Codes auf dem Server.
Die neue Version ist da. Sie läuft. Aber sie ist inaktiv. Niemand greift darauf zu.
Release ist, wenn Sie das Schild von "Demnächst" auf "Jetzt im Programm" umstellen. Der Projektor beginnt zu laufen, und das Publikum sieht den neuen Film.
Warum sollte man sie trennen?
Wenn Sie Deployment und Release gleichzeitig durchführen können, warum sollten Sie sie trennen wollen? Weil die Trennung Ihnen Kontrolle gibt.
Wenn Deployment und Release derselbe Vorgang sind, wird jedes Deployment zum Glücksspiel. Sie pushen Code, Nutzer sehen ihn sofort, und wenn etwas kaputt geht, erlebt jeder das Problem. Es gibt keinen Puffer zwischen "wir haben es hingebracht" und "Nutzer sehen es".
Wenn Sie sie trennen, erhalten Sie ein Zeitfenster. Sie können:
- Die neue Version deployen und sie inaktiv lassen.
- Ihr Verhalten ohne Nutzerauswirkung überwachen.
- Überprüfen, ob sie korrekt startet, Datenbankverbindungen herstellt und interne Anfragen verarbeitet.
- Probleme beheben, bevor ein Nutzer sie bemerkt.
Dieses Zeitfenster ist Ihr Sicherheitsnetz. Es verwandelt Deployment von einem risikoreichen Ereignis in einen Routinevorgang.
Wie man Deployment von Release trennt
Die einfachste Methode verwendet einen Load Balancer oder Reverse Proxy. So funktioniert es:
- Deployen Sie die neue Version zusammen mit der alten Version auf dem Server.
- Konfigurieren Sie den Load Balancer so, dass er allen Nutzer-Traffic zur alten Version leitet.
- Die neue Version läuft, erhält aber keine externen Anfragen.
- Wenn Sie bereit sind, aktualisieren Sie die Load-Balancer-Konfiguration, um Traffic zur neuen Version zu leiten.
Diese Konfigurationsänderung ist Ihr Release. Sie kann Sekunden nach dem Deployment oder Stunden später erfolgen. Der Zeitpunkt liegt bei Ihnen.
Hier ist ein praktisches Beispiel mit einer hypothetischen Load-Balancer-CLI zur Traffic-Verlagerung:
# Neue Version neben alter Version deployen
# (Annahme: beide laufen bereits auf dem Server)
# Aktuelle Traffic-Verteilung prüfen
trafficctl get-weight myapp
# Ausgabe: myapp-v1: 100%, myapp-v2: 0%
# 10% des Traffics zur neuen Version leiten (Canary)
trafficctl set-weight myapp-v2 10%
# Nach Überwachung: gesamten Traffic zur neuen Version leiten
trafficctl set-weight myapp-v2 100%
# Rollback bei Bedarf: sofort allen Traffic zurück zur alten Version leiten
trafficctl set-weight myapp-v1 100%
Canary-Releases: Schrittweise Ausrollen
Ein verfeinerter Ansatz ist das Canary-Release. Statt den gesamten Traffic auf einmal umzuleiten, senden Sie zunächst einen kleinen Prozentsatz der Nutzer zur neuen Version.
Angenommen, Sie haben tausend Nutzer. Sie beginnen damit, fünfzig von ihnen zur neuen Version zu leiten. Wenn nach fünf Minuten alles gut aussieht, erhöhen Sie auf zweihundert. Dann fünfhundert. Dann alle.
Dieser Ansatz begrenzt die Schadensreichweite. Wenn die neue Version einen Fehler hat, erleben ihn nur fünfzig Personen statt tausend. Sie erkennen Probleme frühzeitig mit minimalem Schaden.
Canary-Releases funktionieren auch gut mit Feature Flags. Sie können Code deployen, der hinter einem Flag verborgen ist, ihn für eine kleine Gruppe aktivieren, die Ergebnisse beobachten und das Publikum schrittweise erweitern.
Rollback ohne erneutes Deployment
Die Trennung macht auch Rollbacks einfacher. Wenn Sie eine fehlerhafte Version releasen, müssen Sie die alte nicht erneut deployen. Die alte Version ist noch auf dem Server, läuft noch und kann weiterhin Traffic verarbeiten.
Sie ändern einfach die Load-Balancer-Konfiguration zurück. Der Traffic wechselt zur alten Version. Die Nutzer sind innerhalb von Sekunden wieder auf stabilem Boden.
Vergleichen Sie das mit einem kombinierten Deploy-und-Release-Ansatz. Dort bedeutet ein Rollback:
- Das alte Artefakt finden.
- Es erneut deployen.
- Auf den Neustart des Servers warten.
- Hoffen, dass das Rollback selbst keine Probleme verursacht.
Dieser Vorgang dauert im besten Fall Minuten, oft länger. Während dieser Zeit treffen Nutzer auf eine kaputte Anwendung.
Wer entscheidet, wann released wird?
Deployment ist eine technische Entscheidung. Ihre CI/CD-Pipeline kann es automatisch erledigen. Aber beim Release sind oft Produkt- oder Business-Stakeholder involviert.
Das Produktteam weiß, ob die Funktion für Nutzer bereit ist. Sie möchten sie vielleicht zuerst intern testen, einen A/B-Test durchführen oder den Release aus Marketinggründen verschieben. Sie verstehen die Nutzerauswirkungen auf eine Weise, die die Deployment-Pipeline nicht kann.
Das bedeutet nicht, dass jeder Release eine Besprechung erfordert. Bei Routine-Updates können Sie den Release nach einer kurzen Beobachtungsphase automatisieren. Aber bei bedeutenden Änderungen sollte die Entscheidung zum Release von Personen getroffen werden, die den Geschäftskontext verstehen.
Eine praktische Checkliste für Ihren nächsten Release
Bevor Sie eine neue Version für Nutzer freigeben, gehen Sie diese Punkte durch:
- Läuft die neue Version bereits seit einigen Minuten fehlerfrei in der Produktion?
- Zeigen die Logs normales Verhalten?
- Haben Sie eine Möglichkeit, den Traffic bei Bedarf sofort zurück zur alten Version zu leiten?
- Hat jemand aus Produktsicht bestätigt, dass die Funktion bereit ist?
- Ist das Release-Fenster so gewählt, dass die Nutzerauswirkung minimiert wird?
- Wissen Sie, wen Sie kontaktieren müssen, wenn nach dem Release etwas schiefgeht?
Diese Liste ist bewusst kurz. Eine Überkomplizierung des Release-Prozesses führt dazu, dass Schritte übersprungen werden. Halten Sie es einfach und gehen Sie die Liste jedes Mal durch.
Die wichtigste Erkenntnis
Deployment und Release sind nicht dasselbe. Deployment bedeutet, Code auf einen Server zu bringen. Release bedeutet, Nutzer darauf zugreifen zu lassen. Die Behandlung als separate Aktionen gibt Ihnen Kontrolle über Risiko, Rollback-Geschwindigkeit und Nutzererfahrung.
Wenn Ihre Pipeline das nächste Mal grün wird, fragen Sie sich: Habe ich gerade nur deployed oder tatsächlich released? Die Antwort bestimmt, ob Ihre Nutzer das Update erhalten oder immer noch darauf warten, dass der Film beginnt.