it-swarm.com.de

Datenbanksynchronisation zwischen Entwicklung/Staging und Produktion

Ich habe ein Problem mit der Synchronisation der WordPress-Datenbank zwischen Entwicklung und Produktion und frage mich, wie andere Leute es lösen. Ich kenne diese Frage , aber es geht nicht wirklich um den fieseren und realistischeren Anwendungsfall.

Angenommen, ich habe eine WordPress-Website. Ich habe einen Dump von allem genommen und ihn in unserer Entwicklungsumgebung repliziert. Ich fing an, Änderungen vorzunehmen. 1 Woche später kann ich meine Updates bereitstellen. In der Zwischenzeit hat sich die Datenbank am Produktionsstandort geändert (neue Beiträge, neue Kommentare usw.). Wie synchronisiere ich Änderungen zwischen Produktion und Entwicklung während des Rollouts und ist es möglich, diesen Prozess (zumindest teilweise) zu automatisieren?

34
Alex

Es mag einen besseren Weg geben, den ich vermisse, aber ich werde Ihnen zwei Möglichkeiten geben:

1.Verwenden Sie XML Export, um Ihre neuen Posts und Kommentare zu exportieren. Verwenden Sie dann den WordPress-Importer , um die neuen Posts und Kommentare zurück in die Entwicklerdatenbank zu importieren

Es ist am besten, die Datenbank in dev zu importieren und dann in die Produktion zu verschieben, da beim Import alle neuen Mediendateien aus der Produktion heruntergeladen werden.

In der Zwischenzeit hat sich die Produktion geändert (neue Beiträge, neue Kommentare usw.)

Dies würde Ihr Problem lösen, etwaige geänderte Inhalte einzubringen.

2. Verwenden Sie den Befehl INSERT IGNORE INTO MySql, um die neuen Tabellen von dev hinzuzufügen. oder den Befehl REPLACE , um doppelte Zeilen in derselben Tabelle zu überschreiben.

Erstellen Sie vor der Verwendung von MySql eine Sicherungskopie beider Datenbanken und verschieben Sie die gz-Datenbank auf den Produktionsserver und laden Sie den Dump hoch (ändern Sie den Namen von dev, wenn er mit production identisch ist.

INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`

Ich bin nicht mit MySQL-Befehlen vertraut, daher würde ich Option 1 wählen.

9
Chris_O

Wenn es sich nur um genau denselben Datentyp handelt (einige neue Blogposts, neue Kommentare), bin ich mir nicht sicher, warum Sie ihn wirklich synchronisieren müssen. Es ist nicht so, dass es die Art und Weise ändert, wie der Code auf der Site funktioniert, da er nur mehr der gleichen ist. Ich mache mir normalerweise keine Sorgen, es sei denn, es handelt sich um einen neuen Datentyp.

Ich stelle nur immer sicher, dass ich ein gutes Beispiel der Daten für die Site habe, nicht für jeden Beitrag, jede Seite und jeden Kommentar von der Live-Site.

2
curtismchale

Ich habe gerade einen Beitrag darüber verfasst, wie ich Produktionsdaten mit unserer Inszenierung synchronisiere. Lesen Sie dazu meinen Blog-Beitrag unter: http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite -Datenbank-von-Produktion-zu-Inszenierung-Umgebung/

Wenn Sie den Code und andere Dinge auch synchronisieren möchten, würde ich empfehlen, ein Git- oder Mercurial-Repository mit der entsprechenden Ignorierdatei zu erstellen.

Wenn Sie differenzielle Aktualisierungen von Staging vornehmen möchten, ist die Erstellung von Migrationsskripten der sicherste und beste Weg.

1
Niklas

Sobald Sie das Thema Änderungen parallel berühren, berühren Sie den Bereich Konfigurationsmanagement. Mit vielen Mustern, eigenen Communities (http://www.cmcrossroads.com/) und Tools nicht so sehr für das Versionsmanagement (wie svn/git), sondern für die Unterstützung des Konfigurationsmanagements (Patterns) wie Clearcase. (ganz andere Bereiche).

In diesem Fall ist es immer noch eine einfache Situation und Sie werden feststellen, dass es mit einigen Einschränkungen und einigen manuellen Arbeiten und einigen Listen funktioniert.

Das Szenario, über das ich nachdenke, um die ideale Lösung besser beschreiben zu können: mehrere Entwickler, die an derselben Codebasis arbeiten, mehrere Testumgebungen, mehrere Akzeptanzumgebungen, mehrere Produktionsakzeptanzumgebungen, möglicherweise in allen Teilen der Welt.

Wenn Sie dies ein bisschen professioneller machen möchten:

a) Notieren Sie sich eine Liste aller Konfigurationselemente, auf die Sie stoßen. Dies kann der WordPress-Code selbst sein, Plugins von externen Stellen, Inhalte, Metadaten und entscheiden, welche davon Sie einer Art "Verwaltung" unterziehen möchten, um welche es sich handelt.

b) Beschreiben Sie die Workflows, die z. Was passiert mit einem Fix, was passiert mit etwas Neuem in der Entwicklung, in welchem ​​Fall ändern Sie Inhalte auf Ihrer Seite, wie heißt das und wer macht das, wer ist der Eigentümer davon, z. einen neuen Beitrag oder ein neues Plugin.

c) Beschreiben Sie beim parallelen Arbeiten zunächst, welche CIs Sie verwalten möchten, und entscheiden Sie, ob der Fluss immer von der Entwicklung bis zur Produktion reicht oder ob er wirklich auf zwei Arten durchgeführt werden muss.

d) Schreiben Sie für jeden der CI-Typen unter (a) eine Auflösung. Z.B. für ALLES, was Text ist (oder exportierten Text wie PHP-Dateien, aber AUCH reinen Text in XML-Dateien), ist das Zusammenführen möglich. Dies ist wirklich kein Problem, aber Sie benötigen ein gutes Merge-Tool. z.B. Mit ClearCase würden Sie auf dreifache Weise die folgenden Situationen zusammenführen: 1) Trivial Merges: Diese werden automatisch durchgeführt. 2) Nicht-Trivial-Automatic: Diese werden automatisch durchgeführt. ABER Sie müssen dies überprüfen. 3) Nicht-Trivial-Non-Automatic: Dies ist ein Konflikt zB In einer Zeile wurden mehrere Änderungen vorgenommen. Die Nicht-Trivials sind der minimale Teil, den Sie manuell bearbeiten müssen. Ein gutes Zusammenführungs-Tool führt Sie z. die in Klartext (die auch das Zusammenführen von Word ermöglicht und in der Sie andere kommerzielle oder nichtkommerzielle Zusammenschlüsse für bestimmte Dateitypen verknüpfen können). Wenn Sie unter (a) Dateien identifiziert haben, die nur kopiert werden sollen, besteht ihr Verhalten darin, dass sie nicht zusammengeführt werden, sondern nur so kopiert werden, dass die andere Version ohne Zusammenführung überschrieben wird (z. B. Plugins, die Sie nicht geändert haben). Viele dieser Typen sind mit unterschiedlichem Verhalten möglich. Aber schreiben Sie die Beziehungen zwischen CIs auf,

Dann müssen Sie für die nicht textbasierten Zusammenführungen eine Entscheidung treffen, wie sie behandelt werden sollen, z. Bilder, die an 2 Stellen geändert wurden. Sie könnten hier entscheiden, dass die Produktion immer Vorrang hat (zumindest denke ich das), was es einfach macht.

Um dieses Problem zu lösen, benötigen Sie ein Versionsverwaltungstool, das verschiedene Streams unterstützt. Jeder Strom würde einen Teil darstellen. (Dies kann sehr komplex sein, je nach Ihren Bedürfnissen, aber in diesem Fall denke ich, dass es sehr einfach ist).

Wenn Sie es jetzt schaffen, diese Streams unter Ihren WordPress-Installationen zu haben und sie auch mit dem Inhalt der Datenbank usw. zu synchronisieren, können Sie die Zusammenführungen im CM/Versionierungs-Tool ausführen und dann wieder in die andere Umgebung exportieren.

Die Sache ist ... Sie müssen dies zuerst aufschreiben. Dies ist kein technischer Hack. Es ist ein Standardmuster für das Konfigurationsmanagement, daher ist es auch hier nichts Seltsames, aber Sie müssen es aufschreiben. Sie könnten z.B. dass ein installiertes Plugin Änderungen an der Datenbank mit Daten vornimmt, die sich in einer anderen Umgebung unterscheiden, sodass Sie eine zusätzliche Prozedur benötigen.

Technisch ist fast immer alles möglich. Suchen Sie nach http://www.cmcrossroads.com/forums Szenarien, die Dutzende oder Hunderte Male komplexer sind, aber immer denselben Ansatz und dieselbe Menge von CM-Mustern verwenden.

kurz gesagt: Legen Sie eine Versionsverwaltungsebene darunter, automatisieren Sie die Zusammenführungen und behandeln Sie die Konflikte, und importieren Sie sie dann in die Zielumgebung. Überlegen Sie sich eine Stream-Strategie, die hier passt, und schreiben Sie sie auf. Führe ein kleines bisschen CM-Management durch. Das wäre die professionelle Lösung, ansonsten installiere ein paar db copy hack, scripts etc ...

1
edelwater