Ein moderner Entwicklungs-Workflow für WordPress

Um meinen Kollegen Chad zu zitieren, ist WordPress "seit seiner Veröffentlichung im Jahr 2003 ungeheuer populär geblieben". Für viele ist WordPress nach wie vor das Content Management System (CMS), das am einfachsten zu implementieren ist und in den meisten Anwendungsfällen eine schnelle Markteinführung ermöglicht. Es gibt so viel qualitativ hochwertiges Material für WordPress, sei es Open Source Software (OSS) oder Premium, dass man in kürzester Zeit schöne Websites mit einem einfach zu bedienenden CMS erstellen kann.

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 verbreitet, WordPress sei ein Spielzeug, das sich nicht für Unternehmensprojekte eignet. Dies galt insbesondere dann, wenn ich mit Teams zusammenarbeitete, die bereits in die Best Practices eingeweiht waren, die später als die 12-Faktor-App-Methodikbekannt wurden . Die traditionelle Art und Weise, WordPress zu verwenden, konnte die 12-Faktoren-Methode nicht so einfach übernehmen.

WordPress, traditionell

Traditionell bestand die Codebasis eines WordPress-Projekts aus dem gesamten WordPress-Kern sowie aus allen Plugins und Themes, die für das Projekt erforderlich waren. Die gesamte Codebasis wurde dann auf einem Hosting-Server der Wahl bereitgestellt, in der Regel per(S)FTP. Das leicht weiterentwickelte Modell besteht darin, dass dieselbe Codebasis in ein Quellcode-Verwaltungssystem der Wahl eingecheckt wird, wobei ein CI-Tool sie auf die Server des Hostings überträgt.

Navigieren durch die automatischen Hintergrundaktualisierungen von WordPress

Automatische Hintergrundaktualisierungen wurden in WordPress 3.7 für den WordPress-Kern eingeführt und später auf Plugins, Themes und Übersetzungsdateien ausgeweitet. Ein gewisser Automatisierungsgrad bei Aktualisierungen ist zwar durchaus wünschenswert, aber die Art und Weise, wie dies in WordPress implementiert ist (d. h. Aktualisierungen vor Ort), bedeutet, dass Ihre Codebasis in einem Repository schnell veraltet und Sie die Aktualisierungen in dem Repository nebenbei verwalten müssen, um Probleme und Regressionen zu vermeiden. Wenn Sie stattdessen alles allein über FTP verwalten, bedeutet das, dass jede Aktualisierung ohnehin sehr riskant ist. So oder so kann ich Ihnen garantieren, dass sich die Dinge schnell zu einem Albtraum entwickeln werden.

Moment, das ist noch nicht alles

Es wird noch komplizierter. Um noch einmal Chad 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 Ihrer Codebasis und dem explizit definierten Build-Prozess ergibt, die alle in der Versionskontrolle hinterlegt sind. [...] Externer Code (Abhängigkeiten) [...] und idealerweise die Definitionen Ihrer Infrastruktur selbst werden auf exakte Versionen festgelegt, so dass Ihr gesamter DevOps-Prozess von Anfang bis Ende wiederholbar und reproduzierbar ist."

Dies ist auch aus Sicherheitsgründen hervorragend. Wie Sie vielleicht schon gemerkt haben, kollidiert es jedoch völlig mit der Art und Weise, wie WordPress mit automatischen Updates umgeht, und diese müssen möglicherweise vollständig deaktiviert werden, wenn ein schreibgeschütztes Dateisystem verwendet wird.

Nutzung von Bedrock und Composer für die moderne WordPress-Entwicklung

In seinem Artikel spricht Chad darüber, wie Bedrock den Composernutzt , 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 guten Grad an Automatisierung bei Updates zu erreichen, mit einer größeren Kontrolle über Versionen und einer größeren Wiederholbarkeit des Prozesses.

Unser Ziel: Effizienter WordPress-Workflow und Entwicklung

Das Ziel dieses Artikels ist es, einen Schritt weiter zu gehen und zu zeigen, wie man Upsun mit anderen Tools kombiniert, 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.

Um dies zu tun, beginne ich mit der AnleitungDeploy Composer-based WordPress on Upsun aus der Upsun-Dokumentation.

Maximierung der Automatisierung mit einer Vorlage und WordPress-Workflow-Plugins

Nachdem ich die Anleitung befolgt habe, habe ich mein Experimentmodifiziert , um die Codebasis für zwei Websites (ita und eng) zu hosten, wobei beide:

• mit WordPress.orgaufgebaut sind
• eine rudimentäre "Distro"-Unterstützung haben
• auf Upsun im Multi-App-Setupbereitgestellt 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)
• haben ihre Abhängigkeiten automatisch von Dependabotaktualisiert
• ihre Dependabot PRs werden automatisch von Mergifyzusammengeführt , wenn die Builds erfolgreich sind
• neuer Code wird bei jeder PR-Zusammenführung automatisch in die Produktion eingespeist
• Redis als Backend-Cachingverwenden
• Cloudflare als CDNverwenden
• GitHub Actions als zusätzlichen CI/CD und Cron Schedulerverwenden

Zusätzlich zu den oben genannten:

• die ita-Seite verwendet Elasticsearch
• die eng-Site verwendet Algolia

Zum Schluss:

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

Wenn Sie denken, dass dieses Experiment von einem realen Projekt abgeleitet wurde, dann liegen Sie richtig!

Im weiteren Verlauf dieses Artikels werde ich mich auf die Punkte konzentrieren, die zeigen, dass es bei diesem Experiment darum geht, so viel wie möglich von Ihrem Wordpress-Entwicklungs-Workflow zu automatisieren, und ich werde es vermeiden, auf einige andere Details einzugehen. Wenn Sie also mehr Einblicke in die Composer-basierte WordPress-Entwicklung haben möchten, lesen Sie bitte Chads Artikel oder direkt den Code in meinem Repository.

WordPress-Installation mit Distros und Composer automatisieren

Distros oder Installationsprofile sind im Wesentlichen eine Möglichkeit, Ihre eigene Standard-Installationskonfiguration zu haben. Während einige Softwareprogramme über eine eingebaute Unterstützung dafür verfügen, ist dies bei WordPress nicht der Fall. Mein Ziel war es, die Installation beim ersten Einsatz vollständig zu automatisieren, also beschloss ich, die Dinge selbst in die Hand zu nehmen.

Die rudimentäre Unterstützung, die ich dafür implementiert habe, stützt sich auf zwei Dinge. Erstens, eine maßgeschneiderte Sektion in der composer.json-Datei:

 "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 verwendet, um einige Ersteinrichtungen 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 Deploy-Hooks in Upsunausgeführt , d.h. nachdem die Build-Phase WordPress und die anderen Abhängigkeiten via Composer heruntergeladen und gebaut hat. Das Ergebnis ist eine vollständig installierte WordPress-Anwendung, die es Ihnen erspart, den standardmäßigen manuellen (wenn auch einfachen) WordPress-Einrichtungsassistenten zu durchlaufen.

Wenn Sie sich fragen, warum wir nicht einfach den Abschnitt scripts.postbuild in der composer.json verwendet haben, um ein solches Skript auszuführen, so liegt der Hauptgrund darin, dass während der Build-Phase (wenn composer ausgeführt wird) der Datenbankdienst noch nicht verfügbar ist, da die Build-Phase nur dazu dient, ein deploybares Artefakt zu erzeugen.

Automatische WordPress-Datenbank-Updates

Wir werden später über Code-Updates sprechen, aber da wir oben auf das Skript verwiesen haben, wollte ich hervorheben, dass dasselbe Skript sich um die Aktualisierung der Datenbank kümmert, falls es Code-Updates gegeben hat, die eine solche Operation erfordern.

Wenn Sie schon einmal mit WordPress gearbeitet haben, wissen Sie, dass Sie zumindest bei einem Upgrade des WordPress-Kerns eine sehr einfache Routine ausführen müssen, die das Datenbankschema entsprechend aktualisiert. Dies kann über die administrative Benutzeroberfläche erfolgen, die Ihnen eine einfache Schaltfläche zum Anklicken bietet, oder über die wp-cli. Letzteres wird von diesem Skript verwendet (siehe Installation des wp-cli ): Wenn WordPress bereits installiert ist, wird bei jedem Einsatz einfach eine Datenbankaktualisierungsroutine ausgeführt, die nur dann etwas tut, wenn es etwas zu tun gibt.

Automatisierte Aktualisierungen von Abhängigkeiten

Dependabot, das seit einiger Zeit zur GitHub-Familie gehört, bietet einen kostenlosen Plan für öffentliche Repositories und unterstützt PHP+Composer. Sie können es so konfigurieren, dass Sie entscheiden können, welche Art von Aktualisierungen Sie für Ihre Abhängigkeiten durchführen möchten, und der Bot wird regelmäßig Pull-Requests ausstellen, um veraltete Abhängigkeiten zu vermeiden. Unsere Konfiguration sieht wie folgt 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 Anwendungen gibt es eine tägliche Überprüfung der Abhängigkeiten (denken Sie daran, dass der WordPress-Kern selbst eine Abhängigkeit ist!), mit einem Limit von maximal 10 offenen Pull-Requests zu jeder Zeit. Sie können auch clevere Dinge tun, wie z.B. bestimmte Versionen einer Abhängigkeit ignorieren, wenn Sie wissen, dass sie fehlerhaft sind.

Sie werden sich vielleicht fragen: Ok, aber wie führt das automatische Öffnen von PRs eigentlich zu automatischen Aktualisierungen der Abhängigkeiten? Nun, das tut es nicht :)

Eingabe von auto-merge

Das automatische Öffnen einer Vielzahl von PRs wird Ihnen das Leben kaum erleichtern und Ihre Abhängigkeiten mühelos auf dem neuesten Stand halten. Daher muss ein Tool wie Dependabot mit einem anderen kombiniert werden, das Merge-Warteschlangen und die Möglichkeit bietet, Pull Requests, die bestimmte Kriterien erfüllen, automatisch zusammenzuführen. Ich habe Mergify verwendet, aber es ist wahrscheinlich, dass Sie in naher Zukunft GitHub-Warteschlangenverwenden können , wenn sie sich entscheiden, ein System ähnlich wie Mergify zu implementieren, bei dem Sie ein Muster für die PRsdefinieren können, die automatisch zusammengeführt werden müssen:

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 PRs, die von Dependabot ausgestellt wurden und erfolgreich auf Upsun gebaut wurden, automatisch zusammenzuführen (squash-merge).

Wie bereits erwähnt, soll dieses Experiment über die GitHub-Integration mit Upsun genutzt werden. Dadurch ist es möglich, dass jeder von Dependabot erstellte PR eine zugehörige Vorschauumgebunghat , in der der Build und die Bereitstellung der Anwendung mit den aktualisierten Abhängigkeiten stattfindet. Dank der Integration mit GitHub wird dieser Prozess als Statusprüfung für die PRs im Repository hinzugefügt. Diese Statusprüfung wird hier von Mergify verwendet, um sicherzustellen, dass mit dem PR alles in Ordnung ist; ist das der Fall, wird der PR zusammengeführt.

Dies ist natürlich eine sehr grundlegende Konfiguration; nichts hält uns davon ab, zusätzliche Status-Erfolgs-Bedingungen in der Konfiguration zu verwenden, wie z.B. Unit-Tests, die von einem CI ausgeführt werden. Je mehr Automatisierung und Statusprüfungen Sie haben, desto sicherer können Sie sein, dass der PR automatisch zusammengeführt werden kann.

Kontrolle und Sicherheit mit Upsun und Automatisierungstools erreichen

Die Kombination von Tools wie Dependabot, Mergify und Upsun gibt Ihnen ein viel höheres Maß an Kontrolle und Sicherheit über Ihren Prozess der automatisierten Updates für WordPress Core, Plugins, Themes und Übersetzungsdateien. Denn bei jedem Update können Sie sicher sein, dass eine produktionsähnliche Umgebung mit den Änderungen erstellt wird, und es können zusätzliche Tests durchgeführt werden, um sicherzustellen, dass alles weiterhin einwandfrei funktioniert. Sie können entscheiden, ob Sie nur kleinere Versionen oder auch Hauptversionen automatisch aktualisieren möchten. Sie können bestimmte Versionen oder bestimmte Elemente (z. B. ein bestimmtes Plugin oder Thema) ausschließen. Und vieles mehr. Sie haben eine feinkörnige Kontrolle, mehr Macht und ein höheres Maß an Sicherheit.

Weitere Entwicklungen

Der WordPress-Entwicklungs-Workflow, den ich Ihnen hier gezeigt habe, kann auf erweiterte Szenarien angewendet werden. Sie können Mergify beispielsweise so konfigurieren, dass andere oder sogar alle Arten von PRs unter den richtigen Bedingungen automatisch zusammengeführt werden (denken Sie daran, dass auch manuelle Peer Reviews und andere manuelle Schritte als Statusprüfungen hinzugefügt werden können). Sie können diesen Arbeitsablauf auch extrahieren und ihn auf andere Arten von Anwendungen anwenden, nicht nur auf WordPress.

Eine Möglichkeit, dies auf eine andere Ebene zu bringen, ist die Automatisierung von Infrastruktur-Upgrades! Alles, was Sie brauchen, ist eine Möglichkeit, zu prüfen, ob es eine neue Version eines der von Upsun verwalteten Dienstegibt , die Sie in Ihrem Projekt verwenden, und dann eine neue PR mit dem Update zu erstellen (genau wie Dependabot es mit Anwendungsabhängigkeiten macht). Sobald Sie diese Komponente haben (die in Ihr externes CI-Tool wie GitHub Actions implementiert werden könnte), können Sie Mergify so konfigurieren, dass diese PRs automatisch zusammengeführt werden, wiederum unter den richtigen Bedingungen.

Starten Sie die Automatisierung des WordPress-Entwicklungsworkflows mit Upsun

Während Sie auf die Möglichkeit eines automatischen Upgrades Ihrer Infrastruktur warten (ich verspreche Ihnen, dass ich meine Vorlage mit genau dieser Funktion aktualisieren werde, sobald dies möglich ist), können Sie diese Vorlage und diesen Workflow bereits jetzt verwenden und Ihrem Entwicklungsteam wertvolle Zeit sparen:

• Forken Sie dieses Experiment auf Github
• Erstellen Sie ein neues Upsun-Projekt
• Verknüpfen Sie Ihr geforktes Repository mit dem neu erstellten Projekt über unsere GitHub-Integration (dazu müssen Sie unser CLI installieren).

Und wie immer wissen Sie, wo Sie uns finden, wenn Sie uns brauchen!

Nützliche Links

• WordPress | Upsun Docs
• Bereitstellung von Vanilla WordPress auf Upsun