WordPress und Git Workflow

Ich weiß, dass diese Frage tausendmal gestellt wurde, aber ich versuche wirklich herauszufinden, wie ich das Beste aus Git herausholen kann, wenn ich mit WordPress arbeite.

Ich habe das Internet durchsucht und Dutzende von Artikeln gelesen, die sich alle kurz mit dem Thema befassen. Hier sind einige der bemerkenswertesten, die ich in letzter Zeit gelesen habe.

- Versionskontrolle von WordPress

- Verwalten von WordPress Theme-Bereitstellungen mit Git

- Verwalten Sie Ihr benutzerdefiniertes WordPress-Design mit Git anstelle von FTP

Derzeit sieht mein Workflow so aus.

• Installieren Sie WordPress lokal
• Theme entwickeln
• Exportieren Sie WordPress-Datenbanken vom lokalen Server
• Importieren Sie die WordPress-Datenbank auf den Remote-Server
• Laden Sie WordPress-Dateien und Designs über FTP hoch
• Der Kunde nimmt Änderungen vor
• Laden Sie WordPress-Dateien und -Themen über FTP herunter und exportieren Sie WordPress-Datenbanken vom Remote-Server
• Dateien lokal ersetzen
• Nehmen Sie Entwicklungsänderungen vor
• Erneutes Hochladen über FTP, Exportieren und Importieren der Datenbank auf einen Remote-Server

Mir ist klar, dass Git diesen Prozess rationalisieren kann. Dies lässt sich am besten mit einer .gitignore-Datei erreichen, die bestimmte Verzeichnisse ignoriert, die nicht nachverfolgt werden müssen, sowie mit einer lokalen und einer entfernten wp-config.php-Datei.

Aber wie gehen Sie mit den Datenbanken um? Kunden nehmen normalerweise Änderungen vor (Posts / Seiten / Plugins). Muss ich immer noch aus der entfernten Datenbank exportieren und wieder auf meinen lokalen Server importieren?

Kann mir hier jemand den besten Workflow vorschlagen? Und geh mit mir durch die Stufen.

Außerdem würde ich wahrscheinlich gerne Bitbucket verwenden, da private Repos mit ihnen im Gegensatz zu GitHub kostenlos sind.

Jede Hilfe wäre dankbar.

Danke im Voraus!

Ich bin einer der Entwickler von WP Migrate DB Pro und möchte @ Ennuis Frage beantworten:

Msgstr "Wissen Sie, ob das von db url replace ausgeführte Skript serialisierte Zeichenfolgen berücksichtigt?"

Ja, es werden serialisierte Daten verarbeitet. Tatsächlich ist dies der Hauptgrund, warum ich 2009 die kostenlose Version des Plugins entwickelt habe. :)

Leider habe ich nur einen Ruf von 41, konnte also nicht auf @ Ennuis Kommentar antworten. Das tut mir leid.

Ich bin grenzwertig bei der Abstimmung, um dies als "nicht konstruktiv" abzuschließen, da es die Art von Dingen zu sein scheint, die eher zu Debatten und Meinungen als zu Antworten auffordern. Aber...

So sieht mein Arbeitsablauf nicht aus, und so unterscheidet sich mein Ansatz (und meine Antwort) von den meisten anderen Antworten, die ich bisher erhalten habe.

1. Installieren Sie WordPress lokal
   1. Dies wird von einem lokalen Git-Repo geklont, das die neueste stabile Version enthält.
   2. Ich behalte auch eine lokale Kopie der neuesten Version einiger Plugins, die ich fast immer installiere.
2. Erstellen Sie das Thema und alle erforderlichen Plugins
3. Hochladen auf einen öffentlichen Staging-Server
   1. Der Client erhält Zugriff, kann den Code jedoch nicht ändern, und es wird mitgeteilt, dass Datenbankänderungen nicht an den Produktionsstandort übertragen werden.
   2. Dies bedeutet, dass es keinen Grund gibt, den Code zurück auf den Entwicklungsserver herunterzuladen.
   3. Und kein Grund, die lokale Datenbank erneut zu synchronisieren
4. Nehmen Sie auf der Grundlage unserer Mitarbeiter und des Kundenfeedbacks Änderungen an der lokalen Site vor.
5. Änderungen hochladen
6. Bei Bedarf wiederholen (aber mit zunehmendem Widerstand :))
7. Wenn wir Inhalte bereitstellen, was nicht immer der Fall ist, werden wir (nicht der Client) die Datenbank auf dem Staging-Server bereinigen und Inhalte hochladen.
8. Stellen Sie es bereit, indem Sie den lokalen Code auf die Produktionssite hochladen.
9. Wenn wir Inhalte erstellt haben, werden diese über das Vanille-Export-Tool von der Staging-Site exportiert und in die Produktionssite importiert.
   1. Dies ist das einzige Mal, dass ich die Datenbank verschieben muss, und dies geschieht mit ziemlich standardmäßigen Tools. Ich werde Velvet Blues Update-URLs verwenden , um die Datenbank bei Bedarf zu bereinigen.
10. Debuggen
11. Das Ende

Grundsätzlich halte ich den Kunden so weit wie möglich von meinen Sachen fern, bis wir die Seite übergeben.

Code bewegt sich in eine Richtung - von lokal zu Inszenierung oder Produktion. Es bewegt sich niemals in die andere Richtung. Das beseitigt einige Ihrer Schritte und gibt mir etwas Ruhe. Ich möchte nicht dafür verantwortlich gemacht werden, dass der Client an meinem Code herumgebastelt hat, und ich möchte keine gehackten Dateien importieren, was eine Möglichkeit ist, die nicht Null ist.

Und die Datenbank wird, wenn überhaupt, nur einmal verschoben, was das Problem erheblich verringert. Ich schätze, ich schaffe es, das Problem des Verschiebens der Datenbank zu lösen, indem ich die Notwendigkeit, die Datenbank zu verschieben, reduziere oder entferne. Außerdem werden Probleme mit Datenbankbeschädigungen verringert, die auftreten können, und die Wahrscheinlichkeit, dass ein Hack importiert wird, wird verringert.

Zwar muss ich die Produktionsstätte konfigurieren - Permalinks, Menüs usw. -, aber das zwingt mich dazu, an der Produktionsstätte zu arbeiten, sodass ich dies als eine Art Debugging betrachte. Es hilft mir zu bestätigen, dass die Dinge am Produktionsstandort so funktionieren, wie sie sollten.

https://github.com/nathanielks/Wordpress-Capistrano-Deploy

Ich habe das (noch) nicht selbst ausprobiert, aber es gibt an, alles bereitzustellen - einschließlich DB.

Dazu gibt es auch ein Tutorial: Tutorial Teil 1 | Teil 2

Schauen Sie sich den Grundgesteinstapel an . Es verwendet Composer zum Verwalten der Version von Wordpress- und Plug-ins von Drittanbietern sowie Capistrano für Bereitstellungen und Vagrant / Ansible zum Einrichten von Servern, einschließlich lokaler virtueller Server für die Entwicklung.

Ich habe in letzter Zeit viele Tests dazu durchgeführt und hier ist der Workflow, den ich verwende, der ziemlich genau das tut, wonach Sie fragen:

• Ich verwende wp-cli, um den WordPress-Kern zu verwalten und WordPress zu aktualisieren.
• Ich verwende Composer zusammen mit http://wpackagist.org , um die Abhängigkeiten von Plugins und Themes zu verwalten.
• Ich benutze Git und lege Core-WP-Dateien in die .gitignore. Also sind meistens wp-config.php und untergeordnete Themendateien in git.

Ich bin nicht mit den DB-Migrationstools vertraut, würde diesen Workflow aber hervorragend ergänzen.

Hier finden Sie alle Details zum Workflow: http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

Bezüglich des "Klonens" der Datenbank verwende ich WP Migrate DB Pro: http://deliciousbrains.com/wp-migrate-db-pro/

Es ist ein kostenpflichtiger Dienst, der aber nicht viel kostet und es Ihnen leicht ermöglicht, Ihre Datenbank von Ihrem Entwickler auf Ihren Live-Server zu ziehen oder zu übertragen und umgekehrt. Es ändert die URLs und alles andere, was unterwegs geändert werden muss.