Deployment ohne Ausfall: wie neue Versionen live gehen, ohne die Seite zu stören

Jede neue Version einer Website oder Anwendung muss irgendwann den Sprung vom Testsystem auf die Live-Umgebung schaffen – dieser Moment heißt Deployment. Er ist technisch unscheinbar, aber genau hier häufen sich in der Praxis die Störungen, die Kunden am direktesten zu spüren bekommen: eine Seite, die für einige Minuten gar nicht oder nur teilweise lädt.

Dabei lässt sich dieser Moment so gestalten, dass Besucher davon im Idealfall nichts mitbekommen. Dieser Artikel erklärt, was beim klassischen Deployment schiefgehen kann, wie ausfallfreie Verfahren funktionieren und warum ausgerechnet Datenbank-Änderungen der heikelste Teil bleiben.

Was Deployment bedeutet und warum es ein kritischer Moment ist

Deployment bezeichnet den Vorgang, eine neue Version von Code, Konfiguration oder Inhalten auf das produktive System zu übertragen, das Besucher tatsächlich sehen. Zwischen alter und neuer Version liegt ein Übergang, der je nach Vorgehen wenige Millisekunden oder mehrere Minuten dauern kann.

In dieser Übergangszeit kann es zu Inkonsistenzen kommen: Ein Teil der Anfragen wird noch von der alten Version beantwortet, ein anderer Teil bereits von der neuen, während Dateien oder Datenbankstrukturen sich womöglich schon geändert haben. Genau diese Übergangsphase sauber zu gestalten, ist der Kern von ausfallfreiem Deployment.

Wie häufig ein Deployment stattfindet, unterscheidet sich stark zwischen Projekten: von seltenen, gut vorbereiteten Updates alle paar Wochen bis zu mehreren kleinen Änderungen am selben Tag. Je häufiger Deployments stattfinden, desto wichtiger wird ein verlässlicher, wiederholbarer Ablauf, weil sich improvisierte Schritte auf Dauer nicht durchhalten lassen.

Der klassische Ansatz – und sein Risiko

Im einfachsten Fall wird die laufende Anwendung gestoppt, die neue Version hochgeladen und anschließend neu gestartet. In dieser Zeitspanne ist die Website vollständig nicht erreichbar – bei kleinen, seltenen Änderungen mag das für wenige Sekunden tolerierbar sein, bei größeren Updates oder unter Last kann daraus spürbarer Ausfall werden.

Problematisch wird dieser Ansatz vor allem, wenn während des Uploads ein Fehler auftritt: Die alte Version läuft dann bereits nicht mehr, die neue aber noch nicht vollständig oder fehlerhaft. Ohne klaren Rückweg bleibt die Seite in diesem Zustand hängen, bis jemand manuell eingreift.

Wie ausfallfreies Deployment im Prinzip funktioniert

Ausfallfreie Verfahren beruhen im Kern auf einer einfachen Idee: Die neue Version wird vollständig vorbereitet und getestet, während die alte Version weiterhin alle Anfragen bedient. Erst wenn die neue Version nachweislich funktioniert, wird der Datenverkehr schrittweise oder auf einen Schlag von der alten auf die neue Version umgeleitet.

Ein verbreitetes Prinzip dafür ist, zwei vollständige, parallele Umgebungen zu betreiben – eine aktive und eine vorbereitete. Läuft die neue Umgebung stabil, wird lediglich die Weiche umgelegt, welche der beiden Umgebungen tatsächlich Besucher bedient. Stellt sich danach ein Problem heraus, lässt sich die Weiche ebenso schnell wieder zurücklegen.

Ein anderes verbreitetes Prinzip tauscht Server oder Instanzen schrittweise aus, statt alle auf einmal umzustellen, sodass zu jedem Zeitpunkt ein Teil der Infrastruktur mit der bewährten Version weiterläuft.

Der heikelste Teil: Datenbank-Änderungen

Während sich Code und statische Dateien relativ unkompliziert parallel vorhalten lassen, ist eine Datenbank meist ein einzelner, gemeinsam genutzter Zustand. Ändert eine neue Version die Struktur der Datenbank, etwa durch ein neues Datenfeld, muss diese Änderung so gestaltet sein, dass auch die noch laufende alte Version damit klarkommt, solange beide Versionen parallel aktiv sind.

Wird diese Rückwärtskompatibilität nicht beachtet, kann die alte Version während des Übergangs plötzlich auf Datenstrukturen treffen, die sie nicht kennt, und mit Fehlern reagieren. Sichere Datenbank-Änderungen werden deshalb häufig in mehrere kleine, für sich genommen unkritische Schritte zerlegt, statt eine komplette Strukturänderung in einem einzigen Deployment umzusetzen.

Rollback: der Plan B, den jedes Deployment braucht

So sorgfältig ein Deployment auch vorbereitet ist, ein Rollback-Plan gehört immer dazu – die Möglichkeit, im Fehlerfall zügig zur vorherigen, bekanntermaßen funktionierenden Version zurückzukehren. Ohne diesen Plan wird aus einem an sich kleinen Problem schnell eine längere Störung, weil erst unter Zeitdruck nach einer Lösung gesucht werden muss.

Ein funktionierender Rollback setzt voraus, dass die vorherige Version tatsächlich noch verfügbar ist und dass etwaige Datenbank-Änderungen sich ebenfalls rückgängig machen lassen. Wird dieser Punkt bei der Planung übersehen, bleibt im Ernstfall nur die aufwendige manuelle Fehlersuche live auf der produktiven Seite.

Ein Rollback sollte außerdem regelmäßig tatsächlich geübt werden, nicht nur in der Theorie feststehen. Ein Ablauf, der nur auf dem Papier funktioniert, aber noch nie unter realen Bedingungen ausgeführt wurde, birgt im Ernstfall unangenehme Überraschungen.

Automatisierung vs. manuelles Deployment

Ein manuell durchgeführtes Deployment ist anfällig für genau die Fehler, die unter Zeitdruck am ehesten passieren: ein vergessener Schritt, eine falsche Reihenfolge, eine Datei, die auf dem falschen Server landet. Automatisierte Abläufe führen denselben, vorher getesteten Ablauf jedes Mal identisch aus und schließen damit einen erheblichen Teil menschlicher Fehlerquellen aus.

Das bedeutet nicht, dass jedes kleine Unternehmen eine hochkomplexe Automatisierung braucht. Entscheidend ist, dass der Ablauf – ob automatisiert oder manuell – dokumentiert und wiederholbar ist, statt bei jedem Deployment neu improvisiert zu werden. Wie ein Webprojekt insgesamt strukturiert abläuft, beschreibt der Beitrag Wie läuft ein Webprojekt ab.

Checkliste vor jedem Deployment

Unabhängig vom technischen Verfahren hilft eine feste Routine vor jeder Übertragung auf die Live-Umgebung:

• Neue Version zuvor auf einem separaten Testsystem geprüft
• Datenbank-Änderungen so gestaltet, dass alte und neue Version sie parallel vertragen
• Rollback-Weg konkret bekannt und im Ernstfall sofort ausführbar
• Deployment außerhalb der Hauptnutzungszeit geplant, sofern möglich
• Nach der Übertragung aktiv geprüft, nicht nur angenommen, dass alles funktioniert

Diese Routine kostet wenig Zeit im Vergleich zu den Folgen eines missglückten Deployments, das live und ungeplant korrigiert werden muss.

Wann sich der Aufwand für ausfallfreies Deployment lohnt

Für eine selten geänderte Broschürenwebsite ist ein aufwendiges, mehrstufiges Deployment-Verfahren häufig unverhältnismäßig – ein kurzer, gut vorbereiteter klassischer Ablauf reicht meist aus. Bei Anwendungen mit regelmäßigem Betrieb, Bestellprozess oder internationalem Publikum rund um die Uhr steigt der Nutzen ausfallfreier Verfahren dagegen deutlich, weil jede Downtime unmittelbar Umsatz oder Vertrauen kostet.

Ein realistischer Blick auf die eigene Wartungsroutine, wie sie auch im Beitrag Wartungsvertrag für die Website beschrieben ist, hilft dabei, den passenden Aufwand für das eigene Deployment festzulegen.

Häufige Fragen