Microsoft AZ-400: Release-Management und Deployment-Strategien — Lernleitfaden

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Teil des Microsoft DevOps Engineer Expert AZ-400 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Das Release-Management in Azure basiert auf wiederholbaren, richtliniengesteuerten Bereitstellungen, die die Verfügbarkeit schützen und gleichzeitig das Feedback beschleunigen. Die Beherrschung von Deployment-Strategien, gesteuerten Validierungen, ringbasierter Exposition und Feature-Flag-gesteuerten Dark Launches ermöglicht es Teams, kontinuierlich auszuliefern, ohne die Sicherheit zu beeinträchtigen. Azure Pipelines, Azure Deployment Environments, Azure Front Door/Traffic Manager und Azure App Configuration bieten eine kohärente Toolchain für progressive Bereitstellung, die Orchestrierung mehrerer Umgebungen und eine auditierbare Änderungskontrolle. Dieser Abschnitt erklärt, wann und wie die einzelnen Funktionen zu verwenden sind, wie sie miteinander verknüpft werden und welche Rollback- und Dokumentationspraktiken in produktionsreifen Pipelines erwartet werden.

Deployment-Strategien und progressive Bereitstellung

Bei Blue-Green (auch Red/Black genannt) wird die neue Version in einer parallelen Umgebung (Green) bereitgestellt, während die aktuelle (Blue) den Traffic bedient. In Azure App Service wird Blue-Green über Deployment-Slots umgesetzt: Bereitstellung im Staging-Slot, Aufwärmen und anschließender Slot-Tausch. Ein Rollback erfolgt sofort durch einen erneuten Tausch, weshalb Blue-Green die schnellste Rollback-Option ist. Kombinieren Sie Slot-Tausche mit „Swap with preview“ (Tausch mit Vorschau), um Bindungen und App-Einstellungen zu validieren, bevor der Traffic umgeleitet wird.

Bei Canary-Deployments wird die neue Version zunächst für einen kleinen Teil der Benutzer bereitgestellt. Der Traffic wird dann schrittweise erhöht, solange der Systemzustand stabil bleibt. In Azure kann Canary wie folgt implementiert werden:

Azure Front Door mit gewichtetem Routing, um den Traffic auf der Anwendungsebene zwischen alten und neuen Backends aufzuteilen, inklusive Health Probes und WAF.
Azure Traffic Manager mit gewichteten Endpunkten für DNS-basierte, globale Canaries, wenn eine Steuerung auf Regionsebene erforderlich ist.
AKS-Canary über Ingress (z. B. NGINX-Canary-Annotationen) oder Service-Mesh-Traffic-Splitting. Gates sollten Fehlerbudgets, Latenzperzentile und Sättigung bewerten, bevor die nächste Stufe erreicht wird.

Fortlaufende Updates (Rolling Updates) ersetzen Instanzen schrittweise und vermeiden so die Kosten für eine doppelte Flotte. In AKS wird rollingUpdate mit maxSurge und maxUnavailable konfiguriert; stellen Sie sicher, dass Readiness/Liveness Probes und PDBs die Verfügbarkeit schützen. Für VM Scale Sets verwenden Sie Rolling-Upgrade-Richtlinien mit Application Health Probes. Rolling Updates sind kostengünstig, aber die Wiederherstellung nach systemischen Regressionen ist langsamer als bei Blue-Green.

Feature Flags entkoppeln das Release vom Deployment. Beim Dark Launching werden Codepfade standardmäßig deaktiviert ausgeliefert, um die Infrastruktur zu testen, ohne die Funktionen für Benutzer freizulegen. Verwenden Sie Flags, um aufwändige Migrationen zu steuern, Benutzeroberflächen schrittweise einzuführen und problematisches Verhalten schnell zu deaktivieren. Dies ergänzt Canary- und Ring-Deployments: breitflächig bereitstellen, dann schrittweise aktivieren.

Ring-basiertes Deployment formalisiert die progressive Bereitstellung über verschiedene Benutzergruppen (Kohorten). Definieren Sie Ringe wie R0 (intern), R1 (Canary-Kunden), R2 (eine Region) und R3+ (global). Die Kriterien für den Übergang zum nächsten Ring müssen objektiv sein: Einhaltung von SLOs, keine Sev2+-Vorfälle und akzeptable Business-KPIs. Kombinieren Sie Ringe mit Traffic-Shifting (Front Door/Traffic Manager), Umgebungsprüfungen und Genehmigungs-Gates, um frühzeitig zu stoppen oder ein Rollback durchzuführen.

Azure Front Door im Vergleich zu Traffic Manager für progressives Traffic-Shifting: Front Door arbeitet auf Layer 7 mit sofortigen Änderungen, Health Probes, Sitzungsaffinität, pfadbasiertem Routing und gewichteten Aufteilungen – ideal für Canaries auf Anwendungsebene und A/B-Tests. Traffic Manager arbeitet auf DNS-Ebene; er eignet sich besser für Geo-Routing, cloudübergreifendes Failover oder Canaries auf Regionsebene, hat aber DNS-TTL-Aspekte zu berücksichtigen und keine Funktionen auf Anwendungsebene.

Umgebungen, Genehmigungen und Gates

Azure Deployment Environments standardisieren die Bereitstellung von Dev/Test-Umgebungen mit Leitplanken (Guardrails). Umgebungsdefinitionen sind Infrastructure-as-Code-Vorlagen (Bicep/ARM/Terraform), die wiederholbare Stacks beschreiben. Die Definitionen befinden sich in Katalogen – Git-Repositories, die beim Dienst registriert sind – und ermöglichen so versionierte, auffindbare Umgebungs-Blueprints. Entwickler können sich Dev/Test-Instanzen im Self-Service-Verfahren bereitstellen, die durch Unternehmensrichtlinien (Kontingente, RBAC, Netzwerk) eingeschränkt sind. Dies eliminiert Ad-hoc-Lösungen („Snowflakes“) und gleicht die unteren Umgebungen an die Produktionstopologie an.

Genehmigungen (Approvals) etablieren manuelle Kontrollen, wo sie erforderlich sind. In Azure Pipelines:

Pre-Deployment-Genehmigungen blockieren eine Stage, bis die benannten Genehmiger zustimmen. Verwenden Sie diese für risikoreiche Übergänge, z. B. von Staging zu Produktion oder bei der Eskalation eines Rings über den Canary-Status hinaus.
Post-Deployment-Genehmigungen bestätigen Validierungsaktivitäten (UAT-Abnahme, Auditschritte), bevor das Release als abgeschlossen markiert wird.
Konfigurieren Sie Timeouts für Genehmigungen, damit Anfragen automatisch ablaufen; abgelaufene Genehmigungen führen zum Fehlschlagen der Stage und verhindern unkontrollierte Abweichungen. Fordern Sie mehrere Genehmiger oder eine sequenzielle Genehmigung an, wenn eine Funktionstrennung (Separation of Duties) erforderlich ist. Wenden Sie Genehmigungen über „Approvals and checks“ (Genehmigungen und Prüfungen) auf Umgebungen und Dienstverbindungen an, um eine konsistente Governance zu gewährleisten.

Release-Gates erzwingen objektive Nachweise vor einer Höherstufung (Promotion). Azure Pipelines unterstützt Prüfungen (Checks) wie:

Azure Monitor-Prüfungen, die Metriken oder Warnungen abfragen (z. B. keine aktiven Sev2-Warnungen, Fehlerrate unter dem Schwellenwert, p95-Latenz unter dem Zielwert). Gates werden in einem definierten Intervall neu ausgewertet, bis sie erfolgreich sind, fehlschlagen oder ein Timeout auftritt.
„Invoke REST API“-Prüfungen, um externe Qualitätsdienste, Lasttests oder interne Compliance-Endpunkte aufzurufen. Werten Sie die Antworten aus und blockieren Sie, wenn die Kriterien nicht erfüllt sind.
„Work item query“-Prüfungen, um sicherzustellen, dass erforderliche Aufgaben, Bugs oder Änderungsanfragen vor dem Release den korrekten Status haben (z. B. alle „Must Fix“-Fehler behoben). Verwenden Sie Abfragen, die auf den Release- oder Commit-Bereich beschränkt sind.

Implementieren Sie Gates an den Grenzen zwischen den Ringen und während der Canary-Phase, um von subjektiven zu messbaren Entscheidungen für die Höherstufung überzugehen.

Feature-Flags mit Azure App Configuration und Automatisierung von Versionshinweisen

Azure App Configuration zentralisiert die Funktionsverwaltung mit SDKs für .NET, Java, Node.js und andere. Verwenden Sie Labels, um den Geltungsbereich von Flags pro Umgebung oder Ring festzulegen, und aktivieren Sie die dynamische Aktualisierung, damit Anwendungen Änderungen ohne erneute Bereitstellung übernehmen.

Zielgruppenfilter ermöglichen eine granulare Aktivierung basierend auf Benutzern/Gruppen, Claims, Geräten oder benutzerdefinierten Attributen. Definieren Sie Kohorten (z. B. interne Mandanten, VIP-Kunden), um sie an Ringen auszurichten.
Der prozentuale Rollout macht Funktionen schrittweise für eine zufällige Teilmenge verfügbar. Beginnen Sie mit 1–5 %, validieren Sie KPIs und erhöhen Sie dann schrittweise. Koordinieren Sie dies mit der Gewichtung von Front Door für eine mehrschichtige Steuerung auf Benutzer- und Traffic-Ebene.
Kill-Switches deaktivieren eine Funktion sofort, wenn Vorfälle auftreten. Sichern Sie risikoreiche Pfade (Zahlungen, Datenschreibvorgänge) mit einem globalen „Aus“-Schalter, dessen Ausführung keine Bereitstellungen erfordert. Protokollieren Sie alle Schalter für Audits und korrelieren Sie sie mit Vorfällen.

Automatisieren Sie Versionshinweise, um Nachverfolgbarkeit und Kommunikation zu gewährleisten:

Erzwingen Sie die Verknüpfung von Arbeitselementen, indem Sie verlangen, dass Commit-Nachrichten und PRs auf IDs verweisen. Azure DevOps verknüpft Builds und Releases automatisch mit Arbeitselementen und Commits.
Generieren Sie Änderungsprotokolle in Pipelines mithilfe der Aufgabe „Generate Release Notes“ oder über REST-API-Aufrufe, um Änderungen und Arbeitselemente seit der letzten erfolgreichen Bereitstellung in der Zielumgebung aufzulisten. Geben Sie Markdown mit Abschnitten für Funktionen, Korrekturen, Breaking Changes und Datenbankmigrationen aus.
Veröffentlichen Sie die Hinweise im Projekt-Wiki, verpacken Sie sie als Build-Artefakt und hängen Sie sie an das Release an. Fügen Sie Bereitstellungsmetadaten (Build-Nummer, Commit-SHA, Umgebung, Genehmiger, bestandene Gates) zur Einhaltung von Compliance-Vorschriften hinzu.

Praktisches Problemszenario

Adobe muss eine neue Personalisierungs-Engine für seine auf Azure gehosteten Marketing-Websites einführen, ohne die Konversionsraten während Spitzenkampagnen zu gefährden. Das Team muss häufig bereitstellen, die Funktion schrittweise verfügbar machen, SLOs validieren und bei einer Verschlechterung der KPIs sofort zurückrollen.

Umgebungen mit Azure Deployment Environments definieren

Erstellen Sie Umgebungsdefinitionen (Bicep) für App, AKS, Azure SQL und Front Door in einem Git-gestützten Katalog. Entwickler stellen Entwicklungs-/Testumgebungen sicher selbst bereit, um Parität mit der Produktion zu gewährleisten und kurzlebige Test-Stacks für Experimente zu ermöglichen. ADE setzt Kontingente und RBAC durch, um Ausgaben und Zugriff zu kontrollieren.

Einmal erstellen, mehrfach bereitstellen mit mehrstufigem YAML

Ein einziges Artefakt wird durch die Stufen ring-r0, ring-r1, ring-r2 und prod hochgestuft. Die Stufen hängen voneinander ab und verwenden Deployment-Jobs mit Strategien wie canary und rolling, wo es angebracht ist, was konsistente Binärdateien über alle Ringe hinweg garantiert.

Blue-Green mit App Service-Slots für die alte Web-Schicht verwenden

In einem Staging-Slot bereitstellen, aufwärmen und dann für interne Benutzer von ring-r0 tauschen. Wenn sich die SLOs von Adobe verschlechtern, bietet ein Zurücktauschen der Slots den schnellsten Rollback mit nahezu null Ausfallzeit.

Canary über gewichtetes Routing mit Azure Front Door einführen

Registrieren Sie sowohl die alten als auch die neuen Personalisierungs-Backends. Beginnen Sie mit 1 % Traffic zum neuen Backend in ring-r1. Azure Front Door-Integritätsprüfungen und sofortige Gewichtungsaktualisierungen ermöglichen sichere, schnelle Anpassungen, die an den Verkehrsmustern ausgerichtet sind.

Hochstufungen mit objektiven Prüfungen (Gates) steuern

Fügen Sie Azure Monitor-Prüfungen für p95-Latenz, Fehlerrate und Konversions-KPIs hinzu, die aus Application Insights stammen. Fügen Sie eine REST-API-Prüfung zum internen Experimentierdienst von Adobe hinzu, um Guardrail-Metriken zu bestätigen. Konfigurieren Sie eine Prüfung durch eine Arbeitselementabfrage, um sicherzustellen, dass „Must Fix“-Bugs vor der Hochstufung in den nächsten Ring geschlossen sind. Gates werden periodisch ausgewertet und haben ein Zeitlimit, um blockierte Änderungen zu verhindern.

Genehmigungen an kritischen Übergängen erfordern

Pre-Deployment-Genehmigungen für ring-r2 und prod erfordern die Freigabe durch Marketing und SRE, mit einem 4-Stunden-Timeout, um hängende Releases zu vermeiden. Post-Deployment-Genehmigungen bestätigen, dass die UAT- und Analysevalidierung abgeschlossen ist, bevor das Release geschlossen wird.

Verfügbarkeit mit Azure App Configuration Feature-Flags steuern

Implementieren Sie Dark Launching, sodass die neue Engine vorhanden, aber anfangs deaktiviert ist. Verwenden Sie Zielgruppenfilter, um sie für interne Mitarbeiter (ring-r0) und ausgewählte Kundenkohorten (ring-r1) zu aktivieren. Wenden Sie einen prozentualen Rollout an, um die Verfügbarkeit zu erweitern. Ein Kill-Switch deaktiviert die Engine global in Sekunden, ohne erneute Bereitstellung, falls Anomalien auftreten.

Daten mit Expand-Contract-Migrationen schützen

Stellen Sie zuerst additive SQL-Änderungen bereit, füllen Sie Daten asynchron auf und schreiben Sie bei Bedarf dual. Erst nachdem die Stabilität nachgewiesen ist, entfernen sie veraltete Schemata. Gates überwachen DTU, Deadlocks und langlaufende Abfragen, um eine unsichere Hochstufung zu verhindern.

Rollback-Pfade automatisieren

Fehler-Hooks bei Deployment-Jobs lösen einen Rollback aus: Die Gewichtungen von Azure Front Door kehren zu 0 % für das neue Backend zurück; App Service führt einen umgekehrten Slot-Tausch durch; AKS führt

undefined

aus. Ein manueller Ein-Klick-Rollback bleibt für Bediener in komplexen Szenarien verfügbar.

Versionsdokumentation automatisieren

Die Pipeline generiert Markdown-Versionshinweise aus den zugehörigen Arbeitselementen und Commits, wobei aktivierte Funktionen, Datenbankänderungen und bestandene Gates hervorgehoben werden. Die Hinweise werden im Azure DevOps Wiki veröffentlicht und an das Release angehängt, was die Anforderungen an Audits und die Sichtbarkeit für Stakeholder erfüllt.

Dieser Ansatz nutzt jedes Werkzeug für seine Stärke: ADE für sichere, reproduzierbare Umgebungen; YAML-Strategien und Genehmigungen für einen gesteuerten Ablauf; Front Door und App Configuration für eine mehrschichtige progressive Bereitstellung; Azure Monitor und Gates für eine objektive Qualitätskontrolle; und automatisierte Rollbacks und Versionshinweise für Resilienz und Nachverfolgbarkeit.

← Containerisierung und Kubernetes · Alle Domänen · Sicherheit →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →