20. Sep
Post

Staging-Umgebung für WordPress

Mein neuestes Rand-Projekt dreht sich um die Erstellung einer Staging-Umgebung für WordPress. Wie oft stand ich schon vor dem Problem, dass ich bei einer meiner WordPress-Sites etwas testen wollte und mich dann allerdings nicht getraut habe, weil Herumpfuschen in einer Produktiv-Umgebung meistens nichts Gutes bringt. Neue Plugins, Themes oder sogar manuelle Anpassungen im Code sorgen gelegentlich für ungewollte Seiteneffekte, die normalerweise immer auch sofort für jeden Besucher sichtbar sind. Und war ich dann doch mutig leichtsinnig genug, es doch zu tun, habe ich mich oft genug auch schon über mich selbst geärgert.

Web developmentDas Einfachste wäre doch eine Staging-Umgebung für WordPress, in der man zwar die Produktiv-Umgebung abbildet aber sie bei Änderungen nicht gefährdet. Das hilft zum Beispiel auch bei der Einführung eines neuen Themes. Man könnte so in Ruhe alle Theme-Daten anpassen, während man seine Site bereits mit echten Daten betrachten kann. Gerade im Zusammenspiel mit neuen Plugins wäre das der sicherere Weg.

Deshalb habe ich mich nun mal wieder hingesetzt und eine Lösung für den Aufbau einer Staging-Umgebung gebaut. Herausgekommen ist ein Shell-Skript, das eine Spiegelung einer WordPress-Instanz durchführt. Hierbei werden sowohl alle Verzeichnisse und Dateien gespiegelt, als auch alle Inhalte der Datenbank übertragen. Hierbei werden außerdem alle Pfade und Adressen für die jeweilige Instanz angepasst.

Am Ende hat man somit zwei identische WordPress-Installation mit allen Daten, die jedoch unabhängig voneinander genutzt werden können, z.B.

http://www.mydomain.com – für die produktive Umgebung
http://dev.mydomain.com – für Tests und Weiterentwicklungen

Es existieren da draußen zwar auch andere Lösungen, allerdings meist als Plugin innerhalb einer WordPress-Installation. Ich wollte jedoch etwas Eigenes basteln. :-)

Und so sollte es gehen:

 

Installation / Setup

 

VORAB: Hier geschieht alles auf eigene Gefahr! Ich übernehme keine Verantwortung für Fehlfunktionen oder Programmierfehler, die zu Datenverlust führen oder den Tod von Menschen zur Folge haben. Bevor Ihr das Skript nutzt, legt Euch ein umfassendes Backup an und testet das Ganze mit etwas nicht-Produktivem! Ich habe keine Lust, mir hinterher das Geheule anhören zu müssen, weil wordpress.org plötzlich down ist, oder so. :-)

Ich habe auch auf umfassende Fehlermeldungen im Code verzichtet. Alle externen Tools sind am Anfang aufgeführt. Wenn davon etwas auf dem System fehlt, knallt es halt. Habt also ein Auge darauf! Vielleicht ergänze ich das später mal in einer neuen Version.

Ihr benötigt root-Zugriff auf Eurem Webserver. Außerdem solltet Ihr bereits Vorbereitungen für zwei WordPress-Sites getroffen haben, z.B. VirtualHosts im Apache-Webserver und dazu natürlich zwei MySQL-Datenbanken (mit einer gemeinsamen DB funktioniert das Skript nicht). Wie man das alles einrichtet, erkläre ich hier jetzt aber nicht. Die beiden Sites müssen unter unterschiedlichen Domains erreichbar sein, so wie oben dargestellt. Die Namen (auch www und dev) dürfen natürlich abweichen. Eine der beiden Umgebungen sollte außerdem schon existieren, sonst macht ein Klonen keinen Sinn.

Ladet Euch das ZIP-Archiv wordpress_deployment-1.1.zip herunter und packt es auf Eurem Webserver an einem sicheren Ort aus. Lest Euch alle Hinweise im Skript durch und füllt die Variablen mit den geforderten Werten. Da auch ein paar Passwörter eingetragen werden müssen, solltet Ihr es vor neugierigen Blicken schützen.

Sind alle Daten eingetragen und die “prepared”-Variable aktiviert, kann schließlich das Skript “wordpress_deployment.sh“ aufgerufen werden. Je nach gewünschter Richtung werden zwei Parameter übergeben:

Usage: ./wordpress_deployment.sh  [target]

e.g.:  ./wordpress_deployment.sh live staging

 

Es ist sehr wichtig, zu verstehen, dass das Skript eine Ersetzung von Quelle zu Ziel durchführt. Hier werden keinerlei Daten gemischt, sondern knallhart ersetzt. Es ist also Vorsicht geboten, damit keine Inhalte verloren gehen, wie z.B. neue Kommentare in der Live-Umgebung. Mir ist klar, dass das Skript bei stark frequentierten Sites oder langen Entwicklungszyklen nicht so gut nutzbar ist, um Development-zu-Live-Transfers durchzuführen. Für andere Anwendungsfälle kann es allerdings eine echte Hilfe bedeuten. Eine Staging-Umgebung für WordPress kann auch für schnelle Tests eines neuen Features genutzt werden.

Für das Umbiegen der Domains und Pfade in der MySQL-Datenbank habe ich mir ein externes Skript von David Coveney of Interconnect IT Ltd (UK) zu Nutze gemacht, das Ersetzungen in serialisierten Datensätzen durchführen kann. Ich habe nur minimale Anpassungen vorgenommen, damit es sich in das eigentliche Skript besser einfügt.

Tja, was sonst noch? Feedback ist natürlich erwünscht. Ich bin gespannt, ob es überhaupt bei irgendwem außer mir läuft. :-)

 

Ein wichtiger Hinweis

Ihr solltet Eure Staging-Umgebung durch ein Passwort (mit htaccess) schützen, um zu verhindern, dass Google Euren duplizierten Content indexiert. Hier eine Info der der Google Webmaster-Zentrale:

[quote]Duplizierung von Content über hosting-spezifische URLs. Viele Hosts bieten zu Test-/Entwicklungszwecken URLs für eure Website an. Wenn ihr beispielsweise die Website http://a.com/ auf dem Hostanbieter example.com hostet, bietet der Host möglicherweise über eine URL wie http://a.example.com/ oder http://example.com/~a/ Zugriff auf eure Website. Wir empfehlen euch, diese hosting-spezifischen URLs durch ein Passwort zu schützen und so den öffentlichen Zugriff zu verhindern. Selbst wenn diese URLs zugänglich sind, berücksichtigen unsere Algorithmen in der Regel die Absicht des URL-Webmasters. Falls unsere Algorithmen die hosting-spezifischen URLs auswählen, könnt ihr diese durch die korrekte Implementierung von Autorisierungstechniken so beeinflussen, dass sie die bevorzugten URLs auswählen.[/quote]

Ich habe das Skript etwas erweitert. Die Version 1.1 enhält nun die Variable “$htpasswd_file”. Wird hier ein gültiger Pfad zu einer Apache-Passwort-Datei eingetragen, beschränkt das Skript den Zugriff auf die Staging-Umgebung für WordPress automatisch. Bitte unbedingt prüfen, ob das auch funktioniert!

 

Falls jemand auf der Suche nach einer Alternative zu diesem Skript ist, hilft vielleicht diese Webseite über die Erstellung von Test-Umgebungen für WordPress.

Viel Erfolg!

GD Star Rating
lädt…

Das könnte Dich ebenfalls interessieren:

Veröffentlicht in: Projekte

Über den Autor:

Beruflich arbeite ich als Premium Support Engineer bei Novell. Seit 2008 schreibe ich in diesem privaten Blog über Linux, Software, Programmierung, Suchmaschinen-Optimierung und über alles, was mir außerdem an IT-Themen begegnet. Darüber hinaus blogge ich hier auch über meine Hobbies, meine Meinung zu Filmen, Musik und was mir sonst so vor die Flinte kommt.

4 Kommentare zu "Staging-Umgebung für WordPress"

Trackback | Kommentar RSS Feed

  1. Ben sagt:

    Why does your script require root access? Does this script still work with WordPress 3.6.1?

    best regards, Ben

    • Hi Ben!

      This script uses a chown command within the copy_files() function, because I use two different user accounts for the dev and prod environment. I’m not really sure at the moment but if you don’t need the chown part, root permissions shouldn’t be required.

      I didn’t test this script with WordPress 3.6.1 but this script does not use WordPress features. It just copies and changes some files and database records. So the WordPress version should be unimportant.

      HTH,
      Thomas

  2. shnifti sagt:

    I figured out their is minor problem with your script. When you deploy your live instance as stage it gets a restricted robots.txt. This file doesnt revert when making changes in stage and afterwards deploy stage as live.

    I think you can just leave the robots.txt as it is since you are using htpasswd to protect the stage from being indexed.

    cheers, Ben

    • shnifti sagt:

      As I figured out it is possible to use the script on a shared hosting service as I do with one of my clients. I adapted the script a little bit to make it work on solaris (strato hosting). Besides the kind of strange robots.txt part mentioned above and also not restoring htaccess without htpasswd enabled it works like a charme.

      cheers, Ben

Schreibe einen Kommentar