Moderne Bereitstellungen für Ihre WordPress-Sites

Wenn Sie wie ich sind, haben Sie Ihre ersten Erfahrungen mit dem Pushen von Dateien auf einen Webserver entweder über einen webbasierten Dateimanager wie cPanel oder einen FTP-Client (File Transfer Protocol) wie Transmit oder Filezilla gemacht. Stellen Sie eine Verbindung zum Server her, ziehen Sie Ihre Datei(en) hinüber und warten Sie, bis die Übertragung abgeschlossen ist.

Einfach richtig?

Sobald ich jedoch anfing, mit etwas Komplexerem als statischen HTML-Dateien zu arbeiten, wurde die Bereitstellung meines Codes viel komplexer: Was passiert, wenn ich eine Datei übersehe, die von anderen benötigt wird, oder ein Semikolon in einem globalen Include und es weißt die ganze Seite? Was ist, wenn während des Prozesses ein entscheidender Schritt ausgelassen wird?

Diese „Cowboy-Codierungs“-Probleme werden nur schlimmer, wenn mehr Menschen, Umgebungen und Abhängigkeiten involviert sind. Infolgedessen wird es immer schwieriger, Fortschritte zu machen, während Sie all diese beweglichen Teile jonglieren. Das Schlimmste ist, dass das Freigeben von Code zu einer großen Sache und einer ständigen Quelle der Angst wird.

Da unsere Anwendungen, Sites und Stores immer moderner werden, sollten wir auch unsere Bereitstellungen modernisieren. Von der Versionskontrolle bis zur kontinuierlichen Bereitstellung kann ein moderner Freigabeprozess die Angst vor Bereitstellungen lindern.

Nachverfolgen von Änderungen mit Versionskontrolle

Der erste Schritt zur Abkehr von Ad-hoc-Updates und Cowboy-Codierung besteht darin, Ihre Website mit einem Tool wie Git unter Versionskontrolle zu bringen.

Die Verwendung der Versionskontrolle bedeutet, dass Sie sehen können, was sich geändert hat, wer die Änderungen vorgenommen hat, und sogar an mehreren Sätzen von Änderungen gleichzeitig arbeiten können, indem Sie Verzweigungen verwenden. Dadurch wird die Arbeit nicht überschrieben und alle Konflikte zwischen Dateien werden deutlich hervorgehoben.

Wenn Sie noch nie mit Git gearbeitet haben, haben Sie keine Angst: Wir haben sowohl eine Einführung in Git als auch einen Beitrag über fortgeschrittenere Git-Workflows geschrieben.

Entscheiden, was verfolgt werden soll

Während wir unsere Website unter Versionskontrolle stellen, ist das, was wir nicht im Auge behalten, fast so wichtig wie das, was wir tun:

Im Allgemeinen dient die Versionskontrolle dazu, den Quellcode zu verfolgen, nicht die von Tools oder Prozessen generierten Assets . Dazu gehören Dinge wie verkettetes/minimiertes CSS und JavaScript, externe Abhängigkeiten usw. Zusammenfassend bezeichnen wir diese Elemente als Artefakte .

Wenn Sie beispielsweise einen CSS-Präprozessor wie Sass verwenden, sollten die generierten CSS-Dateien nicht unter Versionskontrolle nachverfolgt werden. Sie sind nicht nur leicht reproduzierbar, sie sind auch schwer zu lesen und eine häufige Ursache für Merge-Konflikte, wenn mehrere Entwickler beteiligt sind.

Wenn es um Abhängigkeiten (Bibliotheken, WordPress-Plugins usw.) geht, nutzen Sie Tools wie Composer und WPackagist, anstatt Code in Ihrem Repository zu bündeln, für den Sie nicht verantwortlich sind.

Darüber hinaus sollte ein Git-Repository niemals Dinge wie Passwörter, private SSH-Schlüssel oder andere vertrauliche Informationen enthalten, die als Geheimnisse gelten würden, da jeder Entwickler mit einer Kopie des Repositorys diese sensiblen Informationen dann auf seinen Computern haben würde.

Strukturierung Ihres Repositorys

Wenn Sie ein Git-Repository für eine WordPress- oder WooCommerce-Site einrichten, ist es im Allgemeinen am besten, wp-content/ als Stammverzeichnis des Repositorys zu behandeln, da Sie im Allgemeinen keine Dateien oberhalb dieses Verzeichnisses berühren.

Plugins und Themes, die Ihre Website verwendet, für die Sie jedoch keinen Code pflegen, sollten dann über Composer geladen werden, da es sich um externe Abhängigkeiten handelt. Ebenso sollten verarbeitete CSS- und JavaScript-Dateien über die .gitignore-Datei ausgeschlossen werden, da diese Artefakte im Rahmen unseres Freigabeprozesses für uns erstellt werden.

Wir haben eine kostenlose Repository-Vorlage auf GitHub verfügbar, um Ihnen den Einstieg zu erleichtern.

Eine Einführung in CI/CD

Bei der Bereitstellung von Software sind zwei wichtige Begriffe zu verstehen: Continuous Integration (CI) und Continuous Delivery (CD).

Diese beiden Begriffe sind so eng miteinander verwandt, dass sie oft gemeinsam als „CI/CD“ bezeichnet werden und der Pfad, durch den unsere Änderungen fließen, somit zur „CI/CD-Pipeline“ wird. Diese Pipeline hat normalerweise die folgende Form:

1. Release erstellen: Abhängigkeiten installieren (Composer, npm usw.), dann Artefakte erstellen (Webpack, Grunt, Sass usw.)
2. Testen Sie den Build: Führen Sie Unit-Tests durch, überprüfen Sie die Codierungsstandards, führen Sie eine statische Codeanalyse durch usw.
3. Stellen Sie die Version in einer oder mehreren Umgebungen bereit

Kontinuierliche Integration ist der Prozess des kontinuierlichen Testens unseres Codes, um sicherzustellen, dass Änderungen die vorhandene Funktionalität nicht beeinträchtigen, sodass sich unsere neuen Änderungen sauber in die vorhandene Codebasis integrieren lassen. Jedes Mal, wenn neue Änderungen gepusht werden, werden Überprüfungen durchgeführt, um sicherzustellen, dass wir den Build nicht „brechen“.

Damit Continuous Integration sinnvoll ist, müssen diese Prüfungen automatisiert werden. Wenn Sie beispielsweise über eine Suite von Einheitentests verfügen, können Sie diese Testsuite jedes Mal ausführen, wenn ein neuer Pull-Request geöffnet wird, und Sie auf mögliche Fehler aufmerksam machen, bevor der Code in der Produktion landet.

Continuous Integration ist jedoch nicht auf Komponententests beschränkt, da es eine Reihe von „codefreien“ Prüfungen gibt, die automatisch gegen Ihren Code ausgeführt werden können, darunter:

• Überprüfung von Codierungsstandards (PHP_CodeSniffer, PHP Coding Standards Fixer)
• Statische Codeanalyse (PHPStan, Psalm)

Das automatische Ausführen dieser Prüfungen bei jedem Push stellt auch sicher, dass der gesamte Code dieselben Prüfungen durchläuft, wodurch verhindert wird, dass Code, der nicht bestanden wird, freigegeben wird.

Continuous Delivery hingegen ist die Idee, dass wir in der Lage sein sollten, unseren Code zu jedem beliebigen Zeitpunkt „zu liefern“ (zu implementieren). Um dies zu erreichen, benötigen wir einen geskripteten Bereitstellungsprozess, der unseren Code mit einem Klick auf eine Schaltfläche nahtlos in die Produktion überführt.

Wenn Sie Ihre Bereitstellungen per Skript erstellen, können Sie sie sowohl regelmäßig als auch konsistent bereitstellen. Jede Bereitstellung sollte genauso funktionieren wie die vorherige. Infolgedessen kann Ihr Team mit einem höheren Maß an Selbstvertrauen und weniger Sorgen, dass jemand einen Schritt auf dem Weg verpasst hat, regelmäßiger bereitstellen. Für einige Teams ist es nicht ungewöhnlich, Dutzende (oder sogar Hunderte) Male am Tag bereitzustellen!

Abhängig von Ihrer Website möchten Sie sich vielleicht sogar „die andere CD“ ansehen, Continuous Deployment ; Es ist der kontinuierlichen Bereitstellung sehr ähnlich, aber bei diesem Modell wird jeder Push an eine Filiale automatisch bereitgestellt. Dies kann bei Verwendung eines verzweigten Versionskontrollschemas (z. B. Github Flow) äußerst leistungsfähig sein, kann jedoch unerwünscht sein, wenn Sie Veröffentlichungsfenster planen oder alle Arbeiten im Hauptzweig erledigen müssen.

Bereitstellen einer WordPress- oder WooCommerce-Site mit CI/CD

Nachdem wir nun die grundlegende Terminologie verstanden haben, werfen wir einen Blick auf die Bereitstellung einer typischen WordPress- oder WooCommerce-Site:

Für diese Übung verwenden wir Branch, ein CI/CD-Tool, das auf die Bedürfnisse von WordPress-Entwicklern von denselben Leuten wie hinter WP Pusher zugeschnitten ist. Das Beste daran ist, dass Branch eine integrierte Unterstützung für die Bereitstellung auf Nexcess bietet!

Melden Sie sich zunächst für Branch an, indem Sie Ihr GitHub-, GitLab- oder Bitbucket-Konto verbinden und dann Ihre erste Website erstellen.

Als Nächstes möchten wir alle Schritte konfigurieren, die zum Erstellen unserer Website erforderlich sind. Branch bietet eine Reihe von „Rezepten“ für häufige Aktionen (Installation von Composer-Abhängigkeiten, Ausführen von Webpack usw.), gibt uns aber auch die Möglichkeit, eine beliebige Anzahl von benutzerdefinierten Schritten hinzuzufügen.

Sobald wir die Schritte skizziert haben, die zum Erstellen unserer Website erforderlich sind, können wir mit der nächsten Phase unserer Pipeline fortfahren: dem Testen.

Wenn Sie bereits über eine automatisierte Testsuite für Ihre Site verfügen, können Sie Branch einfach anweisen, alle erforderlichen Befehle auszuführen. Selbst wenn Sie noch keine Tests haben, macht Branch das Hinzufügen von Linting, Codierungsstandards und Kompatibilitätsprüfungen zum Kinderspiel.

Nachdem wir nun unsere Abhängigkeiten installiert, alles erstellt und unsere Tests bestanden haben, ist es an der Zeit, unseren Code in Produktion zu bringen!

Branch enthält Rezepte für die Bereitstellung auf Nexcess (sowie anderen großen Hosting-Anbietern), und die Verbindung der beiden Plattformen ist problemlos:

1. Wählen Sie Ihre Site im Branch-Dashboard aus, klicken Sie auf „Einstellungen“ und holen Sie sich dann den öffentlichen SSH-Schlüssel Ihrer Branch-Site
2. Fügen Sie diesen öffentlichen Schlüssel der Schlüsselliste im Nexcess-Portal hinzu

Sobald Branch mit Ihrer Nexcess-Site kommunizieren kann, können wir das „Nexcess“-Bereitstellungsrezept auswählen und einige Details eingeben:

1. Der Hostname und der Benutzername für die Site (verfügbar über das Nexcess-Portal auf dem Bildschirm „Zugriff“ Ihrer Site)
2. Das Webstammverzeichnis, in dem wir bereitstellen. Wenn unser Git-Repo als wp-content/-Verzeichnis dienen soll, sollte dieser Wert „public_html/wp-content“ sein.
3. Die Dateien, die wir bereitstellen möchten (im Allgemeinen ist der Standard „*“ ausreichend)
4. Der Git-Zweig, der in dieser Umgebung bereitgestellt werden soll

Die Einstellung „Git-Branch“ ist besonders wichtig, da Sie damit unterschiedliche Deployments für unterschiedliche Branches festlegen können. Beispielsweise haben Sie möglicherweise einen „Staging“-Zweig, der in Ihrer Staging-Umgebung bereitgestellt wird, sodass Sie Änderungen testen können, bevor Sie sie live schalten.

Es ist erwähnenswert, dass Branch standardmäßig das Continuous Deployment -Modell verwendet, bei dem die Pipeline bei jedem Push an den angegebenen Branch ausgeführt wird. Wenn Sie eher ein Continuous- Delivery -Modell bevorzugen (bei dem einige manuelle Maßnahmen ergriffen werden müssen), sollten Sie erwägen, einen „Produktions“-Zweig zu unterhalten, der nur zusammengeführt wird, wenn Sie zur Veröffentlichung bereit sind.

An diesem Punkt sollte Branch so konfiguriert sein, dass es Ihr Git-Repository erstellt und für Nexcess bereitstellt! Sie können Ihre erste Bereitstellung entweder durch Klicken auf die Schaltfläche „Bereitstellung ausführen“ auf der Seite „Pipelines“ Ihrer Website oder durch Pushen in Ihr Git-Repository auslösen.

Anpassen Ihres Freigabeprozesses

Eine der wirklich netten Funktionen von Branch ist die Möglichkeit, nach einer erfolgreichen Bereitstellung zusätzliche Schritte zu konfigurieren, z. B. das automatische Löschen des Objektcaches Ihrer Site nach einer Bereitstellung. Dies kann mit dem WP-CLI-Rezept unter „Andere“ erreicht werden.

Der Host- und Benutzername sind im Allgemeinen die gleichen, die wir im Bereitstellungsschritt verwendet haben, und Sie können so viele Befehle wie nötig verketten.

Fazit

Wenn Sie immer noch mit Cowboy-Codierungspossen und/oder angstbesetzten Veröffentlichungen zu kämpfen haben, werfen Sie einen Blick auf Branch und machen Sie den Einsatz zum Kinderspiel!