Kontinuierliche WordPress-Bereitstellung und Versionskontrolle mit Bitbucket

Gut, Leute. Zeit, es zuzugeben.

Wenn Sie so etwas wie ich sind, haben Sie die erste Phase Ihrer WordPress-Entwicklungsjahre mit „Cowboy-Codierung“ verbracht – das heißt, Sie haben wild Änderungen an Live-Sites vorgenommen, sie dringend getestet und mit FTP gestartet, was häufig zu 500 internen Server-Fehlermeldungen und sitewide unterbricht alles, was für Ihre geschätzten Besucher sichtbar ist.

Während dies absolut aufregend war, als Adrenalin durch Ihre Finger gepumpt wurde und das vergessene Semikolon einhämmerte, wurde dies auf Websites mit mehr als 0 Besuchern (die die Ausfallzeit tatsächlich bemerkten) zu einem Problem. Wenn ein Baum umfällt und niemand da ist, um es zu hören, macht es dann ein Geräusch? Hängt von der Theorie der Menschheit ab, der Sie sich anschließen.

Wenn jedoch eine Website abstürzt und jemand da ist, um es zu sehen, wird er sicherlich ein Geräusch machen.

Kontinuierliche Bereitstellung von WordPress falsch gemacht

Geben Sie Staging-Sites ein, duplizieren Sie WordPress-Installationen (zumindest theoretisch), an denen Änderungen vorgenommen werden könnten, und führen Sie sie dann erneut auf der Live-Site durch, sobald bestätigt wurde, dass alles funktioniert. Während dies die Besucher beruhigte, begann es, uns Entwickler dazu zu bringen, etwas Lärm zu machen. Plötzlich mussten wir zwei Sites im Auge behalten, sicherstellen, dass der Code manuell zwischen ihnen synchronisiert wird, und alles erneut testen, um sicherzustellen, dass es auf der Live-Site funktioniert. Lange, chaotische Listen mit „stellen Sie sicher, dass Sie dies live ändern“ und „stellen Sie sicher, dass Sie dies auf der Staging-Site umschalten, bevor Sie den Code kopieren“ waren, gelinde gesagt, nervenaufreibend. Backups dieses Systems waren ebenfalls ein Albtraum – eine Menge Ordner namens „my-theme-staging-1“ und „my-theme-live-before-menu-restyle-3“ und so weiter.

Es musste einen besseren Weg geben, und den gab es.

Da war Git, das Entwicklern eine perfekte Quellcodeverwaltung und andere Funktionen bietet. Die Verwendung der Versionskontrolle für WordPress-Installationen beschleunigte und bereinigte die Entwicklung sofort, da Stunden nicht mehr mit dem Sichern in einem System pro Entwickler verbracht wurden, sondern tatsächlich mit dem Codieren. Änderungen wurden gespeichert und ich konnte meiner Arbeit endlich aussagekräftige Botschaften hinzufügen, Welten im Unterschied zu „my-theme-4-v2“.

Obwohl die Codebasis viel sauberer war, blieb das Problem der tatsächlichen Bereitstellungen und der Sicherstellung, dass die betreffende Site den neuesten Code verwendete – geben Sie die Möglichkeit für menschliches Versagen ein. Sich immer noch auf manuelle FTP-Uploads zu verlassen, die den vorherigen Code überschreiben, fühlte sich nicht gut an. Während andere CI/CD-Dienste existierten, waren viele von ihnen mit einem beträchtlichen Preisschild und einem großen Einrichtungsaufwand verbunden – Neukonfiguration des Servers, Verlassen auf einen weiteren Dienst selbst für die einfachste Website, Erlernen der gesamten „Vorgehensweise“ des anderen Dienstes und so weiter die Eigenheiten, die damit einhergehen.

Während ähnliche Setups wie in diesem Tutorial mit GitHub/GitLab und anderen Diensten durchgeführt werden können, hatte ich meine Eier aufgrund ihrer kostenlosen privaten Repositories (die erst kürzlich von GitHub angeboten wurden) früh in den Korb von Atlassian gelegt. Als Bitbucket seine Pipelines and Deployments Services einführte, ermöglichte es die automatische Bereitstellung von neuem Code auf Staging- oder Produktionsseiten (oder jeder anderen Site dazwischen), ohne erneutes Hochladen über FTP oder die Verwendung eines externen Dienstes. Entwickler konnten nun alle Werte der Quellcodeverwaltung in ihrer WordPress-Entwicklung nutzen und diese Änderungen ohne zusätzliche Klicks oder Tastenanschläge sofort an die entsprechenden Ziele senden, wobei der Status von allem über ein Dashboard sichtbar war. Dadurch wird sichergestellt, dass alles synchron bleibt und Sie auf einen Blick genau wissen, welcher Code auf jeder Site ausgeführt wird. Außerdem sind die Preise für die Build-Minuten von Bitbucket unglaublich erschwinglich – mit 50 kostenlosen Minuten pro Monat und einer Option für einen „Free with Overages“-Plan.

Es brauchte ein wenig Startzeit, um herauszufinden, wie Branches und andere Funktionen der Quellcodeverwaltung in diesem neuen Modell und den Einzelheiten des Bitbucket Pipelines-Setups am besten verwendet werden können. Hier ist der Prozess, den ich verwende, um neue WordPress-Projekte zu starten. Ich werde nicht auf das Wesentliche beim Einrichten von Git und der WordPress-Installation eingehen, da großartige Ressourcen dafür nur eine Google-Suche entfernt sind. Am Ende wird der Inhaltsfluss in etwa so aussehen:

Die Alexa Green WordPress-Bereitstellungsroutine

Die hier beschriebenen Schritte sollten nach Bedarf durchgeführt werden:

Auf dem Server des Kunden

Richten Sie eine Domain für die Live-Site (z. B. clientsite.com) und eine Subdomain für Staging (z. B. staging.clientsite.com) ein.

Installieren Sie WordPress sowohl auf der Live-Site als auch auf der Staging-Subdomain. Dies kann über cPanel/Softaculous (falls das Hosting des Kunden dies hat) oder durch Herunterladen von wordpress.org erfolgen. Stellen Sie sicher, dass jeweils separate Datenbanken für Live und Staging vorhanden sind.

Auf Bitbucket.com

Richten Sie ein neues Repository ein. Fügen Sie eine .README-Datei hinzu, damit wir loslegen können.

Aktivieren Sie im Repository Einstellungen > Pipelines > Einstellungen und aktivieren Sie dann Pipelines aktivieren .

Geben Sie unter Einstellungen > Pipelines > Repository-Variablen Folgendes ein:

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

Gehen Sie zurück zu Pipelines > Einstellungen und klicken Sie auf die Schaltfläche Bitbucket-pipelines.yml konfigurieren . Wählen Sie auf der folgenden Seite PHP als Sprache aus. Sie sollten so etwas wie den folgenden Code verwenden. Stellen Sie sicher, dass Sie die PHP-Version durch das ersetzen, was Sie auf dem Server des Clients verwenden, und URLs/FTP-Server durch die tatsächlichen URLs/FTP-Server der Client-Site (Produktion und Staging).

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Klicken Sie auf Datei übertragen . Das Pipelines-Setup wird nun festgeschrieben und ausgeführt.

Wenn alles erfolgreich bereitgestellt wurde, gehen Sie zurück und bearbeiten Sie die Datei bitbucket-pipelines.yml (Sie erreichen sie über Pipelines > Settings und View bitbucket-pipelines.yml ). Sie sollten beide Stellen, an denen git ftp init steht, durch git ftp push und save/commit ersetzen. Dadurch wird sichergestellt, dass nur geänderte Dateien hochgeladen werden, wodurch Sie Build-Minuten sparen. Ihre bitbucket-pipelines.yml-Datei sollte jetzt lauten:

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Fügen Sie einen Branch namens main-dev .

Auf Ihrem lokalen Computer

Klonen Sie das Repository in ein leeres Verzeichnis, das Sie für die lokale Installation verwenden möchten. Sehen Sie sich den main-dev Zweig an.

Richten Sie in diesem Verzeichnis eine lokale WP-Installation ein. Dafür gibt es viele Tools – Local by Flywheel, MAMP, Docker usw. Stellen Sie sicher, dass alles gleich ist (WordPress-Version, PHP-Version, Apache/Nginx usw.) wie das, was auf dem Server des Clients läuft.

Fügen Sie eine .gitignore , die ungefähr so ​​aussieht. Im Wesentlichen möchten wir, dass Git alles außer wp-content ignoriert (um Installationsprobleme zwischen Installationen zu vermeiden). Möglicherweise möchten Sie auch Ihre eigenen Regeln zum Ignorieren großer Sicherungsdateien und vom System erstellter Symbol- und DS_Store-Dateien hinzufügen.

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

Speichern und committen Sie .gitignore .

Nehmen Sie Änderungen vor und verpflichten Sie sich entsprechend.

Jedes Mal, wenn Sie sich auf main-dev festlegen, wird ein FTP-Upload auf die Staging-Site ausgelöst. Jedes Mal, wenn Sie sich zum Master verpflichten, wird ein FTP-Upload auf die Produktionsseite ausgelöst. Beachten Sie, dass dies Build-Minuten benötigt, daher möchten Sie vielleicht die meisten lokalen Änderungen an einem Zweig von main-dev vornehmen und dann mit main-dev zusammenführen, wenn Sie für den Tag fertig sind.

Durch das Zusammenführen von Main-Dev mit Master werden alle Staging-Änderungen live geschaltet. Sie können den Status von Pipelines und Bereitstellungen im Repository auf Bitbucket.org überprüfen.

Synchronisieren von WordPress-Datenbanken über Installationen hinweg

Beachten Sie, dass oben nur Dateien (Themen, Plugins usw.) synchronisiert werden. Das Synchronisieren der Datenbank zwischen Produktion und Staging wird zu einer anderen Sache, da Clients häufig Änderungen an der Live-Site vornehmen, die sich nicht auf der Staging-Site widerspiegeln, und umgekehrt.

Für die Synchronisierung von Datenbanken über WordPress-Installationen hinweg gibt es mehrere Optionen. Traditionell können Sie Datenbanken aktualisieren, indem Sie sie über phpmyadmin importieren/exportieren. Dies ist jedoch schwierig, da bestimmte Dinge, die aktualisiert werden müssen, wie Permalinks in Post-Inhalten, nicht aktualisiert werden können. Bei dieser Methode ist das Velvet Blues Update URLs Plugin ein beliebtes Tool, mit dem Sie alle Instanzen der alten Site-URL (z. B. https://staging.clientsite.com) suchen/durch die neue Site-URL ersetzen können ( B. https://clientsite.com). Sie können dies auch mit relativen Pfaden und Zeichenfolgen verwenden. Diese Methode lässt am Ende viel Raum für menschliche Fehler – wenn eine ersetzte Zeichenfolge falsch geschrieben wird, kann dies dazu führen, dass die gesamte Website kaputt geht und das Plugin nicht verwendet/auf das Dashboard nicht zugegriffen werden kann.

Während ein Plugin wie All-in-One WP Migration eine Such-/Ersetzungsfunktion vorkonfiguriert bietet und unglaublich benutzerfreundlich ist, bringt es auch Dateien mit und macht so die Werte unseres gesamten Pipelines-Workflows rückgängig. Da es alle wp-Uploads neu importiert, kann es außerdem zu riesigen Dateien und Ladezeiten führen (daher ist es ungeeignet, Änderungen zwischen Installationen zu verschieben). Ein Plugin wie dieses ist am besten für Backups der gesamten Website zu Archivierungs-/Sicherheitszwecken reserviert.

VersionPress scheint eine interessante Lösung zu sein, hat sich aber noch nicht in vielen Produktionsumgebungen bewährt. Im Moment scheinen Plugins wie WP Sync DB oder WP Migrate DB Pro die besten Lösungen für die Datenbankverwaltung zu sein. Sie ermöglichen das Pullen/Pushen von Datenbanken über Installationen hinweg und bieten gleichzeitig die Möglichkeit, URLs und Pfade automatisch zu aktualisieren. Sie können nur bestimmte Tabellen wie wp_posts nur für Post-Inhalte migrieren und keine Zeit mit dem erneuten Importieren von Benutzern und seitenweiten Einstellungen verschwenden. Ich ziehe immer gerne Live-Puffer, um sicherzustellen, dass keine Produktionsdaten überschrieben werden. Hier ist ein Beispiel-Setup, wenn Sie WP Sync DB verwenden (weitere exemplarische Vorgehensweisen sind auf dem WP Sync DB-Github verfügbar):

1. Auf der Live-Site: Richten Sie WP Sync DB mit aktivierter Einstellung „Pull aus diesem Repository zulassen“ ein.
2. Auf der Staging-Site: Richten Sie WP Sync DB mit Pull from Live-Einstellungen ein. Nennen Sie es „live-to-staging“.
3. Auf Ihrem lokalen Entwickler-Setup: Richten Sie WP Sync DB mit Pull from Live-Einstellungen ein. Nennen Sie es „live-to-dev“.

Sie können auch eine Push-Regel „dev-to-staging“ einrichten und die Staging-Site-Einstellung überprüfen, um das Überschreiben der Datenbank zuzulassen.

Einpacken

Ich habe festgestellt, dass diese Methoden für die meisten Anwendungsfälle funktionieren, sowohl bei der Entwicklung einer neuen WordPress-Website als auch bei der Neugestaltung/Neukonfiguration einer bereits aktiven Website.

Es ermöglicht Code-Bereitstellungen, die alle Site-Versionen ohne zusätzliche Entwicklungszeit/Aufwand auf dem neuesten Stand halten, und eine absichtliche, sichere Datenbankmigrationslogik für die Arbeit zwischen Sites. Das Aktualisieren von Plugins erfolgt ebenfalls innerhalb der Quellcodeverwaltung, sodass Plugin-Updates beim Staging sicher überprüft werden können, bevor sie auf die Live-Site übertragen werden, wodurch Unterbrechungen der Produktionssite minimiert werden.

Während es sicherlich Raum für Verbesserungen gibt, um mehr von einem Source-Control-Workflow in die Datenbankverwaltung zu bringen, scheint diese Methode des selektiven Pulls/Pushes der Datenbank über WP Sync DB oder WP Migrate DB Pro, bis ein Tool wie VersionPress mehr in Produktionsumgebungen verwendet wird um die sicherste Methode zu sein, damit umzugehen. Neugierig zu hören, was für Ihren WordPress-Workflow funktioniert, oder ob Sie nach all dem lieber einfach zu Ihrem Lasso greifen und es mit Cowboy-Code codieren möchten!