Deployment & Rollout
Deployment stellt ein Artefakt in einer Laufzeitumgebung bereit. Ein Rollout steuert, wie Instanzen oder Verkehr von der bisherigen auf die neue Version wechseln.
- CanaryKleiner Verkehrsanteil zuerst.
- KriteriumVorab festgelegter Grenzwert.
- RückkehrpfadVorige Version bleibt aktivierbar.
Einordnung
Warum das wichtig ist
Wird eine neue Version auf einmal für alle ausgerollt, trifft ein Fehler sofort alle Kunden. Ein gestufter Rollout begrenzt die Wirkung und braucht einen Rückweg. Datenmigration und Recovery vertiefen eigene Bausteine.
Dieser Baustein behandelt Bereitstellung und Verkehrswechsel. Datenmigration plant kompatible Schemaänderungen; Wiederherstellung behandelt Rückkehr nach Daten- oder Systemverlust.
Auf einen Blick · Schrittweise Umschaltung zwischen Versionen
Canary-Rollout der Steuerregel
Der Shop veröffentlicht eine neue Steuerregel zunächst für einen kleinen Verkehrsanteil. Alte und neue Version lesen während des Rollouts dasselbe additive Datenbankschema.
So liest du das Bild
- Canary Stufen 1 %, 5 %, 25 % und 100 % bei „Verkehrsanteil neue Version“.
- Kriterium Hinweistexte je Stufe verlangen, Fehlerrate und Latenz zu prüfen, bevor es weitergeht.
- Rückkehrpfad Bei „Neue Steuerregel rechnet falsch“ empfiehlt der Hinweis, zurückzurollen.
- Verkehrsanteil neue Version
- 1 %
- betroffene Bestellungen pro Stunde
- 0 von 400
Sehr kleiner Anteil: Signale prüfen, bevor mehr Verkehr auf die neue Version geht.
Mengen illustrativ
Nutzen & Grenzen
Hilft, wenn
- Laufende Dienste benötigen für regelmäßige Aktualisierungen einen reproduzierbaren und beobachtbaren Versionswechsel.
- Stufenweise Freigaben verbinden Änderungen mit vereinbarten Messkriterien für Nutzerqualität.
Grenzen
- Fachliche Erfolgsindikatoren und repräsentative Abläufe ergänzen Prozess- und Readiness-Prüfungen vor jeder weiteren Freigabestufe.
- Inkompatible Datenänderungen können die Rückkehr zur alten Version verhindern; führe Schemaänderungen additiv ein und prüfe den Rückweg.
- Ohne Messwerte pro Version bleibt ein Canary blind; stütze Stopp-Regeln auf Observability und Ziele aus dem SLO.
In der Praxis
- Artefakt und Umgebung zuordnen. Versioniere das geprüfte Paket und halte fest, welche Konfiguration und Zielumgebung dazugehören. Verwende über alle Freigabestufen dasselbe Artefakt. Das Ergebnis ist eine eindeutige Verbindung zwischen Quellstand, Prüfung und bereitgestellter Version.
- Freigabekriterien festlegen. Definiere Readiness, Mindestkapazität, Beobachtungsdauer und Grenzwerte für Fehler oder Antwortzeiten. Bestimme vorab, wer die Ausweitung oder den Abbruch auslöst. Damit erfolgt die Verkehrsfreigabe anhand prüfbarer Bedingungen.
- Koexistenz und Rückweg prüfen. Teste Verträge und Daten mit parallel laufenden Versionen und definiere, wie Aufträge beim Beenden auslaufen. Prüfe, ob die vorherige Version nach Änderungen weiterhin lauffähig ist. Das Ergebnis ist ein belastbarer Rückkehrpfad.
Ausführliche Erklärung lesen
Deployment stellt ein geprüftes Artefakt in einer Zielumgebung bereit; der Rollout beschreibt den Wechsel von Instanzen oder Verkehr. Rolling Updates ersetzen Instanzen schrittweise, Canary-Verfahren geben einen kleinen Anteil frei. Readiness, Kapazität und geordnetes Beenden sichern den Übergang. Versionierte Artefakte und Datenkompatibilität verbinden den Rollout mit Datenmigration und der Wiederherstellung.
Alte und neue Versionen können zeitweise parallel laufen und müssen gemeinsame Verträge verstehen. Ein Rollback der Anwendung setzt voraus, dass frühere Versionen verbleibende Daten weiterhin lesen können. Freigabeschritte vergleichen definierte Betriebsindikatoren und Nutzersignale. Ein erfolgreicher Prozessstart allein bestätigt weder fachlichen Erfolg noch Datenkompatibilität; das Rolloutverfahren braucht daher Kriterien für Ausweitung, Abbruch und Rückkehr.
Blue-Green hält zwei vollständige Umgebungen vor und schaltet den Verkehr auf die neue um; ein Canary Release gibt der neuen Version zunächst nur einen kleinen Anteil.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie viele Bestellungen pro Stunde sind bei 5 % mit Defekt betroffen?
Lösung mit Begründung ansehen
20 von 400 Bestellungen pro Stunde (illustrativ).
AnwendenAuf eine neue Lage übertragen
Bei 5 % steigt die Fehlerrate über den Grenzwert. Was tust du?
Lösung mit Begründung ansehen
Den Rollout stoppen und auf die vorige Version zurückrollen. Der Anteil wird nicht erhöht.
BewertenEine Alternative abwägen
Das Team rollt direkt mit 100 % aus. Was spricht dafür, was dagegen, was empfiehlst du?
Lösung mit Begründung ansehen
Vorteil: schneller, nur eine Version. Nachteil: Ein Defekt trifft sofort alle 400 Bestellungen pro Stunde. Empfehlung: mit 1 % oder 5 % starten, Signale prüfen, dann stufenweise erhöhen.
Vertiefen
Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.
Serverless-Ausführung
Bei Serverless stellt und skaliert die Plattform Laufzeitressourcen für Funktionen oder verwaltete Dienste. Zustandsbehaftete Abläufe und Daten gehören in dafür vorgesehene externe Speicher. Ausführungsdauer, Cold-Start-Latenz, Parallelität und Plattformgrenzen prägen den Entwurf; Betrieb und Architekturverantwortung bleiben beim Team.
Im Shop kann die asynchrone Rechnungserstellung als Funktion laufen, während Auftragsstatus und Ergebnisdatei extern gespeichert werden. Lange Ausführungen oder benötigter lokaler Zustand können eine andere Laufzeit erfordern.
Zum AusprobierenPlane die asynchrone Rechnungserstellung im Shop als Serverless-Funktion: speichere Auftragsstatus und Ergebnisdatei extern, definiere Zeit- und Wiederholungsgrenzen und prüfe Cold-Start-Latenz sowie Parallelitätslimits. Benenne außerdem, welche Plattformgrenze bei langen Rechnungen oder benötigten lokalen Zuständen eine andere Ausführung verlangt.
Weiterführende Bausteine
Quellen
- Kubernetes – Deployments (öffnet in neuem Tab)Beschreibt Rolling Updates, Rollbacks und Fortschrittskontrolle.
- Martin Fowler – Blue Green Deployment (öffnet in neuem Tab)Erklärt Umschaltung und Rückfall zwischen zwei Deployment-Umgebungen.
- Google SRE Workbook – Canarying Releases (öffnet in neuem Tab)Zeigt schrittweise Freigabe und die Bewertung von Canary-Signalen.
- Microsoft · Leveraging serverless functions (öffnet in neuem Tab)Ausführungsmodell, Aufgaben und Startlatenz von Serverless-Funktionen.