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 für die spätere 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:
/programming//q/225772/149060
Beispielsweise verfügt liquidbase über eine Diff-Funktion, die optional auch Änderungen an Daten enthält. Möglicherweise können wir das Schema und den Datenunterschied in einem Skript ausgeben, wobei (soweit möglich) bestimmte Tabellen ausgeschlossen werden, die Testdaten enthalten (z. B. nachträglich usw.), und dann das Skript 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 beide Datenbanken lokal sind und das Ausführen des Tools auf Ihrem PC löst dieses Problem ...
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 des Instrumenting Hooks von @bueltge ansehen, rufen wir das Plugin zur Inspiration auf: https://gist.github.com/1000143 (danke an Ron Rennick über G +, der mich in Richtung SAVEQUERIES und Shutdown Hook geführt hat) führe mich, es zu finden)
- Ändern Sie es, um stattdessen die SAVEQUERIES-Ausgabe zu erhalten
- Nur im Admin-Modus ausführen
- Alle Auswahlen herausfiltern
- Ergebnisse im Shutdown Hook abspeichern
- Wir konnten die Ausgabe-Überfüllung basierend auf dem, was wir gerade machten, selektiv umschalten.
Beispielsweise:
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. Idealerweise ist es 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?