Updates richtig planen: Staging, Testprotokoll und Rollback

Das Einspielen von Updates gilt als Routineaufgabe, die man nebenbei erledigt. Genau diese Einschätzung ist die Ursache der meisten längeren Ausfälle, die wir in Bestandsaufnahmen finden. Ein Update ist kein Klick, sondern eine Änderung am Produktivsystem — und jede Änderung am Produktivsystem braucht einen Testpfad und einen Rückweg.

Warum Updates überhaupt etwas zerstören

In den seltensten Fällen ist das Update selbst fehlerhaft. Die Ursache liegt fast immer in individuellen Anpassungen. Ein Entwickler hat vor drei Jahren eine Funktion überschrieben, weil das Plugin damals keine passende Schnittstelle bot. Das Update ändert genau diese Funktion, die Anpassung greift ins Leere, und der Fehler zeigt sich nicht auf der Startseite, sondern im Bestellabschluss.

Ein zweiter häufiger Auslöser sind Versionsabhängigkeiten. Ein Plugin setzt eine neuere PHP-Version voraus, als der Server bereitstellt, oder zwei Erweiterungen verlangen unterschiedliche Versionen derselben Bibliothek. Solche Konflikte lassen sich vorab erkennen — aber nur, wenn man vorher nachsieht.

Der Ablauf, den wir verwenden

Wichtig sind die Abbruchkriterien. Ohne sie entsteht in der Praxis Druck, ein Update trotz auffälliger Testergebnisse durchzuziehen, weil der Termin steht. Ein definiertes Abbruchkriterium nimmt diese Entscheidung aus der Situation heraus und verlagert sie in den Prozess.

Was in ein Testprotokoll gehört

Ein brauchbares Testprotokoll ist kurz und geschäftsspezifisch. Es prüft die Pfade, deren Ausfall tatsächlich weh tut. Für eine Unternehmenswebsite sind das typischerweise: Startseite und drei zufällige Unterseiten laden, Kontaktformular absenden und Zustellung im Postfach bestätigen, Suche mit einem bekannten Begriff, Login in den geschützten Bereich, Darstellung auf einem Mobilgerät prüfen.

Für einen Shop kommen hinzu: Produkt in den Warenkorb legen, Gutscheincode anwenden, Versandkostenberechnung prüfen, Testbestellung im Sandbox-Modus des Zahlungsanbieters abschließen, Bestellbestätigung im Postfach kontrollieren und die Bestellung im Backend sehen. Dieses Protokoll wird einmal erstellt und dann bei jedem Update abgearbeitet — als Liste, nicht aus dem Gedächtnis.

Rollback ist eine Entscheidung, keine Rettungsaktion

Vor jedem Produktiv-Deployment erzeugen wir einen vollständigen Snapshot aus Dateisystem und Datenbank und notieren den Zeitstempel als Rollback-Punkt. Tritt nach dem Deployment ein Problem auf, ist die Rückkehr eine bewusste Entscheidung innerhalb weniger Minuten — nicht der Versuch, unter Zeitdruck einen Fehler zu debuggen, während Kunden anrufen.

Ein Sonderfall verdient Beachtung: Datenbankmigrationen. Manche Updates verändern die Datenstruktur unumkehrbar. In diesen Fällen bedeutet ein Rollback auch das Zurücksetzen der Datenbank — und damit den Verlust aller Daten, die seit dem Snapshot entstanden sind. Solche Updates legen wir deshalb in Zeitfenster mit geringem Aufkommen und kündigen sie an.

Automatische Updates: Ja, aber differenziert

Automatische Aktualisierungen sind nicht grundsätzlich falsch. Für Sicherheitsupdates des Systemkerns sind sie sinnvoll, weil Geschwindigkeit hier wichtiger ist als Kontrolle. Für Plugin-Hauptversionen sind sie riskant, weil genau dort Breaking Changes auftreten. Wir konfigurieren daher differenziert: Kern-Sicherheitsupdates automatisch, Nebenversionen von Erweiterungen automatisch mit anschließender Prüfung, Hauptversionen ausschließlich manuell über Staging.

Dieser Ablauf ist Bestandteil unserer laufenden Website-Wartung. Für mobile Anwendungen gilt eine eigene Systematik, weil dort zusätzlich Store-Freigaben und parallel laufende Versionsstände auf Kundengeräten zu berücksichtigen sind — beschrieben unter App Maintenance und Release-Support.