Zum Inhalt springen

Zero Downtime Deployment

oder auch Deployment ohne Ausfallzeit

Männliche Person, frontal, schaut in die Kamera; trägt kariertes Hemd über dunkelfarbigem T‑Shirt; heller Innenraum mit unscharfem Monitor oder Poster links und Fenster rechts.

von Richard Albrecht am 03.11.2026

Zero Downtime Deployment ist ein Deployment, bei dem die Website durchgehend erreichbar bleibt. Der neue Stand wird vollständig daneben aufgebaut, und erst der letzte Schritt schaltet um.

Zero Downtime Deployment

Ein Deployment, bei dem die Website durchgehend erreichbar bleibt.
Beispiel: „Das Zero Downtime Deployment schaltete per Verweis um, kein Besucher sah eine Fehlerseite.“

Auf Deutsch Ausrollen ohne Ausfallzeit. Der übliche Weg legt je Stand ein eigenes Verzeichnis an und richtet am Ende einen symbolischen Verweis darauf.

Abgrenzung zum Wartungsfenster: Dieses nimmt die Website bewusst vom Netz. Beides hat seinen Platz, je nachdem, was geändert wird.

Wie ein Zero Downtime Deployment abläuft

In zwei Phasen. Zuerst entsteht der neue Stand neben dem laufenden: Dateien, Abhängigkeiten, gebaute Assets, geschriebene Zwischenspeicher. Nichts davon berührt die Besucher, die noch auf dem alten Stand unterwegs sind.

Die Abbildung zeigt den Handgriff, um den es dabei geht.

Drei Kästen nebeneinander, je ein Release-Verzeichnis mit Datum; der rechte ist blau gefüllt und als jetzt live beschriftet. Darunter ein blauer Kasten current, von dem ein blauer Pfeil zum neuen Stand zeigt und ein grauer gestrichelter zurück zum vorherigen.
Der neue Stand entsteht vollständig daneben. Sichtbar wird er erst, wenn der Verweis umgelegt ist.

Dann folgt der Schnitt. Der Verweis auf das aktuelle Verzeichnis wird in einem Zug umgelegt, und der nächste Aufruf landet im neuen Stand. Danach bleiben die Hintergrundprozesse und die Zwischenspeicher der Laufzeit.

Warum die Datenbank der schwierige Teil ist

Weil für einen Moment beide Stände auf dieselbe Datenbank zugreifen. Eine Spalte, die der neue Code braucht und der alte nicht kennt, ist unkritisch; eine Spalte, die der neue Code umbenennt, bricht den alten sofort.

Deshalb laufen solche Änderungen in zwei Releases: erst die Spalte hinzufügen und beide Namen bedienen, später den alten entfernen. Das kostet einen Schritt mehr und erspart die Pause, siehe Datenbank-Migration beim Deployment.

Was trotzdem kurz hakt

Drei Dinge. Der Zwischenspeicher für übersetzten PHP-Code kennt die neuen Dateien erst nach einem Signal, die Hintergrundprozesse laufen bis zu ihrem Neustart mit dem alten Code, und offene Verbindungen für Datenströme brechen beim Umschalten ab.

Für eine Website fällt das unter die Wahrnehmungsschwelle. Wer es genau wissen will, prüft nach dem Ausrollen die Fehlerrate der folgenden Minute, siehe Server Monitoring.

Siehe auch:

Deployment

Das Ausrollen eines neuen Stands auf den Server, auf dem die Website läuft.

#Deployment & Versionierung

Deploy-Skript

Die Abfolge von Befehlen, die ein Deployment ausführt, als Datei festgehalten.

#Deployment & Versionierung

Downtime

Die Zeit, in der eine Website oder ein Dienst nicht erreichbar ist.

#Hosting & Webserver

Rollback

Das Zurückschalten auf den vorherigen Stand, wenn ein Deployment Schaden anrichtet.

#Deployment & Versionierung

Load Balancing

Die Verteilung von Anfragen auf mehrere Server, damit keiner überlastet wird.

#Hosting & Webserver

Blue-Green-Deployment

Zwei vollständige Umgebungen, zwischen denen der Verkehr umgeschaltet wird.

#Deployment & Versionierung