Anzeige
Anzeige
How-To
Artikel merken

WordPress in Groß: Workflows für die Umsetzung großer Projekte

Kleine WordPress-Projekte sind in der Regel kein Problem. Wenn aber ein richtiges Team ein größeres Projekt umsetzen will, braucht es einen guten Workflow und Werkzeuge, die helfen.

7 Min. Lesezeit
Anzeige
Anzeige

Grafik: t3n

Eine WordPress-Website aufsetzen: Das ist heute kein Hexenwerk mehr. Diverse Anleitungen im Netz und automatisierte Dienste von Hosting-Anbietern helfen dabei. Doch mit der Projekt- und Teamgröße steigt auch der Schwierigkeitsgrad für die Aufrechterhaltung und (Weiter-)Entwicklung eines WordPress-Projekts. Alle Beteiligten müssen den neuesten Stand möglichst gut kennen und einen grundlegenden Überblick haben. Außerdem muss sich die Seite im Notfall in ihren Ursprungszustand zurücksetzen lassen – ohne dass die Entwickler des Teams dadurch ihre Stunden in die Wiederherstellung ihrer Arbeit anstatt in die Weiterentwicklung stecken müssen.

Anzeige
Anzeige

Um das zu bewerkstelligen, gibt es verschiedene mögliche Herangehensweise und dazugehörige Werkzeuge. Jedes Team und Projekt muss zwar für sich den genau passenden Workflow selbst entwickeln, doch die hier beschriebenen Arbeitsabläufe eignen sich für neue und die meisten bereits bestehenden Projekte.

Der Toolstack

Größere WordPress-Projekte verlangen Entwicklern etwas mehr als üblich ab. Selbst diejenigen, die sich im Umgang mit PHP und der Entwicklung von WordPress-Plugins und -Themes sicher fühlen, können dabei noch das ein oder andere dazulernen. Neben einer guten IDE – wie beispielsweise PHPStorm – sollten die folgenden Werkzeuge in großen Projekten auf keinem Entwicklergerät fehlen.

Anzeige
Anzeige

GIT

GIT ist die wohl bekannteste Lösung, um Code zu speichern und zu versionieren. Mit Diensten wie GitHub oder BitBucket erhalten Entwicklerteams mächtige Werkzeuge, um den Fortschritt ihrer Arbeit festzuhalten, gemeinsam zu entwickeln und Code zu teilen.

Anzeige
Anzeige

Composer

Composer ist ein PHP-Dependency-Manager, mit dem Entwickler PHP-Pakete in Abhängigkeit voneinander herunterladen und stets auf dem neuesten Stand halten können. Dazu gehören auch WordPress-Plugins und -Themes – und das nicht nur Client- sondern auch Serverseitig.

Deployer

Der Deployer ist nur eines von zahlreichen Werkzeugen, mit denen sich Code auf Servern deployen lässt. Deployer erweist sich aber als eines des unkompliziertesten Tools. Es führt eine Reihe von definierten SSH-Kommandos auf dem Ziel-Server aus. Damit können Entwickler ihre Codebase über Composer und GIT aktualisieren oder andere Aufgaben voll automatisiert durchführen.

Anzeige
Anzeige

WP-Starter

Das WP-Starter-Paket liefert den einfachsten Weg, um eine WordPress-Installation mit Hilfe des Tools Composers zusammenzustellen und aufzusetzen.

WP-CLI

WP-CLI bringt WordPress auf die Kommandozeile. Mit ihr können Entwickler unter anderem Plugins aktualisieren, Seiten konfigurieren und Änderungen an einer Datenbank vornehmen – und das alles, ohne auch nur einmal das WordPress-Interface bemühen zu müssen. WP-CLI lässt sich außerdem relativ einfach um eigene Routinen erweitern, sodass sich spezielle, auf das Projekt zugeschnittene Abläufe automatisiert über die Kommandozeile realisieren lassen.

Drei Server sollt ihr sein

Auch bei der Entwicklung großer WordPress-Projekte kann sich zwar jeder Entwickler eine eigene Test-Umgebung einrichten. Entwicklerteams sollten daneben aber mit mindestens drei Servern arbeiten:

Anzeige
Anzeige

Der Development-Server

Auf dem Development- oder auch DEV-Server findet die eigentliche Entwicklung statt. Die Programmierer können hier sämtlichen Code (mehr oder weniger) ungetestet deployen. Der Direkt-Upload ohne GIT und Composer ist explizit erlaubt, um eine schnelle Entwicklung auch ohne Entwickler-eigenes Testsystem zu ermöglichen.

Gerade für Designer, die lediglich CSS-Dateien über FTP hochladen wollen, ist dieser Server die perfekte Spielwiese. Allerdings sollten die Teams sicherstellen, dass die Projektbeteiligten nicht gegeneinander arbeiten – also sich gegenseitig nicht die Dateien zerschießen.

Der Staging-Server

Auf dem Staging-Server testen die Entwickler oder Entwicklerteams sämtlichen Code, bevor er live geht. Das Deployment findet hier nur über die oben genannten Werkzeuge statt, sodass der Prozess möglichst nah an dem späteren Szenario beim Deployment auf den Production-Server herankommt. Die Konfiguration des Staging-Servers sollte möglichst eng an die des Production-Servers angelehnt sein, sodass das Team unter Quasi-Realbedingungen testen kann.

Anzeige
Anzeige

Production-Server

Der Production-Server ist für den öffentlichen Einsatz bestimmt und beherbergt den getesteten und freigegebenen Code. Alles, was auf diesem Server landet, sollte vorher auf dem Staging-Server überprüft und von Fehlern bereinigt sein.

Auf allen drei Servern gilt es, GIT, Composer und WP-CLI zur Verfügung zu stellen. Außerdem sollten die drei Server sämtliche Repositories (auch die nicht-öffentlichen) über SSH klonen. Wie das bei GitHub und BitBucket geht, beschreiben die Dokumentationen der Anbieter. Auf allen Servern sollte sich außerdem PHP über die Kommandozeile ausführen lassen.

WordPress-Projekte anlegen

Mit WPStarter ist das Anlegen einer WordPress-Installation fast so einfach wie mit dem eigentlichen WordPress-Installer. Zunächst mag der Vorgang zwar unnötig kompliziert erscheinen, doch der kleine Umweg lohnt sich. Zur Installation gehören nur die folgenden drei Schritte:

Anzeige
Anzeige
  1. composer.json anlegen
  2. composer install ausführen
  3. Umgebungsvariablen einrichten

Der Autor von WPStarter zeigt in einem Quick-Start ein Beispiel für eine grundlegende composer.json. Entwickler können diese aber auch ihren Bedürfnissen anpassen. Ist die composer.json angelegt, muss man nur noch den Befehl „composer install“ über die Kommandozeile im Projektordner ausführen – und schon lädt die Anwendung sämtliche Abhängigkeiten, die in der composer.json definiert sind, herunter.

Eine der heruntergeladenen Dateien ist die .env.example, die ein Entwickler nur noch kopieren, als .env abspeichern und mit den entsprechenden Einstellungen für die Installation bestücken muss. Dabei sollte er zumindest die Datenbank-Einstellungen und die URL der Website setzen. Diesen Schritt muss er auf jedem Server und jeder (lokalen) Test-Umgebung durchführen. WordPress lässt sich nun über WP-CLI oder über den WordPress-Installer installieren.

Der folgende Befehl liefert das Administrator-Passwort zurück. Die WordPress-Webseite ist nun bereit.

Anzeige
Anzeige

Adminstrator-Passwort zurückliefern

$ wp core install --url=http://meine-testseite.de --title=Test --admin_user=admin --admin_email=admin@test.de

Listing 1

Öffentliche Plugins und Themes über Composer laden

Mit WP-Starter und Composer lassen sich Plugins und Themes aus dem WordPress-Repository ganz einfach zu einem Projekt hinzufügen. Der Dienst WordPress Packagist stellt diese Plugins und Themes für Composer zur Verfügung.

Das Composer Repository von WPackagist liegt bereits als Quelle im WP-Starter-Paket. Über „composer require wpackagist-plugin/plugin-name:version“ oder „composer require wpackagist-theme/theme-name:version“ lassen sich die Plugins und Themes ins Projekt laden.

Eigene Plugins und Themes über Composer laden

Eigene Plugins und Themes können Entwicklerteams hingegen über das Werkzeug GIT für Composer bereitstellen. Hierfür sollten das Theme oder die Plugins eine composer.json im jeweiligen Hauptverzeichnis enthalten. Diese kann aber auch ganz minimal gehalten sein:

Anzeige
Anzeige

Minimale composer.json für eigene Themes oder Plugins

{
  "name": "imbaa/test-plugin",
  "description": "Ein Test Plugin",
  "type": "wordpress-theme"
}

Listing 2

In der composer.json des Projekts muss der Entwickler nun nur noch das GIT-Repository hinterlegen, sodass Composer die Plugins und Themes über „composer require“ als Abhängigkeit beziehen kann. Composer kann neben GIT- auch auf Subversion-, Mercurial- und Fossil-Repositories zugreifen.

Plugins und Themes als Abhängigkeit beziehen

"repositories": [
        {
            "type": "vcs",
            "url": "git@bitbucket.org:imbaa/test-plugin.git"
        }
    ]

Listing 3

Deployer einrichten und nutzen

Der Deployer lässt sich zwar einfach über Composer zum Projekt hinzufügen. Es lohnt sich aber, den Deployer global auf jedem Entwicklersystem, das später auch das Deployment durchführen soll, zur Verfügung zu stellen.

Deployer zur Verfügung stellen

curl -LO https://deployer.org/deployer.phar
mv deployer.phar /usr/local/bin/dep
chmod +x /usr/local/bin/dep

Listing 4

Über den Befehl „dep init“ können Entwickler ein grundlegendes Rezept generieren. Der Deployer erstellt dabei eine zusätzliche PHP-Datei (deploy.php), die den Zielserver definiert, sowie vom System beschreibbare Ordner und für jedes Deployment gemeinsame Dateien und Ordner, die nicht bei jedem Deployment überschrieben werden sollen. Ein grundlegendes Rezept für WordPress kann folgendermaßen aussehen:

Deployer-Rezept

 <?php
require 'recipe/composer.php';
// Haupt-Repository des Projekts
set('repository', 'git@bitbucket.org:imbaa/imbaa-website.git');
// Shared Files, die als Symlink auf dem Zielserver eingebunden werden
set(
    'shared_files',
    [
        '.env',
        'public/robots.txt',
        'public/.htaccess',
        'public/wp-content/debug.log'
    ]
);
// Shared Directories, die als Symlink auf dem Server eingebunden werden
set(
    'shared_dirs',
    [
        'public/wp-content/uploads',
        'public/wp-content/cache',
        'public/wp-content/tmp',
        'public/wp-content/languages'
    ]
);
set('writable_dirs', []);
// Configure servers
server('dev', 'home.imbaa.de')
    ->user('username')
    ->env('deploy_path', '/var/www/dev.imbaa.de')
    ->identityFile(); // Über SSH-Key authentifizieren
server('stage', 'imbaa.de')
    ->user('imbaa')
    ->env('deploy_path', '/var/www/stage.imbaa.de')
    ->identityFile();
server('live', 'imbaa.de')
    ->user('imbaa')
    ->env('deploy_path', '/var/www/ imbaa.de')
    ->identityFile();

Listing 5

Mit dem Befehl „dep deploy dev“ können Entwickler nun ein Deployment auf dem Development-Server auslösen. Der Server klont dabei das oben definierte Repository und führt Composer aus. Beim ersten Deployment-Vorgang legt das Werkzeug dann zusätzliche Ordner an.

Im Ordrner „releases“ befinden sich die Kopien der Daten aus dem Repository. Jeder Deployment-Vorgang erzeugt einen neuen Unterordner, sodass das Team jederzeit zum ursprünglichen Zustand des WordPress-Projekts zurückkehren kann. Im Ordner „shared“ liegen die als gemeinsam definierten Dateien und Ordner. Zusätzlich dazu entsteht ein Symlink „current“, der bei einem erfolgreichen Deployment auf das jeweilige Release im „releases“-Ordner zeigt. Diesen Symlink sollte man auch als Document Root des Webservers definieren.

Beim Deployment führt ein WP-Starter-Projekt einige automatische Prozeduren aus. Scheitern diese, bricht der Deployment-Prozess ab und aktualisiert den Symlink nicht. So merken User bei einem fatalen Fehler meistens nichts von einem auftretenden Problem. Sollte aber doch mal etwas richtig schiefgehen, kann das Team mit „dep rollback“ auf das vorhergehende Release zurückspringen.

Fazit

Besonders für kleine Teams ist es oft nicht leicht, gewohnte Routinen zu verändern – etwa das „einfache Hochladen“ oder Installieren von Plugins und Themes über die Bordmittel von WordPress. Doch die Umstellung lohnt sich, die zusätzlichen Werkzeuge in den Arbeitsablauf aufzunehmen. Denn nur so kann das Team tatsächlich sicherstellen, dass alle auf einem möglichst aktuellen Stand sind und sich jeder Arbeitsschritt zurückverfolgen lässt. Probleme sind frühzeitig auf dem DEV- und Staging-System sichtbar und lassen sich somit beheben, bevor sie zu Schwierigkeiten im Live-Betrieb führen. Dass sich dadurch einige Prozesse – die sonst viel schneller von der Hand gehen – gegebenenfalls in die Länge ziehen, sollte Entwickler deshalb keineswegs abschrecken.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Ein Kommentar
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Heinz Inge

Tja, das interessante wird leider Weggelassen.

Was ist denn für Sie „Groß“? 10k Seiten? 100k? Ne Millionen Plugins?

Und vor allen Dingen fehlen Beispiele von Großen Seiten die mit WordPress realisiert wurden. Die meisten dich ich kenne wurden nämlich mittlerweile durch Eigenentwicklungen ersetzt. Also sofern es sich wirklich um Dynamische Seiten handelt und nicht nur reine Blogauflistungen von News.

Falls noch jemand anders Beispiele hat, immer her damit. :)

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige