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.