Ein moderner Entwicklungs-Workflow für WordPress

Um meinen Kollegen Chad zu zitieren: WordPress „ist seit seiner Veröffentlichung im Jahr 2003 nach wie vor enorm beliebt“. Für viele ist WordPress nach wie vor das mit Abstand am einfachsten zu implementierende Content-Management-System (CMS), das in den meisten Anwendungsfällen eine schnelle Markteinführung ermöglicht. Es gibt so viel hochwertiges Material für WordPress, sei es open source oder Premium-Software, dass man im Handumdrehen wunderschöne Websites mit einem benutzerfreundlichen CMS erstellen und betreiben kann.

Das stimmt, aber…

Es gab eine Zeit in meiner Karriere, in der die Entwicklung von CMS-Lösungen für Unternehmen meine Hauptaufgabe war. In diesen Kreisen war die Vorstellung weit verbreitet, dass WordPress ein Spielzeug sei, das für Projekte auf Unternehmensebene ungeeignet sei. Das galt besonders, wenn ich mit Teams zusammenarbeitete, die bereits mit Best Practices vertraut waren, die später als 12-Factor-App-Methodik bekannt wurden. Die traditionelle Art, „WordPress zu nutzen“, ließ sich nicht ohne Weiteres mit dem 12-Factor-Ansatz vereinbaren.

WordPress, traditionell

Traditionell bestand die Codebasis eines WordPress-Projekts aus dem gesamten WordPress-Kern sowie allen Plugins und Themes, die für das Funktionieren des Projekts notwendig waren. Die gesamte Codebasis wurde dann auf einem Hosting-Anbieter deiner Wahl bereitgestellt, meist über – hust – (S)FTP. Das leicht weiterentwickelte Modell sieht vor, dass genau dieselbe Codebasis in ein Quellcode-Verwaltungssystem deiner Wahl eingecheckt wird, wobei ein CI-Tool sie auf die Server des Hosting-Anbieters überträgt.

WordPress-Automatische Hintergrund-Updates

Automatische Hintergrund-Updates wurden in WordPress 3.7 für den WordPress-Kern eingeführt und später auf Plugins, Themes und Übersetzungsdateien ausgeweitet. Zwar ist ein gewisses Maß an Automatisierung bei Updates definitiv wünschenswert, doch die Art und Weise, wie dies in WordPress umgesetzt ist (d. h. Updates vor Ort), bedeutet: Wenn sich deine Codebasis in einem Repository befindet, wird sie schnell veraltet sein, und du musst die Updates im Repo separat verwalten, um spätere Probleme und Regressionen zu vermeiden. Wenn du stattdessen alles allein über FTP verwaltest, bedeutet das, dass jedes Update ohnehin sehr riskant ist. So oder so kann ich dir garantieren, dass die Sache schnell zu einem Albtraum eskalieren wird.

Moment, das ist noch nicht alles

Es wird noch komplizierter. Um Chad noch einmal aus demselben Artikel zu zitieren:

„Viele Hosting-Lösungen, darunter auch Upsun, erzwingen zur Laufzeit schreibgeschützte Dateisysteme. Diese Lösungen stellen ein hochgradig reproduzierbares Build-Image bereit, das sich aus deiner Codebasis und ihrem explizit definierten Build-Prozess ergibt, die beide in der Versionskontrolle festgehalten werden. [...] Externer Code (Abhängigkeiten) [...] und im Idealfall auch die Definitionen deiner Infrastruktur selbst werden in exakten Versionen festgehalten, sodass dein gesamter DevOps-Prozess von Anfang bis Ende wiederholbar und reproduzierbar ist.“

Das ist auch aus Sicherheitsgründen hervorragend. Doch wie du vielleicht schon bemerkt hast, steht dies in völligem Widerspruch zu der Art und Weise, wie WordPress automatische Updates handhabt, und diese müssen möglicherweise vollständig deaktiviert werden, wenn ein schreibgeschütztes Dateisystem verwendet wird.

Bedrock und Composer für moderne WordPress-Entwicklung nutzen

In seinem Artikel spricht Chad darüber, wie Bedrock „composer“ nutzt, um einen moderneren Ansatz für die WordPress-Entwicklung zu bieten – auch dank der großartigen Arbeit hinter WordPress Packagist. Chad zeigt, dass es durch die Kombination dieser Bemühungen mit unseren eigenen „Source Operations“ möglich ist, einen hohen Grad an Automatisierung bei Updates zu erreichen, mit besserer Kontrolle über die Versionen und einer höheren Wiederholbarkeit des Prozesses.

Unser Ziel: Effizienter WordPress-Workflow und -Entwicklung

Das Ziel dieses Artikels ist es, noch einen Schritt weiter zu gehen und zu zeigen, wie man Upsun mit anderen Tools kombinieren kann, um den besten WordPress-Workflow – einschließlich automatischer Updates – zu erreichen, der auch ein höheres Maß an Komplexität, Kontrolle und Konfiguration ermöglicht.

Dazu werde ich zunächst der Anleitung „Deploy Composer-based WordPress on Upsun“ aus der Upsun-Dokumentation folgen. 

Maximiere die Automatisierung mit einer Vorlage und WordPress-Workflow-Plugins

Nachdem ich der Anleitung gefolgt bin, habe ich mein Experiment so angepasst, dass die Codebasis für zwei Websites (ita und eng) gehostet wird, wobei beide: 

• mit WordPress.org erstellt wurden
• über eine rudimentäre „Distro“-Unterstützung verfügen
• auf Upsun in einer Multi-App-Konfiguration bereitgestellt werden
• ihre gesamte Codebasis über composer verwaltet wird, dank johnpbloch/wordpress, WordPress Packagist (für Plugins und Themes) und inpsyde/wp-translation-downloader (ein „composer“-Plugin zur Verwaltung von WordPress-Übersetzungen für Core, Plugins und Themes)
• lassen ihre Abhängigkeiten automatisch von Dependabot aktualisieren
• werden ihre Dependabot-PRs automatisch von Mergify zusammengeführt, wenn die Builds erfolgreich sind
• lassen bei jedem PR-Merge neues Programm automatisch in der Produktivumgebung bereitstellen
• nutzen Redis als Backend-Caching
• nutzen Cloudflare als CDN
• GitHub Actions als zusätzliches CI/CD-Tool und Cron-Scheduler nutzen

Zusätzlich zu den oben genannten Punkten:

• Die Website ita nutzt Elasticsearch
• Die Website eng nutzt Algolia

Und schließlich:

• Das Experiment ist als GitHub-Repository gedacht, das über unsere GitHub-Integration mit einem Upsun-Projekt verknüpft ist.

Wenn du denkst, dass dieses Experiment aus einem realen Projekt hervorgegangen ist, dann liegst du richtig!

Im weiteren Verlauf dieses Artikels werde ich mich auf die Punkte konzentrieren, die zeigen, wie es bei diesem Experiment darum geht, deinen WordPress-Entwicklungsworkflow so weit wie möglich zu automatisieren, und ich werde es vermeiden, auf andere Details einzugehen. Wenn du also mehr Einblicke in die Composer-basierte WordPress-Entwicklung erhalten möchtest, schau dir bitte Chads Artikel an oder direkt den Code in meinem Repository.

WordPress-Installation mit Distros und Composer automatisieren

Distros oder Installationsprofile sind im Wesentlichen eine Möglichkeit, eine eigene Standard-Installationskonfiguration zu erstellen. Während manche Software dies bereits von Haus aus unterstützt, ist das bei WordPress nicht der Fall. Mein Ziel war es, die Installation beim ersten Deployment vollständig zu automatisieren, also habe ich beschlossen, die Sache selbst in die Hand zu nehmen.

Die rudimentäre Unterstützung, die ich dafür implementiert habe, stützt sich auf zwei Dinge. Erstens einen maßgeschneiderten Abschnitt in der Datei „composer.json“:

  "distro": {
    "default-theme": "lovecraft",
    "enable-plugins": [
      "academic-bloggers-toolkit",
      "akismet",
      "contextual-category-widget",
      "elasticpress",
      "jetpack",
      "really-simple-ssl",
      "redis-cache",
      "series",
      "social-pug",
      "wp-cloudflare-page-cache",
      "wpforms-lite"
    ]
  },

Zweitens ein Skript, das die Informationen in diesem Abschnitt nutzt, um einige Ersteinstellungen vorzunehmen:

#!/usr/bin/env bash

cd wordpress
if ! wp core is-installed; then
  WP_URL=$(echo $PLATFORM_ROUTES  | base64 --decode | jq -r 'keys[]' | grep $PLATFORM_APPLICATION_NAME | grep https | grep www)
  wp core install --url="${WP_URL}" --title="Modern WordPress" --admin_user=admin --admin_password=changeme --admin_email=change@me.com
  DEFAULT_THEME=$( jq -r '.[ "distro" ][ "default-theme" ]' ../composer.json )
  wp theme activate ${DEFAULT_THEME}
  jq -r '.[ "distro" ][ "enable-plugins" ][]' ../composer.json |
  while read PLUGIN; do
    wp plugin activate ${PLUGIN}
  done
else
  wp core update-db
fi

Das Skript wird dann als Teil des Hooks „deploy“ in Upsun ausgeführt, d. h. nachdem die Build-Phase WordPress und die anderen Abhängigkeiten über „composer“ heruntergeladen und erstellt hat. Das Ergebnis ist eine vollständig installierte WordPress-Anwendung, wodurch du dir den (wenn auch einfachen) manuellen WordPress-Setup-Assistenten sparen kannst.

Falls du dich fragst, warum wir nicht einfach den Abschnitt „scripts.postbuild“ auf composer.json genutzt haben, um ein solches Skript auszuführen: Der Hauptgrund ist, dass während der „build“-Phase (wenn „composer“ ausgeführt wird) der Datenbankdienst noch nicht verfügbar ist, da die Build-Phase nur darauf ausgelegt ist, ein bereitstellbares Artefakt zu erstellen.

Automatische WordPress-Datenbank-Updates

Wir werden später noch auf Code-Updates eingehen, aber da wir oben bereits auf das Skript verwiesen haben, möchte ich hervorheben, dass dasselbe Skript auch die Aktualisierung der Datenbank übernimmt, falls es Code-Updates gibt, die einen solchen Vorgang erfordern.

Wenn du schon einmal mit WordPress gearbeitet hast, weißt du, dass du zumindest bei einem Upgrade des WordPress-Kerns möglicherweise eine sehr einfache Routine ausführen musst, die das Datenbankschema entsprechend aktualisiert. Dies kann über die Admin-Oberfläche erfolgen, wo dir eine einfache Schaltfläche zum Anklicken angezeigt wird; oder es kann über das „wp-cli“ erfolgen. Letzteres nutzt dieses Skript (siehe, wie das „wp-cli“ installiert wird): Wenn WordPress bereits installiert ist, führt es bei jedem Deployment einfach eine Datenbank-Update-Routine aus, die nur dann etwas tut, wenn es etwas zu tun gibt.

Automatisierte Abhängigkeits-Updates

Dependabot gehört schon seit geraumer Zeit zur GitHub-Familie und bietet einen kostenlosen Tarif für öffentliche Repositories an; außerdem unterstützt es PHP+Composer. Du kannst es so konfigurieren, dass du festlegst, welche Art von Upgrades du an deinen Abhängigkeiten durchführen möchtest, und der Bot wird regelmäßig Pull-Requests ausstellen, um veraltete Abhängigkeiten zu vermeiden. Unsere Konfiguration sieht so aus:

version: 2
updates:
  - package-ecosystem: composer
    directory: "/eng"
    schedule:
      interval: daily
    open-pull-requests-limit: 10
    ignore:
      - dependency-name: wpackagist-plugin/really-simple-ssl
        versions:
          - 4.0.10
  - package-ecosystem: composer
    directory: "/ita"
    schedule:
      interval: daily
    open-pull-requests-limit: 10

Für beide Apps haben wir eine tägliche Überprüfung der Abhängigkeiten (denk daran, der WordPress-Kern selbst ist eine Abhängigkeit!), mit einer Obergrenze von maximal 10 offenen Pull-Anfragen gleichzeitig. Du kannst auch clevere Dinge tun, wie bestimmte Versionen einer Abhängigkeit zu ignorieren, wenn du zum Beispiel weißt, dass sie fehlerhaft sind.

Du fragst dich vielleicht: Ok, aber wie sorgt das automatische Eröffnen von PRs eigentlich für automatische Abhängigkeits-Updates? Nun, das tut es nicht :)

Hier kommt Auto-Merge ins Spiel

Das automatische Eröffnen von Unmengen von PRs wird dir das Leben kaum erleichtern und deine Abhängigkeiten mühelos auf dem neuesten Stand halten. Daher muss ein Tool wie Dependabot mit einem anderen kombiniert werden, das Merge-Queues und die Möglichkeit bietet, Pull-Requests, die bestimmte Kriterien erfüllen, automatisch zusammenzuführen. Ich habe Mergify verwendet, aber es ist wahrscheinlich, dass du in naher Zukunft GitHub-Merge-Queues nutzen kannst, falls GitHub beschließt, ein System ähnlich wie Mergify zu implementieren, bei dem du ein Muster für die PRs definieren kannst, die automatisch zusammengeführt werden sollen:

pull_request_rules:
  - name: automatic merge for Dependabot pull requests
    conditions:
      - author~=^dependabot(|-preview)\[bot\]$
      - status-success=upsun
    actions:
      merge:
        method: squash

Die obige Konfiguration weist Mergify im Wesentlichen an, alle von Dependabot erstellten PRs, die erfolgreich auf Upsun gebaut wurden, automatisch zu squashen und zusammenzuführen.

Wie ich bereits erwähnt habe, ist dieses Experiment für die Nutzung über die GitHub-Integration mit Upsun gedacht. Dadurch ist es möglich, dass jeder von Dependabot erstellte PR über eine zugehörige Preview-Umgebung verfügt, in der der Build und die Bereitstellung der Anwendung mit den aktualisierten Abhängigkeiten stattfinden. Dank der Integration mit GitHub wird dieser Prozess als Statusprüfung für die PRs im Repository hinzugefügt. Diese Statusprüfung nutzt Mergify hier, um sicherzustellen, dass mit dem PR alles in Ordnung ist; wenn ja, wird der PR zusammengeführt.

Das ist natürlich eine sehr einfache Konfiguration; nichts hindert uns daran, zusätzliche Bedingungen für die „status-success“ in der Konfiguration zu verwenden, beispielsweise Unit-Tests, die von einer CI ausgeführt werden, oder ähnliche Maßnahmen. Je mehr Automatisierung und Statusprüfungen du einsetzt, desto sicherer kannst du sein, dass der PR automatisch zusammengeführt werden kann.

Kontrolle und Sicherheit mit Upsun und Automatisierungstools

Die Kombination von Tools wie Dependabot, Mergify und Upsun gibt dir ein viel höheres Maß an Kontrolle und Sicherheit über deinen Prozess der automatisierten Updates für den WordPress-Core, Plugins, Themes und Übersetzungsdateien. Denn bei jedem Update kannst du sicher sein, dass eine produktionsähnliche Umgebung mit den Änderungen aufgebaut wird und zusätzliche Tests durchgeführt werden können, um sicherzustellen, dass alles weiterhin einwandfrei funktioniert. Du kannst entscheiden, ob du nur Minor-Versionen oder auch Major-Versionen automatisch aktualisieren möchtest. Du kannst bestimmte Versionen oder bestimmte Elemente (zum Beispiel ein bestimmtes Plugin oder Theme) ausschließen. Und vieles mehr. Du hast eine fein abgestimmte Kontrolle, mehr Leistung und ein höheres Maß an Sicherheit.

Weiterentwicklungen

Der WordPress-Entwicklungsworkflow, den ich dir hier gezeigt habe, lässt sich auf erweiterte Szenarien anwenden. Du kannst Mergify beispielsweise so konfigurieren, dass es unter den richtigen Bedingungen andere oder sogar alle Arten von PRs automatisch zusammenführt (denk daran, dass auch manuelle Peer-Reviews und andere manuelle Schritte als Statusprüfungen hinzugefügt werden können). Du kannst diesen Workflow auch extrahieren und auf andere Arten von Anwendungen anwenden, nicht nur auf WordPress.

Eine Möglichkeit, dies jedoch wirklich auf eine neue Ebene zu heben, ist die Automatisierung von Infrastruktur-Upgrades! Alles, was du dafür brauchst, ist eine Möglichkeit zu prüfen, ob es eine neue Version eines der von Upsun verwalteten Dienste gibt, die du in deinem Projekt nutzt, und dann einen neuen PR mit dem Update zu erstellen (genau wie Dependabot es bei Anwendungsabhängigkeiten macht). Sobald du diese Komponente hast (die in deinem externen CI-Tool, wie z. B. GitHub Actions, implementiert werden könnte), könntest du Mergify so konfigurieren, dass diese PRs automatisch zusammengeführt werden – wiederum unter den richtigen Bedingungen.

Starte die Automatisierung deines WordPress-Entwicklungs-Workflows mit Upsun

Während du darauf wartest, dass die automatische Aktualisierung deiner Infrastruktur möglich wird (ich verspreche dir, dass ich meine Vorlage mit genau diesen Features aktualisieren werde, sobald dies möglich ist), kannst du diese Vorlage und diesen Workflow bereits jetzt nutzen und deinem Entwicklungsteam wertvolle Zeit sparen:

• Fork dieses Experiment auf GitHub
• Erstelle ein neues Upsun-Projekt
• Verbinde dein geforktes Repository über unsere GitHub-Integration mit dem neu erstellten Projekt (dafür musst du unsere CLI installieren).

Und wie immer weißt du, wo du uns findest, falls du uns brauchst!

Nützliche Links

• WordPress | Upsun-Dokumentation
• Vanilla WordPress auf Upsun bereitstellen