Ein WordPress-Deployment kann mehr verändern als die Dateien einer Version. Ein Plugin-Update oder eine individuelle Entwicklung kann außerdem Tabellen anlegen, Optionen ändern, Datensätze umwandeln oder die Interpretation vorhandener Daten beeinflussen. Befinden sich Code und Datenbank in nicht kompatiblen Zuständen, kann die Website ausfallen, obwohl die Dateikopie vollständig zu sein scheint.
Ein WordPress-Deployment mit Datenbankänderungen zu verwalten, bedeutet, jede Änderung entsprechend ihrer Auswirkungen und Reversibilität zu behandeln. Das Ziel ist nicht nur, Code bereitzustellen: Es geht darum, einen kontrollierten Übergang sicherzustellen, kritische Abläufe zu prüfen und zu wissen, was zu tun ist, wenn die neue Version nicht wie erwartet funktioniert.
Warum das Wiederherstellen von Dateien die Website nicht immer wiederherstellt
Der Code führt Operationen an der Datenbank aus, enthält aber nicht zwangsläufig deren aktuellen Zustand. Wenn eine neue Version eine Tabelle anlegt oder das Format eines Werts ändert, werden diese Änderungen durch die Rückkehr zu den vorherigen Dateien nicht rückgängig gemacht. Der alte Code erkennt möglicherweise das neue Schema nicht, oder die Website hat Daten erhalten, die die vorherige Version nicht verarbeiten kann.
Auch der umgekehrte Fall ist möglich: Wird eine ältere Datenbank eingespielt, während die neuen Dateien beibehalten werden, kann das System in einen inkonsistenten Zustand geraten. Bei WooCommerce können Bestellungen und andere Betriebsdaten beispielsweise während und nach dem Deployment weiter geändert werden. Das Einspielen einer früheren Datenbankkopie könnte legitime Bestellungen und andere Betriebsdaten löschen, die seit der Erstellung dieser Kopie hinzugekommen sind.
Deshalb empfiehlt es sich, zwischen einem Code-Rollback, bei dem die Dateien auf eine frühere Version zurückgesetzt werden, einer Datenkorrektur, bei der konkrete Änderungen berichtigt werden, und dem Einspielen eines Backups zu unterscheiden. Diese Maßnahmen sind nicht gleichwertig und haben weder dieselben Kosten noch dieselben Auswirkungen.
Änderungen und Abhängigkeiten vor der Veröffentlichung erfassen
Dokumentieren Sie vor dem Deployment, was sich ändert und wo es liegt. Eine hilfreiche Liste unterscheidet vier Kategorien:
- Code: Themes, Plugins, individueller Code, geplante Aufgaben und Abhängigkeiten.
- Schema: Tabellen, Spalten, Indizes oder andere Strukturen, die erstellt, geändert oder entfernt werden.
- Daten: Datensätze, die eingefügt, aktualisiert, umgewandelt oder gelöscht werden, einschließlich Optionen und Metadaten.
- Konfiguration und Inhalte: umgebungsspezifische Werte, Zugangsdaten, Regeln, Seiten oder über das Dashboard verwaltete Einstellungen.
Dokumentieren Sie, wer jede Migration ausführt, wann sie ausgeführt wird und ob sie gefahrlos wiederholt werden kann. Prüfen Sie, ob sie beim Aktualisieren eines Plugins automatisch ausgeführt wird oder einen Befehl, einen manuellen Vorgang oder eine administrative Aktion erfordert. Ermitteln Sie auch die Abhängigkeiten: Welche Codeversion benötigt die neue Struktur, und welche Prozesse schreiben in die betroffenen Tabellen?
In WordPress kann ein Teil der Konfiguration in der Datenbank liegen und sich zwischen Produktions- und Testumgebung unterscheiden. Gehen Sie nicht davon aus, dass das Kopieren einer Datenbank von einer Umgebung in eine andere unbedenklich ist. Serialisierte Daten oder als Optionen gespeicherte Werte können zudem eine formatgerechte Umwandlung erfordern und nicht einfach wahllos durch Textersetzung geändert werden.
Eine kompatible und schrittweise Abfolge entwerfen
Wenn die Änderung es zulässt, verwenden Sie eine Expand-and-Contract-Strategie. Fügen Sie zunächst Strukturen hinzu, die mit der aktuellen Version kompatibel sind. Stellen Sie anschließend Code bereit, der sowohl mit dem alten als auch mit dem neuen Zustand arbeiten kann. Migrieren Sie danach die Daten und prüfen Sie das Ergebnis. Erst wenn die neue Version stabil ist, werden nicht mehr benötigte alte Spalten, Pfade oder Strukturen entfernt.
Diese Abfolge verringert das Risiko, dass ein Code-Rollback die Website ohne eine Struktur zurücklässt, die der vorherige Code erwartet. Nicht alle Änderungen lassen sich auf diese Weise umsetzen: Eine destruktive Umwandlung oder eine inkompatible Änderung kann ein Wartungsfenster, eine Sperrung von Schreibvorgängen oder spezifische Schritte des Plugin-Anbieters erfordern. Die Entscheidung hängt von der Operation, dem Datenvolumen, der voraussichtlichen Dauer und der Möglichkeit ab, den Dienst aufrechtzuerhalten.
Vermeiden Sie es, Codeänderungen, Migrationen und irreversible Bereinigungen ohne Kontrollpunkte in einem einzigen Vorgang zusammenzufassen. Dauert eine Aufgabe lange oder schlägt sie mittendrin fehl, muss erkennbar sein, welche Schritte abgeschlossen wurden. Legen Sie fest, wie sie sicher fortgesetzt werden kann, wie doppelte Ausführungen verhindert werden und wer die Fortsetzung genehmigt. Stellen Sie bei schrittweisen Deployments sicher, dass gleichzeitig laufende Versionen mit der gemeinsam genutzten Datenbank arbeiten können.
In einer repräsentativen Umgebung testen
Eine Testumgebung ist dann hilfreich, wenn sie die relevanten Bedingungen abbildet: PHP- und WordPress-Versionen, Plugins, Integrationen, Konfiguration und Datentypen. Sie muss nicht alle echten Daten kopieren, sollte aber Tests der betroffenen Abläufe ermöglichen. Wenn Sie Produktionsdaten verwenden, schützen Sie personenbezogene Informationen und beschränken Sie den Zugriff; eine Kopie muss mit denselben Vorsichtsmaßnahmen wie die Quelle behandelt werden.
Führen Sie die Migration probeweise aus und messen Sie ihre Dauer mit einer hinreichend repräsentativen Datenmenge. Prüfen Sie, was bei einer Unterbrechung geschieht und ob die Migration ohne doppelte Datensätze oder Datenverlust wiederholt werden kann. Prüfen Sie anschließend mindestens das Lesen und Schreiben der betroffenen Daten sowie die relevanten Geschäftsabläufe: Kauf, Zahlung, Bestätigung, Bestellverwaltung oder Synchronisierung mit externen Systemen, je nach Anwendungsfall.
Beziehen Sie Kompatibilitäts- und Berechtigungstests, geplante Aufgaben sowie Integrationsfehler ein. Eine ladende Startseite beweist nicht, dass der Kaufprozess funktioniert. Wenn sich eine Integration in der Testumgebung nicht nachbilden lässt, legen Sie eine alternative Prüfung fest und bestimmen Sie, wer sie nach der Veröffentlichung durchführt.
Signale nach dem Deployment festlegen
Legen Sie vor dem Start fest, woran sich ein erfolgreiches Deployment erkennen lässt und wie lange es beobachtet wird. Die Signale müssen den ermittelten Risiken entsprechen und dürfen sich nicht darauf beschränken, zu prüfen, ob der Server antwortet. Dazu können gehören:
- PHP-Fehler, Anwendungsprotokolle und Fehler bei geplanten Aufgaben.
- Migrationsergebnisse: erwartete Struktur, Anzahl oder Konsistenz der betroffenen Datensätze.
- Lese- und Schreibvorgänge sowie die Ausführung kritischer Abläufe.
- Status von Zahlungen, Webhooks, Synchronisierungen und anderen beteiligten Integrationen.
- Übliche Geschäftskennzahlen, verglichen mit dem in diesem Kontext erwarteten Verhalten.
Weisen Sie Verantwortliche zu, die diese Signale prüfen und Schwellenwerte für eine Pause oder einen Code-Rollback festlegen. Wenn die Zahl der Fehler steigt, ermitteln Sie zunächst, ob sie die Anwendung, die Integration oder die Daten betreffen. Ein Alarm ohne festgelegtes Reaktionsverfahren reicht nicht aus, um das Risiko zu kontrollieren.
Die Wiederherstellung vorbereiten und über die Freigabe entscheiden
Der Plan muss festlegen, was sicher zurückgesetzt werden kann und was eine Korrektur oder das Einspielen eines Backups erfordert. Vergewissern Sie sich, dass Backups vorhanden sind und sich einspielen lassen; ein nicht getestetes Backup ist keine Betriebsgarantie. Legen Sie den Wiederherstellungspunkt, die Abhängigkeiten des Verfahrens und die Auswirkungen des Verwerfens legitimer Änderungen fest, die nach der Erstellung des Backups vorgenommen wurden. Prüfen Sie bei einem aktiven Shop, wie sich Bestellungen und weitere Betriebsdaten sichern lassen, die während des Eingriffs eingehen.
Vereinbaren Sie vor der Veröffentlichung, wer entscheidet, wer den Vorgang ausführt und wer das Ergebnis prüft. Geben Sie das Deployment nur frei, wenn die Migration erprobt wurde, die Abhängigkeiten bekannt sind, Verantwortliche für die Prüfungen feststehen und die Wiederherstellung möglich ist. Pausieren Sie, wenn Zweifel an der Kompatibilität zwischen Versionen bestehen, ein kritischer Test fehlschlägt oder der laufende Betrieb nicht geschützt werden kann. Führen Sie einen Code-Rollback durch, wenn dies ausreicht, um die Kompatibilität wiederherzustellen; korrigieren Sie Daten, wenn sich das Problem eingrenzen lässt; spielen Sie ein Backup nur ein, wenn bekannt ist, welche späteren Änderungen dadurch verloren gehen könnten.
Checkliste für die Deployment-Freigabe: vollständiges Inventar; verifiziertes Backup; festgelegte Abfolge und Wartungsfenster; bestandene Tests; zugewiesene Signale und Verantwortliche; sowie klare Kriterien für Fortsetzung, Pause oder Wiederherstellung. Diese Disziplin macht eine Datenbankänderung zu einem kontrollierten Vorgang statt zu einer Wette darauf, dass die alten Dateien ausreichen.
