it-swarm.com.de

Wordpress-Datenbanksynchronisation zwischen dev und prod

Es wurde bereits eine Frage zum Synchronisieren von Dateien und der Datenbank zwischen zwei Wordpress-Installationen gestellt.

Auf Datenbankebene lautet die Antwort in der Regel, eine Datenbank zu sichern und auf einem anderen Server einzufügen. Das Problem dabei ist, dass Sie am Ende alle Änderungen verlieren, die möglicherweise auf dem Prod-Server vorgenommen wurden. Zum Beispiel Nutzungsmetriken, Kommentare usw.

Vor diesem Hintergrund begann ich mich zu fragen, ob es möglich sein würde, den Wordpress-ORM so zu erweitern, dass Sie Deltas generieren und diese dann in die Prod-Site injizieren können.

Hat jemand dies ausprobiert, sich damit befasst oder hat er Ideen oder Kommentare?

18

Die Realität sieht so aus: http://www.liquibase.org/

Liquibase ist eine datenbankunabhängige Open Source-Bibliothek (Apache 2.0 Licensed) zum Nachverfolgen, Verwalten und Anwenden von Datenbankänderungen. Es basiert auf einer einfachen Prämisse: Alle Datenbankänderungen werden in einer für den Menschen lesbaren und dennoch verfolgbaren Form gespeichert und in die Quellcodeverwaltung eingecheckt.

Unser Entwicklungsprozess unterstützt dies jedoch nicht. Normalerweise ändern wir die Datenbank nicht über eigens erstellte Skripte, sondern verwenden Plugins, die wir aktivieren. Wir schreiben keine DML-Skripte, um Suchdaten zu ändern, die wir dann in die Quellcodeverwaltung einchecken. Wir verwenden eine Benutzeroberfläche auf der Administrationsseite und haben daher keinen Quellcode zur späteren Verwendung beim Replizieren dieser Änderung während der Migration.

Wir können jedoch einige davon emulieren, indem wir einige der auf dieser Seite aufgelisteten Tools verwenden:

https://stackoverflow.com/q/225772/149060

Beispielsweise verfügt liquidbase über eine Diff-Funktion, die optional auch Änderungen an Daten enthält. Möglicherweise könnten wir das Schema und den Datenunterschied in einem Skript ausgeben und (soweit möglich) bestimmte Tabellen ausschließen, die wahrscheinlich Testdaten enthalten (z. B. nachträglich usw.), und das Skript dann auf die Produktionsdatenbank anwenden.

MySQLDiff (auf der StackOverflow-Frage besprochen) führt Schemaunterschiede durch, und sein Autor empfiehlt mysql_coldiff für tabellenweise Datenunterschiede - beide sind in Perl implementiert, wenn Java-Tools (liquidbase) für Ihre Server zu ressourcenintensiv sind - obwohl Bringen Sie beide Datenbanken lokal und führen Sie das Tool auf Ihrem PC aus.

Wenn wir es wirklich richtig machen wollen, sollten wir alle SQL-Anweisungen protokollieren, die sich auf Einstellungen, Optionen oder andere Konfigurationsänderungen sowie auf Schemaänderungen beziehen - und den protokollierten Code in ein Migrationsskript konvertieren, um gegen unseren Produktionsserver zu spielen. Spielen Sie das Migrationsskript gegen den Server, kopieren Sie die WordPress-Site-Dateien (ggf. ohne Uploads) und wir sind goldrichtig.

Daher scheint es mir, dass der beste Ausweg das Migrations-Builder-Plugin eines Entwicklers ist, das den von uns benötigten SQL-Code abfängt, speichert und dann ein Migrationsskript aus dem protokollierten Code generiert, anstatt eine Möglichkeit zum Zusammenführen von Datenbanken zu erstellen zwischen Inszenierung und Produktion. Scheint auch ein einfacheres Problem zu lösen.

Wenn wir uns den Code von @bueltges Instrumenting Hooks ansehen, rufen wir das Plugin zur Inspiration auf: https://Gist.github.com/1000143 (Vielen Dank an Ron Rennick über G +, der mich in Richtung SAVEQUERIES und das Abschalthaken, der mich dazu führte, es zu finden)

 - Ändern Sie diese Option, um stattdessen die SAVEQUERIES-Ausgabe zu erhalten. 
 - Nur im Administratormodus ausführen. 
 - Alle ausgewählten Elemente herausfiltern. 
 - Ergebnisse in Tabelle speichern im Shutdown-Hook 
 - konnten wir die Ausgabe-Überfüllung basierend auf dem, was wir gerade machten, selektiv umschalten. 

Zum Beispiel:

Capture Name: Aktiviere und konfiguriere das Plugin XYZ

Capture State Toggle - Ein

... Plugin XYZ installieren und konfigurieren

Capture State Toggle - Aus

Export Migrationsskript für: Plugin XYZ aktivieren & konfigurieren

Drücken Sie die Export-Taste, um ein Popup-Textfeld mit dem gefilterten SQL-Code zu erstellen. Diese Funktion ist idealerweise als Shell-Skript mit Befehlszeilenaufruf an mysql vorformatiert. Kopieren Sie es in Ihren Migrationscode-Ordner und fügen Sie es Ihrem Quellcode-Repository hinzu.

Wenn Sie die Erfassung während der Arbeit ein- und ausschalten, können Sie das perfekte Migrationsskript generieren, um Ihre Produktionsdatenbank in eine der Staging-Datenbank entsprechende Konfiguration zu bringen.

Was ist besser, haben Sie ein Skript (oder eine Reihe von gleichen), die Sie testen können. Imaging mit replizierbaren, testbaren Migrationsskripten !!

Ich bin schon verliebt.

Irgendjemand anderes?

11
marfarma

DasDatabase Sync WordPress-Plugin erledigt einen großartigen Job beim Synchronisieren von Daten zwischen zwei Servern.

Standardmäßig werden ALLE Zieldaten überschrieben, es wurden jedoch einige Verbesserungen am Plugin vorgenommen, mit denen Sie nur bestimmte Datenbanktabellen synchronisieren können. Dies kann Ihnen helfen, Kommentare, Benutzer und andere solche Daten, die Sie nicht überschreiben möchten, beizubehalten. Gibt Ihnen das die Granularität, die Sie benötigen?

Ich habe meine Änderungen noch nicht veröffentlicht, aber wenn Sie an einer Kopie interessiert sind, senden Sie mir eine E-Mail an simon-at-yump.com.au. Wenn jemand dies nützlich findet oder zusätzliche Funktionsanforderungen hat, lass es mich wissen und ich werde sehen, was ich tun kann.


UPDATE: Ich habe auch gerade das WP-Sync-DB gefunden Plugin, das eine Abzweigung des kommerziellen WP-Migrate-DB-Pro ist Plugin. Es macht eine sehr ähnliche Sache, obwohl es wahrscheinlich mehr Polnisch als Database Sync hat.

3
Simon East

Speziell für diese Aufgabe gibt es einen relativ neuen kommerziellen Dienst. Es heißt RAMP:

http://alexking.org/blog/2011/07/20/ramp-content-deploy-wordpress

0
scribu