it-swarm.com.de

Entwicklungs-, Bühnen- und Produktionsbereitstellung für WordPress-Sites?

Daher muss ich in der Lage sein, Entwicklungs-/Bühnen-/Produktionsiterationen (über separate Server) für eine WordPress-Website zu haben. Ich verwende normalerweise Git, aber dies funktioniert offensichtlich nicht mit WordPress-Sites, da die Hauptdatenbank verwendet wird Konfiguration von ... na ja, fast alles.

Meine Frage ist also, wie macht ihr das? Ich hatte ein schnelles Google und sah, dass es ein paar Plugins gab. Ist dies der einzige Weg? Welche machen den Job am besten in Bezug auf Benutzerfreundlichkeit, Geschwindigkeit, Zuverlässigkeit, Benutzeroberfläche usw.?

41
igneosaur

Ich bin ziemlich stolz auf mein Setup und es funktioniert sehr gut für mein Team.

Allgemeine Struktur

Ich halte die gesamte Installation unter Kontrolle. Alle Änderungen, sei es ein System-Update, das Hinzufügen/Aktualisieren eines Plugins, das Hinzufügen/Aktualisieren eines Themas, durchlaufen denselben Workflow. Änderungen können jederzeit rückgängig gemacht werden. Ich habe einen Bereitstellungsserver (einen alten P4-Desktop), auf dem gitosis ausgeführt wird, aber Sie können genauso einfach github oder gitolite verwenden. In Git habe ich zwei "spezielle" Zweige, master und develop (weiter unten erklärt). Meine Produktions- und Staging-Server sind cloudbasiert.

Entwicklungsumgebungen

Jeder Entwickler betreibt seinen eigenen Entwicklungsserver auf seinem eigenen Computer. In Bezug auf Datenbanken war der Bedarf an Live-Daten selten ein Thema. Wir verwenden hauptsächlich die Theme Unit Testdaten . Ansonsten umfasst Export und Import die meisten Dinge. Wenn das DB-Teil von entscheidender Bedeutung ist, können Sie die Replikation oder etwas für die On-Demand-Synchronisierung einrichten. Als ich diese Struktur zum ersten Mal einrichtete, dachte ich, dass dies von entscheidender Bedeutung sein würde, und begann, ein Werkzeugset zu schreiben, aber zu meiner Überraschung waren sie wirklich nicht notwendig. (Anmerkung: da sie nicht notwendig waren, habe ich sie nie aufpoliert, daher gibt es Fehler, die beispielsweise die Domain in serialisierten Daten ersetzen).

Staging-Umgebung

Wenn Commits vom Zweig develop zu gitosis verschoben werden, werden sie automatisch auf unserem Staging-Server bereitgestellt. Die Staging-Datenbank ist ein Slave für die Produktionsdatenbank.

Produktionsumgebung

Wenn Commits für den Zweig master an gitosis gesendet werden, werden sie automatisch auf dem Produktionsserver bereitgestellt.

Das Problem mit wp-config.php

Sie möchten, dass der wp-config.php von Server zu Server eindeutig ist, aber Sie möchten ihn auch unter Versionskontrolle halten. Meine Lösung bestand darin, .gitignore zum Ignorieren von wp-config.php zu verwenden und die Staging- und Produktionsversionen als Dateien mit unterschiedlichen Namen zu speichern. Dann verknüpfe ich auf jedem Server z. wp-config.php -> wp-config-production.php. Jeder Benutzer behält dann seine eigene Datenbank mit seinen eigenen Anmeldeinformationen und seinen eigenen (nicht verfolgten) wp-config.php-Einstellungen.

Weitere Hinweise

Ich benutze Rackspace Cloud , was phänomenal und preiswert ist. Damit kann ich meine Staging- und Produktionsserver identisch halten. Ich schreibe gerade auch Plugins, die ihre API verwenden, um meine Dienste direkt aus WordPress heraus zu steuern. Es ist wunderbar.

Cache-Verzeichnisse, Datei-Upload-Verzeichnisse usw. werden zu .gitignore hinzugefügt. Wenn Sie möchten, können Sie eine Cron-Task einrichten, um Uploads routinemäßig einzuchecken und auf Gitosis zu verschieben, aber das schien mir nie notwendig zu sein.

Die Master/Develop-Struktur ist so eingestellt, dass sie Vincent Driessens Verzweigungsmodell teilweise nachahmt. Ich benutze auch seine Git-Erweiterung git-flow und ich würde das auch sehr empfehlen.

Ich habe ungefähr 10 Entwickler, die seit über einem Jahr an dieser Struktur arbeiten, und es war ein Traum, mit ihr zu arbeiten. Zuverlässig, sicher, schnell, funktional und agil - mehr kann man nicht verlangen!

27
Matthew Boynes

Erstens denke ich, dass es wichtig ist, was Sie zur Versionskontrolle gehen. Ich würde empfehlen, gegen das gesamte Verzeichnis WP unter VC zu stellen. Ich denke, es ist am sinnvollsten, wp-content/themes/YourThemeName unter VC zu setzen. Bei einer großen Site mit einer großen Anzahl komplexer Plugins könnte es durchaus vorkommen, dass auch wp-content/plugins einbezogen werden. Wenn Sie unbedingt müssten, könnten Sie wp-Inhalte/Uploads einbinden. Die folgenden Antworten ändern sich ein wenig, je nachdem, welche Versionskontrolle Sie durchführen.

Vor diesem Hintergrund verwende ich Folgendes:

Lokal: Richten Sie einen LAMP-Stack auf Ihrem Computer ein. Verwenden Sie dieselbe URL wie Ihre Entwicklungssite. Verwenden Sie VirtualHosts- und .Host-Dateieinträge, um die Entwicklungsumgebung aus URL-Sicht zu simulieren. Wenn Sie nur Ihr Thema VC'ing, erwägen Sie die Verwendung von SSHFS zum Verknüpfen von WP-Inhalten/Plugins, WP-Inhalten/Uploads. Ziehen Sie in Betracht, die Datenbank für Ihre Entwicklungsinstallation des Projekts zu verwenden, es sei denn, Sie tun wirklich etwas Schweres.

Entwicklung: Testen Sie eine Arbeitskopie Ihres Repos in Ihrer WP Umgebung. Richten Sie in SVN einen POST-COMMIT-Hook ein, um dieses Repo bei jedem Commit zu aktualisieren. Dadurch wird die Synchronisierung aufrechterhalten. (Betrachten Sie es als kontinuierliche Integration eines armen Mannes.)

Produktion: Schauen Sie sich ein benanntes Versions-Tag an, das einen endgültigen Kandidaten darstellt. Wenn Sie eine neue Version benötigen, wechseln Sie das Tag und aktualisieren Sie das Repo.

4
Ethan Seifert

Wir haben kürzlich RAMP entdeckt. Hinweis: Dies ist nur ein Teil des gesamten Prozesses, aber das Synchronisieren von Inhaltsdatenbanken zwischen Servern ist wahrscheinlich der schwierigste Teil.

2
lkraav

Ich mache das mit git und Mercurial, stelle nur sicher, dass du ein privates Repo verwendest.

Option 1.

Das einzige Problem ist die config.php, die Sie bei Push oder vor init ignorieren können.

Verwende .gitignore oder git update-index --assume-unchanged config.php (lies ein wenig über den angenommenen-unveränderten Befehl, bevor du ihn verwendest)

Optionen 2.

Verwenden Sie in der config.php eine Bedingung, die die URL überprüft und die korrekten Anmeldeinformationen anwendet, wie unter "Wenn Server-URL = dev, dann Anmeldeinformationen A verwenden, andernfalls Anmeldeinformationen B verwenden" beschrieben.

Mark erklärt das besser, http://markjaquith.wordpress.com/2011/06/24/wordpress-local-dev-tips/

ps. Sie können die Dateien auch direkt von einem Remote-Repository aus speichern, anstatt über einen herkömmlichen "Dateiserver" zu verfügen. (Wirklich langweiliges Video, das ich darüber gemacht habe http://www.youtube.com/watch?v=8ZEiFi4thDI )

2
Wyck