web-dev-qa-db-de.com

Mehrere Entwickler/Redakteure arbeiten an einer Site in Bearbeitung

Hintergrund

Ich stehe kurz vor der Fertigstellung meiner ersten ziemlich großen WordPress-Site und stoße jetzt auf einige Probleme. Die Site wurde größtenteils auf meinem lokalen Computer entwickelt, und ich habe Änderungen zur Überprüfung auf einen Staging-Server übertragen ( . Weitere Informationen zu dieser Frage finden Sie unter . ). Die Lösung, mit der ich letztendlich fertig war, hat ganz gut funktioniert, als ich nur den Inhalt bearbeitete, aber jetzt bearbeiten einige andere Leute den Inhalt, während ich noch Funktionen zum Hinzufügen habe. Die Idee war: Wir könnten die Dinge schneller erledigen, wenn die Features und der Inhalt in einem Konzert zusammenkommen ... aber jetzt bin ich mir nicht so sicher.

Derzeit befinden sich auf dem Staging-Server andere Inhalte in der Datenbank als auf meinem lokalen Computer. Das ist an sich in Ordnung, da ich auf meinem lokalen Rechner keine endgültige Body-Kopie benötige, aber mehr Entwicklungsarbeiten durchführen muss, die sich auf die Datenbank auswirken (installieren/schreiben Sie ein paar weitere Plugins, die ihre eigenen Tabellen benötigen).

Meine Frage ist:

Gibt es eine einfache Möglichkeit, das Zusammenführen von Datenbanken zu automatisieren, damit mehrere Personen an einer WordPress-Installation arbeiten können? Ich könnte natürlich einfach die Tabellen exportieren, von denen ich weiß , dass sie sich auf meinem lokalen Computer geändert haben , und sie auf den Staging-Server übertragen, aber es ist möglich, dass sich auch Dinge auf dem Staging-Server befinden würde gerne runter bringen. Ich könnte die SQL-Ausgabe beider DBs abrufen und sie unterscheiden ... aber das scheint mühsam und hackisch zu sein. Ich frage mich, ob dies ein Problem ist, das andere gelöst haben. wenn es eine von der Community akzeptierte Möglichkeit gibt, mit solchen Dingen umzugehen.

Vielen Dank!

28
Gavin Anderegg

Ich habe diese Frage vor über einem Jahr gestellt. In dieser Zeit haben wir mehr Leute in unser Team aufgenommen und eine viel größere Anzahl von Websites in WordPress entwickelt. Ich wollte unseren Prozess durchgehen, falls es jemand anderem helfen könnte.

Alles in Git

Das war etwas, was ich getan habe, als ich die Frage gestellt habe, aber es ist gut, diesen Punkt hervorzuheben. Die Verwendung von Git hat uns nicht nur geholfen, produktiver zu werden, sondern es hat auch mehrmals unsere kollektiven Ärsche gerettet.

Mussten Sie jemals größere bauliche Renovierungen an einem Standort vornehmen, die Genehmigung für diese Renovierungen von einem Kunden einholen und gleichzeitig kleinere Aktualisierungen an der nicht renovierten Version vornehmen? Wir haben es und Git lässt es uns tun. Das Beschreiben dieses Setups würde etwas langwierig werden, aber die Grundlagen sind, dass wir einen neuen Zweig erstellt, diesen Zweig auf den Server gezogen und eine Unterdomäne an diesen Zweig angehängt haben.

Wir wurden auch von Git gerettet. Es erlaubt uns natürlich, Änderungen rückgängig zu machen, was großartig ist, aber es erlaubt uns auch, alte Versionen von Dateien zurückzubringen. Das heißt, wenn ein Kunde fragt: "Erinnern Sie sich, wie dieser Teil der Website vor etwa einem Jahr funktioniert hat? Können wir ihn zurückholen?", Lautet die Antwort "Ja" - auch wenn die befragte Person nicht ein Jahr lang an diesem Projekt teilgenommen hat vor.

Abgesehen von diesen Punkten bedeutet dies auch, dass wir nie ohne die benötigten Dateien stecken bleiben. Wir können jederzeit die neueste Version der Site von jedem Computer herunterladen und Änderungen vornehmen.

Verwenden Sie Git zum Bereitstellen

Wir machen unser WordPress-Hosting auf Media Temple und wir mögen sie wirklich. Sie sind nicht die billigsten Anbieter, aber ihr Service ist ausgezeichnet und ihre Server sind wirklich gut eingerichtet. Die bieten standardmäßig auch Git an. Dies bedeutet, dass wir den Server als Git-Repository einrichten und Änderungen auf diese Weise abrufen können, anstatt SFTP zu verwenden. Es bedeutet auch, dass Arbeiten auf dem Server nicht überschrieben werden können (da diese Änderungen einfach zusammengeführt und gesichert werden können).

Da wir BitBucket als Git-Host verwenden, ist hier ein wenig zusätzliche Arbeit erforderlich. Zunächst verwenden wir .ssh/config files , damit wir uns mit Dingen wie ssh sitename auf unseren Servern anmelden können (wir verwenden auch kennwortloses SSH , was dies sehr einfach macht). Wir stellen außerdem sicher, dass immer ssh-Passphrasen verwendet werden (Mac OS X vereinfacht dies durch damit Sie Ihre Passphrase in Keychain.app speichern können ). Schließlich fügen wir dem Eintrag .ssh/config auf den Hosts, von denen wir ziehen möchten, eine ForwardAgent-Zeile hinzu. Dies bedeutet, dass wir nur den öffentlichen SSH-Schlüssel jeder Person in BitBucket benötigen und nicht den öffentlichen Schlüssel jedes Servers. Wir stellen außerdem sicher, dass das Verzeichnis .git ein Verzeichnis über dem öffentlichen HTML-Verzeichnis ist.

Automatisierte Datenbank-Dumps

Sobald sich der Server im Produktionsmodus befindet, stellen wir sicher, dass unsere Datenbank automatisch gesichert wird, nur für den Fall .

Jeder hat seine eigene wp-config

Da wir alle unsere eigenen lokalen Datenbankbenutzernamen und -kennwörter haben und unterschiedliche Namen und Serving-Mechanismen verwenden können, behalten wir jeweils unsere eigene wp-config-Datei bei. Jedes dieser Elemente wird in Git mit einem Namen wie wp-config-gavin.php gespeichert. Wenn wir diese Konfiguration verwenden möchten, müssen wir symlink auf wp-config.php verweisen (was von Git mit .gitignore ignoriert wird).

Dadurch können wir auch die Option siteurl in der Datenbanktabelle wp_options wie folgt überschreiben:

define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');

Dies verhindert, dass WordPress die Datenbank nach dem Serverstandort durchsucht, und bedeutet, dass es keine merkwürdigen Unterschiede zwischen dem Standort der lokalen und der Serverinstallation gibt.

Ein letzter Hinweis zu wp-config.php-Dateien: Stellen Sie sicher, dass sie über dem öffentlichen HTML-Verzeichnis gespeichert werden und dass die Berechtigungen nur für den Webbenutzer lesbar sind . Dies macht einen großen Unterschied bei der Sicherung von WordPress.

Das Datenbankproblem

Endlich das Fleisch der Sache.

Was ich akzeptieren musste, ist, dass es bei der Verwendung von WordPress keine gute Möglichkeit gibt, Datenbankänderungen zusammenzuführen. Stattdessen mussten wir Verhaltensregeln entwickeln, um dies zu lösen. Die Regeln sind ziemlich einfach und haben uns bisher gute Dienste geleistet.

Während der Entwicklung "besitzt" eine einzelne Person die Site. Diese Person führt normalerweise die Einrichtung durch (Zusammenstellen des Hosting-Pakets, Starten des Basecamp-Projekts, Schneiden des Designs usw.). Sobald diese Person einen vernünftigen Punkt erreicht hat, wird die Datenbank für die WordPress-Installation gesichert und in Git abgelegt. Ab diesem Zeitpunkt verwendet jeder Entwickler diesen Datenbankspeicherauszug, und der Eigentümer ist der einzige, der Änderungen an der Datenbank vornimmt.

Sobald der Site Build ein Stückchen weiter fortgeschritten ist, wird die Site auf einen Server gestellt. Ab diesem Zeitpunkt ist die Datenbank des Servers kanonisch. Jeder (einschließlich des Besitzers) muss alle Datenbankänderungen auf dem Server vornehmen und die Änderungen für die lokale Entwicklung und das Testen herunterladen.

Dieser Prozess ist nicht perfekt. Es ist immer noch möglich, dass jemand während der Entwicklung Änderungen im WordPress-Backend lokal vornehmen und diese Änderungen dann in der Produktion erneut vornehmen muss. Wir haben jedoch festgestellt, dass solche Dinge selten sind, und dieser Prozess funktioniert für uns ziemlich gut.

16
Gavin Anderegg

Ich experimentiere gerade mit verschiedenen Lösungen für das gleiche Problem. Es ist definitiv eine schwierige Frage.

Meine derzeitige Lösung besteht darin, einen lokalen MySQL-Dump mit dem Flag --skip-extended-insert durchzuführen. Ich glaube, dieses Flag bewirkt, dass eine Anweisung zum Einfügen eines Datensatzes für jede Zeile der Datenbank generiert wird, wodurch der Speicherauszug ein wenig zusammenführungsfreundlicher wird. Ich habe diesen Trick aus diesem Artikel aufgegriffen: http://www.viget.com/extend/backup-your-database-in-git/ .

Ich habe dann die Quellcodeverwaltung der resultierenden .sql-Datendump-Datei mit Git zusammen mit den Quelldateien der Site durchgeführt. Wenn ein anderer Entwickler Codeänderungen abruft, wird die .sql-Datei mitgeliefert. Anschließend importiert er diese Datei in seine lokale Version der Datenbank. Wir haben beide unsere jeweiligen lokalen Datenbanken auf beiden Computern mit MAMP auf die gleiche Weise eingerichtet, sodass keine Suchen und Ersetzen erforderlich sind.

Es gab Zusammenführungsprobleme, daher versuchen wir, alles, was eine Datenbankänderung zur Folge hat, "abwechselnd" zu behandeln. Bevor ich in Wordpress etwas tue, das die Datenbank ändert, stelle ich sicher, dass er seinen neuesten Speicherauszug eingecheckt hat, ziehe ihn und importiere ihn und fordere ihn auf, keine DB-Änderungen vorzunehmen, bis ich meine vorgenommen und eingecheckt habe. Dies ist offensichtlich nicht ideal und ich suche nach einer besseren Lösung, aber es ist ein Anfang. Es gibt uns auch die Versionskontrolle der DB, die Nizza ist.

Möglicherweise richte ich eine gemeinsam genutzte Entwicklerdatenbank auf dem Server ein und versuche, beide lokalen Kopien der Website über SSH-Tunneling mit derselben Datenbank zu verbinden. Dieser Ansatz stößt jedoch immer dann auf Probleme, wenn einer von uns ein Plugin installiert. Grundsätzlich sind die PHP -Dateien und die MySQL-Datenbank nicht synchron.

Ich bin gespannt, wie andere mit diesem Problem umgehen.

1
Yaron

Ich arbeite an einer solchen Installation und habe Fragen wie diese bereits beantwortet . Unten ist mein bevorzugtes Setup für diese Art von Arbeit. Da Sie Datenbanken zusammenführen möchten, anstatt eine vorhandene Datenbank zu ersetzen, sollten Sie beim Erstellen des MySQL-Dumps nicht das Flag --add-drop-table verwenden.


  • Schritt 1. Mysqldump Ihre Entwicklungsdatenbank
  • Schritt 2. Ersetzen Sie alle Instanzen von development.domain.com durch production.domain.com ^^
  • Schritt 3. Melden Sie sich bei MySQL an und führen Sie einen SOURCE-Befehl aus, um Daten zu importieren, z. source /path/to/file

^^ So ersetzen Sie alle Instanzen der alten Domain durch neue: (1) Kopieren Sie das folgende Skript. (2) chmod +x it. (3) Führen Sie es aus.

Verbrauch: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g
1
editor