Hinweis: Der folgende Artikel hilft Ihnen dabei: Moderne Bereitstellungen für Ihre WordPress-Sites
Wenn Sie wie ich sind, haben Sie Ihre ersten Erfahrungen mit dem Übertragen 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) dorthin 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 weitaus komplexer: Was passiert, wenn ich eine Datei übersehe, die von anderen benötigt wird, oder ein Semikolon in einem globalen Include, und die Datei wird weiß angezeigt? ganze Seite? Was passiert, wenn während des Prozesses ein entscheidender Schritt übersehen wird?
Diese „Cowboy-Coding“-Probleme werden nur noch schlimmer, je mehr Menschen, Umgebungen und Abhängigkeiten involviert sind. Infolgedessen wird es immer schwieriger, weiterhin Fortschritte zu machen und gleichzeitig all diese beweglichen Teile unter einen Hut zu bringen. Am schlimmsten ist jedoch, dass die Veröffentlichung von Code zu einem ständigen Grund zur Sorge wird.
Da unsere Anwendungen, Websites und Stores immer moderner werden, sollten wir auch unsere Bereitstellungen modernisieren. Von der Versionskontrolle bis hin zur kontinuierlichen Bereitstellung kann ein moderner Release-Prozess 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 unter Versionskontrolle zu stellen. mit einem Tool wie Git.
Die Verwendung der Versionskontrolle bedeutet, dass Sie sehen können, was sich geändert hat, wer die Änderungen vorgenommen hat, und mithilfe von Verzweigungen sogar an mehreren Änderungssätzen gleichzeitig arbeiten können. Dadurch wird die Arbeit nicht überschrieben und etwaige Konflikte zwischen Dateien werden deutlich hervorgehoben.
Wenn Sie noch nie mit Git gearbeitet haben, keine Angst: Wir haben sowohl eine Einführung in Git als auch einen Beitrag über fortgeschrittenere Git-Workflows geschrieben.
Entscheiden, was verfolgt werden soll
Wenn wir unsere Website unter Versionskontrolle stellen, was wir nicht Den Überblick zu behalten ist fast genauso wichtig wie das, was wir tun:
Allgemein gesagt, Die Versionskontrolle dient der Verfolgung des Quellcodes, nicht der 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 verwenden Sassdie generierten CSS-Dateien sollten nicht unter Versionskontrolle verfolgt werden. Sie sind nicht nur leicht reproduzierbar, sondern auch schwer zu lesen und eine häufige Ursache für Zusammenführungskonflikte, wenn mehrere Entwickler beteiligt sind.
Wenn es um Abhängigkeiten (Bibliotheken, WordPress-Plugins usw.) geht, nutzen Sie Tools wie Komponist Und WPackagist anstatt Code, für den Sie nicht verantwortlich sind, in Ihrem Repository zu bündeln.
Darüber hinaus sollte ein Git-Repository niemals Dinge wie Passwörter, private SSH-Schlüssel oder andere vertrauliche Informationen enthalten, die in Betracht gezogen werden könnten Geheimnisseda jeder Entwickler mit einer Kopie des Repositorys diese vertraulichen Informationen dann auf seinen Computern hätte.
Strukturieren Sie Ihr Repository
Beim Einrichten eines Git-Repositorys für eine WordPress- oder WooCommerce-Site 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, deren Code Sie jedoch nicht 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 Veröffentlichungsprozesses für uns erstellt werden.
Eine Einführung in CI/CD
Wenn es um die Bereitstellung von Software geht, müssen zwei wichtige Begriffe verstanden werden: Kontinuierliche Integration (CI) und Kontinuierliche Lieferung (CD).
Diese beiden Begriffe sind so eng miteinander verbunden, 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:
- Erstellen Sie das Release: Installieren Sie Abhängigkeiten (Composer, npm usw.) und erstellen Sie dann Artefakte (Webpack, Grunt, Sass usw.).
- Testen Sie den Build: Führen Sie Unit-Tests durch, überprüfen Sie Codierungsstandards, führen Sie eine statische Code-Analyse durch usw.
- 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 unsere neuen Änderungen sauber mit der vorhandenen Codebasis übereinstimmen. Jedes Mal, wenn neue Änderungen gepusht werden, werden Prüfungen durchgeführt, um sicherzustellen, dass wir den Build nicht kaputt machen.
Damit die kontinuierliche Integration sinnvoll ist, werden diese Prüfungen durchgeführt muss automatisiert werden. Wenn Sie beispielsweise über eine Suite von Komponententests verfügen, können Sie diese Testsuite jedes Mal ausführen, wenn eine neue Pull-Anfrage geöffnet wird, um Sie auf mögliche fehlerhafte Codefehler in der Produktion aufmerksam zu machen.
Die kontinuierliche Integration ist jedoch nicht auf Unit-Tests beschränkt, da es eine Reihe von „codefreien“ Prüfungen gibt, die automatisch für Ihren Code ausgeführt werden können, darunter:
Durch die automatische Ausführung dieser Prüfungen bei jedem Push wird außerdem sichergestellt, dass der gesamte Code dieselben Prüfungen durchläuft, wodurch verhindert wird, dass Code, der nicht erfolgreich ist, freigegeben wird.
Kontinuierliche Lieferunghingegen ist die Idee, dass wir in der Lage sein sollten, unseren Code jederzeit zu „liefern“ (zu implementieren). Um dies zu erreichen, benötigen wir einen skriptgesteuerten Bereitstellungsprozess, der unseren Code mit einem Klick nahtlos in die Produktion überführt.
Wenn Sie für Ihre Bereitstellungen ein Skript erstellen, können Sie beides bereitstellen regelmäßig Und konsequent; Jede Bereitstellung funktioniert genauso wie die davor. Dadurch kann Ihr Team regelmäßiger und mit größerer Sicherheit Einsätze tätigen und muss sich weniger Sorgen machen, dass jemand einen Schritt auf dem Weg verpasst hat. Für einige Teams ist es nicht ungewöhnlich, dass sie Dutzende (oder sogar Hunderte) Male am Tag bereitstellen!
Abhängig von Ihrer Website möchten Sie vielleicht sogar einen Blick auf die „andere CD“ werfen. Kontinuierliche Bereitstellung; Es ist der kontinuierlichen Bereitstellung sehr ähnlich, aber bei diesem Modell wird jeder Push an eine Filiale automatisch bereitgestellt. Dies kann äußerst leistungsstark sein, wenn ein verzweigtes Versionskontrollschema verwendet wird (wie Github Flow), kann aber unerwünscht sein, wenn Sie Release-Fenster planen oder alle Arbeiten im Hauptzweig erledigen müssen.
Bereitstellung 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 Zweigein CI/CD-Tool, das speziell auf die Bedürfnisse von WordPress-Entwicklern zugeschnitten ist und von den gleichen Entwicklern stammt WP Pusher. Am allerbesten, Branch verfügt über integrierte Unterstützung für die Bereitstellung auf Hostinger!
Um zu beginnen, Melden Sie sich für Branch an, indem Sie Ihr GitHub-, GitLab- oder Bitbucket-Konto verbindenund erstellen Sie dann Ihre erste Website.
Als Nächstes möchten wir alle Schritte konfigurieren, die zum Erstellen unserer Website erforderlich sind. Branch bietet eine Reihe von „Rezepten“ für allgemeine Aktionen (Installieren von Composer-Abhängigkeiten, Ausführen von Webpack usw.), gibt uns aber auch die Möglichkeit, eine beliebige Anzahl benutzerdefinierter Schritte hinzuzufügen.
Sobald wir die zum Aufbau unserer Website erforderlichen Schritte skizziert haben, 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. Auch wenn Sie noch keine Tests haben, Branch macht es zum Kinderspiel, Linting, Codierungsstandards und Kompatibilitätsprüfungen hinzuzufügen.
Nachdem wir nun unsere Abhängigkeiten installiert, alles erstellt und unsere Tests bestanden haben, ist es an der Zeit, unseren Code in die Produktion zu bringen!
Branch enthält Rezepte für die Bereitstellung auf Hostinger (sowie andere große Hosting-Anbieter) und Das Verbinden der beiden Plattformen ist schmerzlos:
- 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
- Fügen Sie diesen öffentlichen Schlüssel zur Schlüsselliste im Hostinger-Portal hinzu
Sobald Branch in der Lage ist, mit Ihrer Hostinger-Site zu kommunizieren, können wir das Bereitstellungsrezept „Hostinger“ auswählen und einige Details eingeben:
- Der Hostname und Benutzername für die Site (verfügbar über das Hostinger-Portal auf dem „Zugriff“-Bildschirm Ihrer Site)
- Das Webstammverzeichnis, in dem wir die Bereitstellung durchführen. Wenn unser Git-Repo als wp-content/-Verzeichnis dienen soll, sollte dieser Wert „public_html/wp-content“ sein.
- Die Dateien, die wir bereitstellen möchten (im Allgemeinen ist der Standardwert „*“ ausreichend)
- Der Git-Zweig, der in dieser Umgebung bereitgestellt werden soll
Besonders wichtig ist die Einstellung „Git-Zweig“, da Sie damit unterschiedliche Bereitstellungen für verschiedene Zweige festlegen können. Beispielsweise könnten Sie über einen „Staging“-Zweig verfügen, in dem die Bereitstellung erfolgt Ihre Staging-UmgebungSo können Sie Änderungen testen, bevor Sie sie in Betrieb nehmen.
Es ist erwähnenswert, dass Branch die kontinuierliche Methode verwendet Einsatz Standardmäßig wird das Modell verwendet, wobei die Pipeline bei jedem Push zum angegebenen Zweig ausgeführt wird. Wenn Sie eher eine kontinuierliche Variante bevorzugen Lieferung Modell (bei dem einige manuelle Maßnahmen ergriffen werden müssen) können Sie erwägen, einen „Produktions“-Zweig beizubehalten, der erst dann zusammengeführt wird, wenn Sie zur Veröffentlichung bereit sind.
Zu diesem Zeitpunkt sollte Branch für die Erstellung und Bereitstellung Ihres Git-Repositorys für Hostinger konfiguriert sein! Sie können Ihre erste Bereitstellung entweder durch Klicken auf die Schaltfläche „Bereitstellung ausführen“ auf der Seite „Pipelines“ Ihrer Site oder durch Pushen in Ihr Git-Repository auslösen.
Anpassen Ihres Release-Prozesses
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 ist im Allgemeinen derselbe, den wir im Bereitstellungsschritt verwendet haben, und Sie können so viele Befehle wie nötig verketten.
Abschluss
Wenn Sie immer noch mit Cowboy-Coding-Mätzchen und/oder angstgeladenen Veröffentlichungen zu kämpfen haben, werfen Sie einen Blick auf Zweig und machen Sie den Einsatz zum Kinderspiel!