Mehrere Entwickler / Redakteure arbeiten an einer Site in Bearbeitung

28

Hintergrund

Ich stehe kurz vor der Fertigstellung meiner ersten ziemlich großen WordPress-Site und stoße jetzt auf einige Reibungspunkte. Die Site wurde größtenteils auf meinem lokalen Computer entwickelt, und ich habe die Änderungen zur Überprüfung auf einen Staging-Server übertragen (weitere Informationen finden Sie in dieser Frage ). 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, die ich herunterfahren möchte. Ich könnte die SQL-Ausgabe beider DBs abrufen und sie unterscheiden ... aber das scheint mühsam und hackisch. 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!

Gavin Anderegg
quelle
Abstimmung zum Schließen oder Umzug auf eine andere Site (Jan: Gedanken zu einer guten? Superuser vielleicht). Dies ist nicht WordPress-spezifisch, da Sie auf Drupal, Joomla oder einer von PHP + MySQL gesteuerten Site auf dieselben Probleme stoßen würden.
John P Bloch
Mein Vorschlag ist jedoch, dass Sie einen Remote-Staging-Server anstelle eines lokalen Servers verwenden.
John P Bloch
@John P Bloch: Mit Drupal würde so etwas wie Drush in dieser Situation viel helfen. Ich bin persönlich an Django gewöhnt, wo diese Probleme durch Fixtures gemildert werden. Außerdem habe ich derzeit zwei Staging-Server: einen lokalen und einen Remote-Server. Die Sache ist, dass ich meine Arbeit auf meinem Remote-Computer erledige, ihn aber auf einen Server übertragen muss, damit andere ihn sehen können. Der letzte Server wird eingerichtet, wenn wir alles zusammen haben.
Gavin Anderegg
2
@John P Bloch - Ich denke, es gibt Gründe, warum dies hier als gute Frage sinnvoll ist. Ich habe im Moment keine Zeit, darauf zu antworten, aber hoffentlich tun es andere.
MikeSchinkel
1
@Gavin: Entschuldigung, ich habe deine Frage falsch interpretiert. Ja, ich glaube, das würde alles auf dem Produktionsserver überschreiben. : /
Zack

Antworten:

16

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

Dies 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 erhalten 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äre etwas langwierig, 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 zurückgespielt werden können).

Da wir BitBucket als Git-Host verwenden, ist hier ein wenig zusätzliche Arbeit erforderlich. Zunächst verwenden wir .ssh / config-Dateien, damit wir Dinge eingeben können , um uns ssh sitenameauf unseren Servern anzumelden (wir verwenden auch passwortloses SSH , was dies sehr einfach macht). Wir achten auch darauf, immer ssh-Passphrasen zu verwenden (Mac OS X macht dies sehr einfach, indem 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 auch sicher, dass das .gitVerzeichnis ein Verzeichnis über dem öffentlichen HTML-Verzeichnis ist.

Automatisierte Datenbank-Dumps

Sobald sich der Server im Produktionsmodus befindet, stellen wir sicher, dass unsere Datenbank für alle Fälle automatisch gesichert wird .

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. Jeder von ihnen ist in Git mit einem Namen gespeichert wie wp-config-gavin.php, und wenn wir diese Konfiguration verwenden möchten, wir Symlink sie wp-config.php(die von Git ignoriert .gitignore ).

Dies ermöglicht uns auch, die siteurlOption in der wp_optionsDatenbanktabelle wie folgt zu ü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 lokalen und dem Server-Installationsort gibt.

Ein letzter Hinweis zu wp-config.php-Dateien: Stellen Sie sicher, dass sie über dem öffentlichen HTML-Verzeichnis gespeichert sind 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 Eigentümers) 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.

Gavin Anderegg
quelle
1

Ich arbeite an einer solchen Installation und habe bereits Fragen wie diese 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 das Flag --add-drop-table nicht 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 +xes. (3) Führen Sie es aus.

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

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g
Editor
quelle
2
seien sie vorsichtig: sed ist nicht in der lage, daten zu verarbeiten, die in zuvor serialisierten mysql-dumps codiert wurden.
Hakre
Die Frage, die Sie zuvor beantwortet haben, war tatsächlich meine :) Ich habe das Gefühl, dass ich hier eine andere Frage stelle. Es ist großartig, die gesamte Datenbank zu sichern, wenn nur ich daran arbeite. Wenn ich dies jedoch in der oben beschriebenen Situation tue, überschreibe ich entweder die Änderungen anderer Personen oder meine eigenen Änderungen. Ich versuche die Änderungen zu kombinieren, da mehr als eine Person an WordPress-Instanzen arbeitet.
Gavin Anderegg
1

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-Speicherauszug mit dem Flag --skip-extended-insert zu erstellen. 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 zu einer Datenbankänderung führen kann, "abwechselnd" zu behandeln. Bevor ich etwas in Wordpress 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, was nett 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 MySQL DB nicht synchron.

Ich bin gespannt, wie andere mit diesem Problem umgehen.

Yaron
quelle