it-swarm.com.de

Staging-Sites, wie verwalten Sie die Synchronisierung von Aktualisierungen in der Datenbank?

Es ist allgemein anerkannt, dass Entwickler Updates über eine Staging-Site testen sollten, bevor sie auf dem Live-Server veröffentlicht werden. Wenn die Entwicklungsupdates jedoch Änderungen in Wordpress DB erfordern, werden die Dinge kompliziert, da Benutzer auf der Live-Site auch die DB aktualisieren.

Der einzige (durcheinandergebrachte) Fluss, den ich mir vorstellen kann, ist der folgende:

  1. Test auf einem lokalen Server (WAMP, XAMP usw.)
  2. Versetzen Sie die Live-Site nach der Bereitstellung in den Wartungsmodus
  3. Live-Site sichern (Duplicator, sqldump usw.)
  4. Erstellen Sie einen Klon der gesperrten Live-Site für die Staging-Site
  5. Laden Sie Änderungen aus der lokalen Umgebung auf die Staging-Site hoch
  6. Testen Sie die Staging-Site
  7. Schieben Sie die Staging-Site zum Leben.
  8. Wartungsmodus entfernen

Nachteile des obigen Ablaufs:

  • die Ausfallzeiten können für Benutzer länger als erwartet sein, während der Entwickler die Updates auf der Staging-Site sorgfältig testet.
  • möglicherweise ist eine manuelle Verwaltung von Änderungen erforderlich: Beispielsweise werden Siteorigin-Pagebuilder-Layouts in der Datenbank gespeichert. Wenn ein Layout geändert wurde, muss es manuell in die Staging-Site importiert werden. In diesem Fall kann es ausreichend sein, Seiten einfach in die Staging-Site zu importieren und zu löschen und, falls dies funktioniert, in die Live-Site zu importieren

Ich frage mich, ob es einen besseren und automatisierten Weg gibt, dies zu erreichen.

Was denkst du?

EDIT, wie angefordert, einige Lösungen wurden in der Vergangenheit vorgeschlagen, aber keine bietet eine endgültige Lösung:

8
Riccardo

Neuere Hosting-Anbieter, die speziell auf WordPress zugeschnitten sind, verfügen in der Regel über Tools, um diesen Schmerz zu lindern. Ich setze meine Kunden auf Pantheon, das diesen ordentlichen, Git-fähigen Workflow hat, bei dem Code nur nach oben (von dev zu staging zu production) und DB-Sachen nur nach unten (umgekehrt zum Code) verschoben werden. Das Kopieren einer Datenbank von der Produktion zum Staging erfolgt mit einem Klick über die Benutzeroberfläche. Vorausgesetzt, dass dieser Workflow eingehalten wird, entfällt das Problem, dass die Produktionsdatenbank ständig durcheinander gebracht wird, und ich kann meine Änderungen in beiden Entwicklungsphasen immer auf einem neuen Klon der Produktionsdatenbank testen.

Man muss Pantheon nicht verwenden - Sie können einen ähnlichen Ansatz in Ihrem Prozess mit Ihren eigenen Tools anwenden (Git + ein DB-Klon-Plugin wie WP Migrate DB). Ich finde nur, dass dieser Weg für mich gut funktioniert.

Frage: Warum sollten Sie Ihre Produktionsstätte während der Testphase in den Wartungsmodus versetzen? In den meisten Fällen sollte dies nicht erforderlich sein. Der einzige Fall, den ich mir vorstellen kann, ist ein sehr sprödes System, das sehr empfindlich auf das Einspeisen zusätzlicher Benutzerdaten reagiert, mit einem katastrophalen Fehler beim Booten - aber das würde wahrscheinlich auf ein anderes, größeres Problem hinweisen, das benötigt würde die gesamte Architektur ihres Produkts zu überdenken.

2
montrealist

Schauen Sie sich VersionPress an, das die GIT-Versionierung auf den gesamten Prozess (Dateien und Datenbank) überträgt.

Wie auf ihrer Website beschrieben:

VersionPress bietet schmerzlose Inszenierung . Dies bedeutet, dass Sie auf einfache Weise eine sichere Testumgebung für Ihre Änderungen erstellen und diese erst dann wieder zusammenführen können, wenn sie fertig sind. Zusammenführen ist hier das Schlüsselwort - VersionPress verarbeitet Situationen, in denen Ihre Live-Site in der Zwischenzeit nahtlos neue Inhalte enthielt.

1
marekeiba