Azure App Service Deployment Slots Blue-Green-Deployments ohne Kubernetes

In meinen Azure-Kursen taucht dieses Szenario regelmäßig auf: Ein Entwicklerteam will Zero-Downtime-Deployments umsetzen, denkt sofort an Kubernetes und Container – und übersieht dabei, dass Azure App Service genau diese Anforderung out-of-the-box mitbringt. Deployment Slots sind das Werkzeug der Wahl, wenn Sie Blue-Green-Deployments für Web-Apps, API-Backends oder Function Apps realisieren wollen, ohne eine vollständige Container-Infrastruktur aufzubauen. Was viele nicht wissen: Die Feature sind ab dem Standard-Tier verfügbar und lassen sich in wenigen Minuten einrichten.

Ein Deployment Slot ist eine eigenständige Instanz innerhalb desselben App Service Plans, die eine eigene URL, eigene Umgebungsvariablen und einen eigenen Anwendungszustand besitzt. Der produktive Slot heißt immer production; alle weiteren Slots (z. B. staging, canary) sind zusätzliche Instanzen, die auf demselben zugrundeliegenden Rechenplan laufen.

Was sind Deployment Slots – und warum Blue-Green?

Das klassische Blue-Green-Deployment beschreibt ein Muster, bei dem zwei identisch konfigurierte Umgebungen parallel betrieben werden – eine aktive (Blue/Produktion) und eine inaktive (Green/Staging). Das neue Release wird in Green deployed, getestet und anschließend per Swap mit Blue zur aktiven Umgebung gemacht. Azure App Service setzt dieses Muster nativ um: Der Swap-Vorgang ist atomar, nahezu verzögerungsfrei und vollständig reversibel.

Merke: Ein Slot-Swap ist kein Neustart und kein Re-Deploy – Azure tauscht die Routing-Zeiger und wärmt den neuen Slot vorab auf. Nutzer, die gerade eine Anfrage stellen, werden nicht unterbrochen.

Slot-Konfiguration: Was bleibt, was wechselt?

Beim Swap werden nicht alle Einstellungen mitgetauscht. Das ist Absicht – und gleichzeitig eine der häufigsten Fehlerquellen, die ich in meinen Azure-Kursen sehe. Die folgende Tabelle zeigt, welche Einstellungen slot-sticky (also an den Slot gebunden) bleiben und welche mit dem Swap in die Produktion wandern.

Praxistipp: Markieren Sie Datenbankverbindungsstrings und alle umgebungsabhängigen API-Keys grundsätzlich als „slot setting“ (Häkchen „Deployment slot setting“ im Portal oder --slot-setting in der Azure CLI). Sonst zeigt Ihr Staging-Slot nach dem Swap plötzlich auf die Produktionsdatenbank – ein Fehler, der in der Praxis häufiger vorkommt als man denkt.

Swap-Vorgang und Traffic-Steuerung im Detail

Der eigentliche Swap läuft in zwei Phasen ab, die Azure intern koordiniert:

Phase 1 – Warm-up: Azure übernimmt die Slot-Einstellungen des Ziel-Slots (Produktion) in den Quell-Slot (Staging) und startet die Anwendung neu. Erst wenn alle Instanzen des Staging-Slots auf HTTP 200 antworten, beginnt Phase 2.

Phase 2 – Traffic-Switch: Azure leitet alle neuen Anfragen auf den bisher als Staging laufenden Slot um. Der bisherige Produktions-Slot bleibt vollständig erhalten und kann bei Bedarf innerhalb von Sekunden zurückgetauscht werden (Swap with Preview oder direkter Rollback-Swap).

Für Teams, die noch kein Vertrauen in einen direkten 100-%-Swap haben, bietet Azure die Traffic Routing-Funktion (auch als Testing in Production bekannt). Sie können einen prozentualen Anteil des Live-Traffics an den Staging-Slot routen – beispielsweise 10 % – und so echte Nutzer kontrolliert auf die neue Version führen, ohne einen vollständigen Swap durchzuführen. Das entspricht dem Canary-Release-Muster.

Per Azure CLI lässt sich der Swap vollständig automatisieren und in CI/CD-Pipelines integrieren:

# Deployment in den Staging-Slot
az webapp deployment source config-zip \
  --resource-group myRG \
  --name myApp \
  --slot staging \
  --src release.zip

# Swap: Staging → Produktion
az webapp deployment slot swap \
  --resource-group myRG \
  --name myApp \
  --slot staging \
  --target-slot production

In GitHub Actions oder Azure DevOps Pipelines ersetzen entsprechende Tasks (AzureWebApp@1 mit slotName: staging und anschließendem AzureAppServiceManage@0 für den Swap) diese CLI-Befehle – das Prinzip bleibt identisch.

Praxisempfehlung: KMU-taugliche Slot-Struktur

Folgendes Setup hat sich in der Praxis für mittelständische Teams bewährt, die Blue-Green ohne großen Overhead umsetzen wollen:

Drei Slots, klare Zuständigkeiten:

Noch mal in Kürze, zum Abharken:

• App Settings und Connection Strings für Datenbankverbindungen immer als „slot sticky“ markieren.
• Staging-Slot auf 1 Instanz begrenzen – spart Kosten, da derselbe App Service Plan genutzt wird, aber Staging keine Produktion-Last trägt.
• Swap immer per CLI oder Pipeline automatisieren, nie manuell im Portal – so ist der Vorgang reproduzierbar und auditierbar.
• Nach jedem erfolgreichen Swap den alten Produktions-Slot (jetzt Staging) für mindestens 30 Minuten erhalten, bevor ein erneuter Deploy stattfindet – das ist Ihr Rollback-Fenster.
• Application Insights für beide Slots konfigurieren, aber mit separaten Instrumentation Keys, damit Logs nicht vermischt werden.

Deployment Slots sind kein Ersatz für Kubernetes in allen Szenarien – aber für Web-Apps, REST-APIs und Azure Functions auf Basis von App Service sind sie die unkomplizierteste, kostengünstigste und am schnellsten produktiv einsetzbare Lösung für Zero-Downtime-Deployments. Wer tiefer in das Thema einsteigen will – Slot-Konfiguration, CI/CD-Integration und Monitoring nach dem Swap – findet das in meinen Azure-Kursen als praxisorientiertes Hands-on-Lab.