Moderner WordPress-Workflow (Sage, Trellis, Bedrock)

Endlich habe ich meinen Allerwertesten angeschoben und mich mit einem modernen, effizienteren Workflow rund um meine WordPress-Projekte vertraut gemacht. Die Schritte auf dem Weg dahin sind zwar recht zahlreich und zeitweise ‚mental‘ aber es lohnt sich…!

Disclaimer: Das Ding hier ist recht lang geraten und Ihr werdet erfahrungsgemäß > 2 Stunden mit dem Setup verbringen – also keine falschen Illusionen machen und mit Kaffee / Bier wappnen.

Background

Den Anfang machte für mich die Entdeckung von Roots vor ca. 2 Jahren – ich hab damals mit der 5er-Version des Starter-Templates (damals hieß es auch noch ‚Roots‘, inzwischen umbenannt in ‚Sage‘) begonnen, inzwischen befindet sich die v9 in der Beta und bringt zahlreiche Neuerungen (Bootstrap 4, Laravel Blade, ES6, Webpack, Yarn, …) mit sich.

Das Roots-Team hat es geschafft, die WordPress-Entwicklung ins 21te Jahrhundert zu hieven. Und mir dabei eine Fülle von Funktionen und Tools zu offerieren, über die ich so nicht gestolpert wäre, geschweige denn gewusst hätte, wie man sie vernünftig einsetzt. Das war quasi mein zweiter „Aha“-Moment nach der Entdeckung von WordPress selbst 🙂

Was macht einen modernen Workflow aus?

Anders gefragt: Wo hakte es bei meinem bisherigen Workflow?

Das Sage-Theme mit seiner Build-Routine hat mein DEV-Leben zwar schon deutlich geschmeidiger gemacht, letztlich wurden die deployments aber immer noch händisch per FTP vorgenommen… Das bedeutet anfangs eine relative aufwendige Migration (Local -> Remote) und im weiteren Verlauf eine irgendwie holprige Synchronisation zwischen den verschiedenen Servern. Zudem hab ich mich arg vor der (Git-)Versionierung gesträubt – natürlich zu Unrecht, aber irgendwie waren die Vorteile als einzelner Entwickler nicht wirklich allzu ersichtlich.

Das kannst Du vom neuen WordPress-Workflow erwarten:

Optimierte WordPress-Templates (Struktur, Code / DRY)
Integrierte module bundler (mehr dazu hier), performante Build-Routine
Versionierung des Codes (Git)
Dependency management für WP-Plugins (Composer)
Virtueller Server / Entwicklungsumgebung (reproduzierbar = keine Abweichungen zwischen den verwendeten Umgebungen)
uvm.

Wem jetzt schon der Kopf raucht: Keine Sorge, so ging es mir auch anfänglich. Und ja, Ihr werdet vermutlich nicht über Nacht alles umstellen / erweitern können aber allein die Auseinandersetzung mit den aktuellen Programmierungstools und -routinen zahlt sich aus.

An dieser Stelle der Verweis auf den Artikel von Dave Kiss, der mich in die Verwendung von Trellis, Bedrock, Vagrant & Co. eingeführt hat – ich übernehme einige Aspekte aus dem Original-Post, außerdem waren auch andere Posts hilfreich für bestimmte Fragestellungen (siehe Ende des Artikels für weiterführende Links).

Voraussetzungen

Ich gehe für dieses Tutorial davon aus, dass du auf einem Mac unterwegs bist. Wenn dem nicht so ist, dann musst du einige Abweichungen für Windows-User beachten.

Terminal / CLI

Die Kommandozeile ist deine rechte Hand? Hervorragend, weiter gehts.

Wer oder was ist die Kommandozeile? Kein Problem, das haben wir gleich: Ab sofort wirst du unmittelbar mit deinem Computer interagieren und auf Menüs & Co. verzichten. Quasi wie in den ‚good old days‘ bei MS DOS.

Einfach das Terminal öffnen (unter Programme/Dienstprogramme), das ist unser Command Line Interface und nimmt die ganzen Befehle entgegen. Auch hiermit kann (und sollte) man sich vertraut machen, eine Möglichkeit ist u.a. das Tutorial von Wes Bos, auf ein paar Modifikationen und Add-Ons gehe ich in einem anderen Blog-Post ein (ich verwende statt des normalen Terminals z.B. iTerm 2 und lasse fish als shell laufen).

Wenn du Code-Schnipsel wie type this siehst, dann musst du diese wortwörtlich ins Terminal hacken und mit Enter bestätigen

Git / Versionierung

Solltest du noch keinen Schimmer von Git haben, dann lies dir bitte vorher den Starter-Guide durch – die Verwendung im weiteren Verlauf ist obligatorisch, du kommst also nicht drum rum… Auch hier: Du kannst nur gewinnen 😉

Dependencies bzw. lokale Installationen

Für die Nutzung von Trellis, Bedrock & Co. benötigen wir auf unserem Rechner

Homebrew
Git
Ansible
Composer
VirtualBox
Vagrant

Sollten diese Programme schon installiert sein dann kannst du diesen Absatz logischerweise überspringen.

Homebrew

Homebrew ist ein Package-Manager, der die Installation von anderen Paketen deutlich vereinfacht. Um Homebrew selbst zu installieren verwendest du

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

im Terminal. Nach der Installation kannst du mit brew doctor testen, ob alles in Ordnung ist. Ein alternativer Weg zur Verifizierung ist brew -v was dir die aktuelle Versionsnummer ausgibt (bei anderen Programmen gleichermaßen mit XYZ -v möglich).

Git, Ansible & Composer

Jetzt können wir auf Homebrew zurück greifen und andere Software mittels brew install XYZ aufspielen, in dem Fall also brew install git usw. – es geht auch in einem Schritt wenn wir brew install git ansible composer aufrufen.

Virtualbox

Wir benötigen die Virtualisierungssoftware Virtualbox, die dafür sorgt, dass wir virtuelle Server auf unserem lokalen System einrichten können. Diese Installation ist eine ’normale‘ Mac-Installation via DMG – einfach zur Downloadseite navigieren und die aktuelle Version herunterladen.

Vagrant

Vagrant funktioniert im Zusammenspiel mit der VirtualBox. Mittels Vagrant können fest definierte, reproduzierbare Serverumgebungen erstellt werden, d.h. man kann quasi den Server mit anderen Nutzern / Programmierern ’sharen‘ und so verhindern, dass Fehler durch Server- bzw. Versionsabweichungen produziert werden. Das vehindert dann Aussagen wie „bei mir funktioniert es aber“ und lässt die Serverumgebung identisch auf dem Zielsystem / beim Hoster einrichten.

Einfach downloaden und regulär als DMG installieren.

Terminalumgebung

Ich verwalte meine Seiten / Projekte über einen „htdocs“-Ordner auf einer zweiten internen Festplatte, d.h. meine Commands sind relativ spezifisch. Für diesen Artikel gehen wir also davon aus, dass du deine Projekte unter „USER-FOLDER / sites“ listest. Das ~-Zeichen ist relativ zu deinem User-Folder, d.h. mit cd ~/sites/ steuerst du (auch unabhängig vom aktuellen Ordner) deine Arbeitsumgebung an.

Bitte beachten und entsprechend anpassen, wenn Ihr eine andere Struktur verwenden möchtet.

Trellis

Trellis ist als „Server-Framework“ (basierend auf Ansible, VirtualBox und Vagrant) zu verstehen und übernimmt im weiteren Verlauf die Parität zwischen Development- und Produktionsumgebung.

Als Erstes erstellen wir einen neuen Ordner für unser Projekt (der Einfachheit halber nach der späteren Domain benannt – bitte entsprechend ersetzen bzw. einen für Euch passenden Namen wählen):

mkdir -p ~/sites/example.com
cd ~/sites/example.com

Hier hinein klonen wir jetzt das Trellis repo via

git clone --depth=1 git@github.com:roots/trellis.git ansible

Mittels rm -rf ansible/.git wird dann noch die im Repo bestehnde Git-File getilgt. In dem neuen Ordner example.com wurde der Unterordner ansible angelegt, dort befindet sich jetzt das geklonte Trellis repo.

Mit den folgenden Direktiven

cd ~/sites/example.com/ansible
ansible-galaxy install -r requirements.yml

werden die ansible-dependencies von Trellis installiert.

Bedrock

Bedrock ist als „Wrapper“ für WordPress zu verstehen – einerseits wird Euer Projekt so anders (besser) strukturiert und mittels composer könnt Ihr selbst (Plugin-)dependencies für WordPress festlegen. Das ist besonders hilfreich, wenn das Projekt von jmd. anderem als Euch bearbeitet werden soll und automatisiert die (Plugin-)Installation, was die Prozesse (nach der initialen Einrichtung) beschleunigt.

Hier eine Übersicht der neuen WP-Struktur:

├── composer.json
├── config
│   ├── application.php
│   └── environments
│       ├── development.php
│       ├── staging.php
│       └── production.php
├── vendor
└── web
    ├── app
    │   ├── mu-plugins
    │   ├── plugins
    │   ├── themes
    │   └── uploads
    ├── wp-config.php
    ├── index.php
    └── wp

Bedrock wird mittels

cd ~/sites/example.com
git clone --depth=1 git@github.com:roots/bedrock.git site

installiert.

Auch hier noch die bestehenden Git-File löschen: rm -rf site/.git

Ihr habt jetzt Trellis im Ordner ~/sites/example.com/ansible und Bedrock im Ordner ~/sites/example.com/site platziert, kudos!

Composer (Installation)

Wie bereits beschrieben wird Composer als PHP package-manager eingesetzt. In der Datei composer.json werden die dependencies festgelegt, dort finden sich per default neben WordPress selbst noch ein paar Standard-Plugins auch der WordPress Packagist über den Plugins aus dem offiziellen WP-Directory als dependency benutzt werden können.

Und so werden die Standard-Komponenten mittels Composer installiert:

cd ~/sites/example.com/site
composer install

Sage

Dieser Teil ist insofern optional, als dass man natürlich ein anderes Theme / Framework als Sage verwenden kann – ich schwöre aber auch hier auf die Roots-Suite und kann Euch Sage nur wärmstens ans Herz legen.

Wir klonen das Repo (Sage 8, die 9er-Version ist aktuell noch in Entwicklung) und entfernen die bestehende Git-Datei:

git clone --depth=1 --branch sage-8 git@github.com:roots/sage.git site/web/app/themes/sage
rm -rf site/web/app/themes/sage/.git

Alle weiteren Schritte bzgl. Sage entnehmt Ihr bitte den offiziellen Docs und/oder dem Demo-Projekt roots-example-project.com.

WordPress konfigurieren (Teil 1)

Damit haben wir alle Tools vorhanden und können zur eigentlichen WordPress-Installation übergehen.

Unter ansible/group_vars/* finden sich die verschiedenen Umgebungsvariablen (development / staging / production). Selbige geben Info darüber, wie unsere App (= WordPress) sich mit dem Server und der Datenbank verbinden kann, welche URL verwendet wird, etc. – Daten, die zuvor teilweise über die wp-config.php verwaltet wurden, werden so möglichst zentralisiert gehandhabt.

Development-Environment

Zuerst gehen wir in den development-Ordner und öffnen dort die Datei ~/sites/example.com/ansible/group_vars/development/wordpress_sites.yml in unserem Text-Editor (nachdem ich TextMate + Atom ausprobiert habe kann ich mittlerweile SublimeText am wärmsten empfehlen).

wordpress_sites:
  example.com:
    site_hosts:
      - canonical: example.dev
        redirects:
          - www.example.dev
    local_path: ../site # path targeting local Bedrock site directory (relative to Ansible root)
    admin_email: admin@example.dev
    multisite:
      enabled: false
    ssl:
      enabled: false
      provider: self-signed
    cache:
      enabled: false

Hier ersetzt Ihr example.com durch Eure Live-URL bzw. den Arbeitstitel (s.u.) und example.dev durch die (frei vergebbare, lokale) Dev-URL. Die anderen Settings sind für die lokale Entwicklung nicht wirklich relevant (ausser natürlich Ihr wollt den Cache explizit testen, ein Multi-Site-Projekt entwickeln o.ä.)…

WICHTIG: example.com fungiert hier lediglich als ‚Arbeitstitel‘ und beschreibt keine URL, d.h. hier hängt keine Funktionalität dran! Ich komme da gerne mal durcheinander (à la „Live-URL in der DEV-Umgebung?“) und verwende als Projekttitel lieber einen eindeutigeren String bzw. einfach die Domain ohne TLD.

Weiter gehts mit der Datei ../ansible/group_vars/development/vault.yml – hier wird der Datenbank-Zugang festgeschrieben:

# Variables to accompany `group_vars/development/wordpress_sites.yml`
vault_wordpress_sites:  
  example.com:
    admin_password: example_wordpress_admin_password
    env:
      db_password: example_dbpassword

Wieder die example.com durch Eure Live-URL bzw. den Arbeitstitel (s.o.) ersetzen und die Connection-Details eintragen – letztere legt Ihr hier erstmalig fest, d.h. es muss keine Datenbank erstellt werden, das macht alles Trellis / Ansible für uns!

Da diese Passwörter hier quasi als plain-text vorliegen empfiehlt es sich, den vault auch entsprechend abzuschließen.

Vagrant Up!

Halbzeit! Gratulation, wir schmeissen jetzt zum ersten Mal unseren lokalen Server an:

cd ~/sites/example.com/ansible
vagrant up

Die erste Runde dauert etwas länger (bis zu 10 Minuten), entsprechend kann jetzt mit guten Gewissen pausiert werden.

WICHTIG: Du musst anfangs dein Master-Passwort eingeben, damit Vagrant seinen Job machen kann (bzw. die /etc/hosts beschreiben kann um dort die Dev-URL zu hinterlegen). Ich selbst verpenne so was durchaus mal und verlängere damit unnötig die Wartezeit, weshalb die Trigger bei iTerm mir sehr gelegen kommen. Ich habe einfach einen Alert für den String „To proceed, enter your password“ erstellt, das verhindert zuverlässig, dass ich solche Terminal-Prompts verpasse.

Noch etwas: Beim Ausprobieren und Rumfrickeln mit den Konfigurationsdateien bzw. den Vagrant-Settings kam ich irgendwann nicht weiter, weil das (neue / geänderte) Projekt nicht erkannt wurde o.ä. – das lag daran, dass die ‚alte‘ URL/IP noch in der etc/hosts festgeschrieben war. Einfach öffnen, die betreffenden Zeilen löschen, speichern und dann per Terminal-Befehl (dscacheutil -flushcache; sudo killall -HUP mDNSResponder) eine Aktualisierung erzwingen.

Nachdem der Build-Prozess abgeschlossen ist könnt Ihr jetzt Eure Seite via example.dev (bzw. wie auch immer sie heissen mag) aufrufen!

Composer

Plugins hinzufügen

Um ein weiteres Plugin als dependency zu listen würdet Ihr dem Block "require": { ... } in der Datei ~/sites/example.com/site/composer.json einfach eine weitere Zeile mit dem betreffenden Plugin hinzufügen, das könnte dann so aussehen:

"require": {
  "php": ">=5.6",
  "composer/installers": "~1.0.12",
  "vlucas/phpdotenv": "^2.0.1",
  "johnpbloch/wordpress": "4.7.2",
  "oscarotero/env": "^1.0",
  "roots/wp-password-bcrypt": "1.0.0",
  "wpackagist-plugin/autodescription": "2.8.2"
}

Hier habe ich am Ende der bestehenden dependencies einfach The SEO Framework mittels wpackagist hinzugefügt. Auch ‚premium plugins‘ lassen sich einbinden, das Procedere ist nur unwesentlich anders / aufwendiger.

composer install

Damit werden die neuen dependencies entsprechend installiert. Schau schnell im Backend auf der Plugin-Seite nach…! 🙂

Plugins aktualisieren

Anstelle wie bisher über das WP-Backend die Plugins zu aktualisieren werden diese nun durch Bedrock / Composer gehandhabt – das macht deshalb Sinn, weil Ihr so quasi ‚gezwungen‘ werdet, die Updates erst mal lokal / im der Entwicklungsumgebung durchzuführen und mögliche Fehler wenn dann hier anfallen. Das schützt die Live-Umgebung vor „white screens of death“, genereller Downtime, etc.

Um eine Aktualisierung zu erwirken müsst Ihr die dependency der Plugins in der Datei ~/sites/example.com/site/composer.json ‚uppen‘, erst wenn dort eine höhere Version verlangt wird nimmt Composer ein Update vor!

Das Update selbst triggert Ihr dann (innerhalb ~/sites/example.com/site/) folgendermaßen:

composer update

Sollte etwas schief laufen dann einfach die Versionsnummer anpassen / zurücksetzen.

Puh, ganz schön viel Holz… Aber wo wir schon soweit gekommen sind, wollen wir den Bob auch in die Bahn werfen a.k.a. die Seite ans Netz bringen, oder? Im weiteren Verlauf geht es also darum, das lokale Projekt im WWW erreichbar zu machen.

Hosting / Digital Ocean

Ich bin eigentlich großer Freund und Verfechter von Uberspace (kompetitives Angebot, super Team + genialer Support) ABER weil einerseits der ganze Build-Prozess bei Trellis exemplarisch mit Digital Ocean beschrieben wird und andererseits sich das Hosting dort extrem performant und professionell anfühlt (Stichworte: SSD, Monitoring, Scaling, Setup, …) empfehle ich Euch, das Projekt dort zu hosten.

Das kleinste ‚Droplet‘ kostet schmale 5,- USD / Monat und über diesen Empfehlungslink bekommt Ihr zum Start 10,- USD bzw. 2 Monate geschenkt – quasi ein ’no brainer‘ wenn man so will…

Ein ‚Droplet‘ einrichten

Die (virtuellen) Server werden bei Digital Ocean Droplets genannt und lassen sich sehr einfach aufsetzen und bedienen.

Für die Verbindung zum Server benötigen wir einen SSH-Key – wenn Ihr noch keinen haben solltet dann bitte jetzt anlegen. Das macht die ganzen Abläufe und Deploys nebenbei auch viel sicherer als der Login per Passwort (die SSH-Keys sind an die physischen Geräte geknüpft, d.h. um ‚Einzubrechen‘ braucht es direkten Zugriff auf Euren Rechner). Eine Einführung in die Erstellung und Verwendung von SSH-Keys findet Ihr in den GitHub-Docs.

Einfach auf „Create Droplet“ klicken und den Einrichtungshinweisen mit folgendem Setup folgen:

Choose an Image: Ubuntu on 14.04 x64
Choose a Size: $5/month
Choose a Datacenter Region: Frankfurt
Select additional options: keine
Add your SSH Keys: Hier deinen SSH-Key hinterlegen
Choose a Hostname: Name deines Projekts / deine URL / whatever

Nach ca. einer Minute ist die Einrichtung abgeschlossen und jetzt benötigen wir die IP-Adresse des Droplets – diese findet man im Reiter „droplet details“, bitte notieren (brauchen wir noch).

Domain verknüpfen

Da das Droplet aktuell nur unter der IP-Adresse zu erreichen ist werden wir jetzt unsere Wunsch-Domain hinterlegen. Das geht über den Menüpunkt „Networking“ von statten und es werden zwei Einträge getätigt:

Domain: Unsere Domain = example.com
Droplet or Custom IP: einfach das neue Droplet auswählen

Speichern und voilá!

Solltet Ihr noch keine Domain Euer eigen nennen und auf der Suche nach einem Registrar sein dann empfehle ich wahlweise Strato oder NameCheap, beide bieten günstiges Domain-Hosting inkl. aller notwendigen DNS-Einstellung an.

Projekt-Push zu GitHub

Die Versionierung mit Git ist ein wichtiger Zwischenschritt im Deploy-Prozess – nachdem wir lokal entwickelt (oder eine Änderung vorgenommen) haben wird der Code erst einmal zu GitHub ‚geschoben‘ und dort als neue Version hinterlegt. Der eigentliche Deploy zum Live-Server bzw. -Droplet erfolgt basierend auf dem GitHub-Repository, d.h. Trellis setzt voraus, dass dort der aktuelle Code liegt (also lokal <--> Git <--> remote statt lokal <--> remote).

Ich habe es anfangs alternativ zu GitHub mit Bitbucket versucht weil dort auch im kostenfreien Paket private Repositories enthalten sind, fand die Übersetzung aber nicht wirklich intuitiv was den Build-Prozess anbelangt und habe mich dann für einen Pro-Account bei GitHub entschieden (7,- € / Monat). Zum Testen ist aber ein öffentliches Repo völlig ausreichend, seht nur zu, dass Ihr dort keine sensiblen (Kunden-)Daten hinterlegt habt o.ä.

Fix ein neues Repo angelegt (bitte keine automatische README erstellen lassen) und dann im Terminal:

cd ~/sites/example.com/site 
git init  
git add .  
git commit -am "First commit"

Damit haben wir die Git-Versionierung für die Seite aktiviert und den ersten Commit getätigt. Da u.U. bereits eine Git-Datei bzw. eine Versionierung vorhanden war müssen wir erst einmal die bestehenden remote-location(s) entfernen, das testet / macht Ihr mit

git remote # Listet die verfügbaren remote-locations
git remote remove origin # Entfernt die location "origin"

WordPress konfigurieren (Teil 2)

Bei meiner Deploy-Routine gibt es nur DEV + LIVE, habe bis dato noch keine staging-Umgebung benötigt… Deshalb überspringen wir diesen Punkt und gehen direkt zur Einrichtung der Live-Umgebung über.

Live-Einstellungen

in der Datei ansible/hosts/production wird nun die IP-Adresse unseres Droplets eingesetzt:

# Add each host to the [production] group and to a "type" group such as [web] or [db].
# List each machine only once per [group], even if it will host multiple sites.

[production]
deine.droplet.IP.adresse

[web]
deine.droplet.IP.adresse

Quasi identisch zu den Einstellungen die wir beim Setup der Development-Umgebung vorgenommen haben müssen wir jetzt auch für die Produktions-Umgebung die Variablen passend setzen. Zuerst die ~/sites/example.com/ansible/group_vars/production/wordpress_sites.yml:

# Documentation: https://roots.io/trellis/docs/remote-server-setup/
# `wordpress_sites` options: https://roots.io/trellis/docs/wordpress-sites
# Define accompanying passwords/secrets in group_vars/production/vault.yml

wordpress_sites:
  example.com:
    site_hosts:
      - canonical: example.com
        redirects:
          - www.example.com
    local_path: ../site # path targeting local Bedrock site directory (relative to Ansible root)
    repo: git@github.com:example/example.com.git # replace with your Git repo URL
    # repo_subtree_path: site # relative path to your Bedrock/WP directory in your repo
    branch: master
    multisite:
      enabled: false
    ssl:
      enabled: true
      provider: letsencrypt
    cache:
      enabled: true
      duration: 30s

Jetzt noch die Passwörter in der ansible/group_vars/production/vault.yml eintragen:

# Documentation: https://roots.io/trellis/docs/vault/
vault_mysql_root_password: ERSTES-PASSWORT

# Documentation: https://roots.io/trellis/docs/security/
vault_users:
  - name: "{{ admin_user }}"
    password: NOCH-EIN-PASSWORT
    salt: "generateme"

# Variables to accompany `group_vars/production/wordpress_sites.yml`
# Note: the site name (`example.com`) must match up with the site name in the above file.
vault_wordpress_sites:
  example.com:
    env:
      db_password: EIN-WEITERES-PASSWORT
      # Generate your keys here: https://roots.io/salts.html
      auth_key: "generateme"
      secure_auth_key: "generateme"
      logged_in_key: "generateme"
      nonce_key: "generateme"
      auth_salt: "generateme"
      secure_auth_salt: "generateme"
      logged_in_salt: "generateme"
      nonce_salt: "generateme"

Well done!

Verbindung zum GitHub-Account

Innerhalb der Datei ansible/group_vars/all/users.yml hinterlegen wir die Informationen, welche User (bzw. welche SSH-Keys) deployments vornehmen dürfen. Die einzigen Anpassungen, die hier nötig sein sollten, sind in den Zeilen mit

# https://github.com/username.keys

zu finden. Einfach durch Euren GitHub-Usernamen ersetzen und ab sofort darf der GitHub-Account die besagten deployments vornehmen. Wenn im Team an einem Projekt gearbeitet wird dann könnte man hier weitere Zeilen mit anderen GitHub-Usern einsetzen.

Unter Umständen müsst Ihr auch den Pfad zu Eurem lokalen SSH-Key anpassen (~/.ssh/id_rsa.pub), gehe aber kaum davon aus…

„Spin your Droplet“ / Provisioning

Unser Droplet läuft zwar die ganze Zeit schon, ist aber abgesehen von dem eingangs installierten bzw. ausgewählten OS (Ubuntu) noch völlig jungfräulich. Jetzt glänzt der neue Workflow insofern, als dass wir mit einem einfachen Command den Server komplett einrichten können – und zwar identisch zu unserem lokalen Server, mit allem Schnick und Schnack.

cd ~/sites/example.com/ansible && ansible-playbook server.yml -e env=production

Das dauert jetzt ein wenig, einfach zurücklehen…

Für mich ist ein besonderer Clou, dass der so aufgesetzte Server ohne große Konfiguration von Hause aus ‚cutting edge‘-Features mitbringt, u.a.

Nginx
MariaDB (MySQL drop-in replacement)
PHP 7.1 (+ extensions)
Composer
WP-CLI
sSMTP
Memcached
Fail2ban
ferm (firewall)
Mailhog

Deployment

Es ist soweit!! Jetzt ernten wir die Früchte unserer Arbeit und launchen endlich das WordPress-Projekt.

Für das deployment wird sich immer an dem auf GitHub hinterlegten Code bedient, entsprechend müsst Ihr dafür sorgen, dass Ihr mit Commits / Pushes auf dem aktuellen Stand seid. Ein einfacher Weg, um dies zu testen ist git status – wenn noch nicht synchronisiert wurde dann bitte jetzt per git push origin master erledigen.

Jetzt schieben wir den GitHub-Code auf unseren Live-Server mittels

cd ~/sites/example.com/ansible && ./deploy.sh production example.com

That’s it, folks. Das Projekt bzw. die Änderungen daran sind live, die Versionierung steht und wir können uns getrost zumindest angetäuscht auf die Schulter klopfen.

Anmerkungen & Weiterführende Links

Ich möchte nochmals auf den Artikel von Dave Kiss verweisen, der mich bei der Einrichtung begleitet hat und den ich Inspiration verwendet habe. Die Motivation für den eigenen Blog-Artikel war letztlich der Wunsch, den Workflow auch auf Deutsch zugänglich zu machen und mir selbst eine Anleitung für kommende Projekte an die Hand zu geben.

Bei Anregungen oder Fragen einfach einen Kommentar hinterlassen.

Hier noch zwei weitere Artikel zum Thema, die ebenfalls sehr hilfreich sind / waren: