Halten Sie die WP-Datenbank mit git über mehrere Entwickler hinweg synchron

Ich arbeite daran, meinen Git-Workflow für meine WordPress-Entwicklungsprojekte zu verbessern. Oft erstelle ich bei der Entwicklung eines Content-Management-Systems einen Entwicklungsserver (wie http://dev.finalsitename.com), der die benutzerdefinierten Beitragstypen und Taxonomien enthält, die in der Produktionsversion verwendet werden. Dadurch kann mein Kunde beginnen, Inhalte zur Site hinzuzufügen.

Während sie an dieser Aufgabe arbeiten, baue ich in der Regel das Aussehen und Verhalten sowie die benutzerdefinierten Programme / Plugins auf, die in meiner lokalen Host-Umgebung verwendet werden. Um sicherzustellen, dass ich ihre Updates nicht überschreibe, ziehe ich im Allgemeinen eine Kopie ihrer Datenbank nach unten und ersetze meine. Es gibt jedoch Zeiten, in denen ich einfach in den WP-Administrationsbereich springen und eine Einstellung oder etwas anderes Kleines ändern muss ...

Wenn mehrere Entwickler an einem WordPress-Projekt arbeiten, führen wir jeweils einen (zeitgestempelten) Datenbank-Dump unserer Site-Version durch und fügen ihn in das Stammverzeichnis ein, bevor wir den lokalen Zweig in das Remote-Repository übertragen. Das Problem bei diesem Ansatz besteht darin, dass die Datenbanken häufig nicht synchron sind und nicht auf einfache Weise ermittelt werden kann, welche Datenbanken verwendet werden sollen.

Was tun andere Entwickler, um ihre Datenbanken synchron zu halten und gleichzeitig mehreren Entwicklern (und Kunden / Inhaltsproduzenten) die Möglichkeit zu geben, an demselben Projekt zu arbeiten?

Es gibt 3 Möglichkeiten von am einfachsten ->

1. Verwenden Sie nur eine entfernte Datenbank, mit der Sie alle eine Verbindung mit vielen Sicherungen herstellen. Auf diese Weise müssen Sie sich nur um Dateien und nicht um die Datenbank kümmern.

2. Verwenden Sie die in WordPress integrierte Import- und Exportfunktion und legen Sie sie in Ihrer Versionskontrolle direkt im WP-Stammverzeichnis ab (wie in einem neuen Ordner). Natürlich dauert es ein paar Minuten länger, aber es ist denkbar einfach und Sie können es automatisieren, aber was noch wichtiger ist, es wird Teil der Versionskontrolle.

3. Verwenden Sie ein benutzerdefiniertes Aktualisierungsskript, um die tatsächliche Datenbanksynchronisierung zu versionieren. Ich weiß ehrlich gesagt nicht, wie man das mit git machen kann, weil es nur ein Skript ist und nicht wirklich weiß, was los ist . liquibase.org/ ).

Wenn Sie die Datenbanken vollständig synchron halten müssen, z. Schema und Daten können Sie ein benutzerdefiniertes Versionsverwaltungssystem entwickeln, das auf Sicherungen basiert.

Wenn Sie die Daten aus der Produktion entfernen möchten, aber das Schema weiterentwickeln möchten, arbeiten Sie möglicherweise mit einer benutzerdefinierten Lösung (einer versionierten Datei mit allen Schemaänderungen) oder mit einer Standardlösung, die auf dem Konzept von basiert migration. In diesem Stackoverflow-Thread finden Sie viele Informationen: Mechanismen zum Nachverfolgen von DB-Schemaänderungen .

Es tut mir leid, wenn dies unglaublich offensichtlich erscheint, aber wenn Sie alle dieselbe Kopie der Datenbank mit derselben Struktur benötigen, ist es dann nicht sinnvoll, einen Office- / zentralen SQL-Server zu haben und diesen zu verwenden? Klonen Sie es lokal, wenn Sie experimentieren müssen, aber behalten Sie es als autorisierenden Defacto-Standard bei und sichern Sie diesen Server und nur diesen Server.

Ansonsten, wenn ich an einem Gruppenprojekt arbeite, haben wir unsere eigenen Setups mit unterschiedlichen Inhalten. Der Code übernimmt das Aktualisieren und Migrieren von Tabellenstrukturen, und wir können über das LAN auf alle lokalen Installationen des Codes zugreifen, der auf unseren Computern ausgeführt wird. Daher müssen wir keine Inhalte freigeben.

Wenn wir Inhalte eingeben, führen wir sie auf einem Testserver aus, den wir entweder exportieren und in den Live-Server importieren oder direkt auf den Produktionsserver migrieren können, wenn derzeit keine Live-Instanz vorhanden ist.

Wenn Sie zu irgendeinem Zeitpunkt eine Trennung von Live-Test- und WIP-Daten benötigen, verwenden Sie einfach einen Live-, Test- und Entwicklungszweig in Ihrem Repository