Kontinuierliche Bereitstellungen für WordPress mit GitHub Actions

Workflows für kontinuierliche Integration (CI) gelten heutzutage als Best Practice. Das heißt, Sie arbeiten mit Ihrem Versionskontrollsystem (Git), und während Sie arbeiten, erledigt CI Aufgaben für Sie, wie z. B. das Ausführen von Tests, das Senden von Benachrichtigungen und das Bereitstellen von Code. Dieser letzte Teil wird als Continuous Deployment (CD) bezeichnet. Aber der Versand von Code an einen Produktionsserver erfordert oft kostenpflichtige Dienste. Mit GitHub Actions ist Continuous Deployment für jeden kostenlos. Lassen Sie uns untersuchen, wie Sie das einrichten.

DevOps ist für alle da

Als Frontend-Entwickler waren Workflows für kontinuierliche Bereitstellung für mich aufregend, aber mysteriös. Ich erinnere mich, wie ich zahlreiche Male Angst hatte, Bereitstellungskonfigurationen anzufassen. Stattdessen habe ich mich für den einfachen Weg entschieden – normalerweise ließ ich jemanden anderes es einrichten und warten, oder im schlimmsten Fall manuelles Kopieren und Einfügen.

Sobald ich die Grundlagen von rsync verstanden hatte, wurde CD endlich greifbar für mich. Mit dem folgenden GitHub Action Workflow müssen Sie kein DevOps-Spezialist sein; Sie haben dennoch die Werkzeuge zur Hand, um Best-Practice-Bereitstellungsworkflows einzurichten.

Die Grundlagen eines Continuous Deployment Workflows

Also, was ist der Clou, wie funktioniert das? Alles beginnt mit CI, was bedeutet, dass Sie Code in ein gemeinsames Remote-Repository wie GitHub committen, und jeder Push dorthin führt automatisierte Aufgaben auf einem Remote-Server aus. Diese Aufgaben können Test- und Build-Prozesse umfassen, wie z. B. Linting, Konkatenation, Minifizierung und Bildoptimierung, unter anderem.

CD liefert auch Code an einen Produktionsserver. Dies kann durch Kopieren des verifizierten und erstellten Codes und Platzieren auf dem Server über FTP, SSH oder durch den Versand von Containern an eine Infrastruktur geschehen. Während jedes Shared-Hosting-Paket über FTP-Zugriff verfügt, ist das Senden vieler Dateien an einen Server eher unzuverlässig und langsam. Und während der Versand von Anwendungscontainern eine sichere Methode zur Veröffentlichung komplexer Anwendungen ist, können die Infrastruktur und Einrichtung auch ziemlich komplex sein. Die Bereitstellung von Code über SSH ist jedoch schnell, sicher und flexibel. Außerdem wird sie von vielen Hosting-Paketen unterstützt.

Bereitstellung mit rsync

Eine einfache und effiziente Methode, Dateien über SSH auf einen Server zu übertragen, ist rsync, ein Dienstprogramm zum Synchronisieren von Dateien zwischen einem Quell- und einem Zielordner, Laufwerk oder Computer. Es synchronisiert nur die Dateien, die sich geändert haben oder noch nicht am Ziel vorhanden sind. Da es ein Standardwerkzeug auf gängigen Linux-Distributionen ist, müssen Sie es wahrscheinlich nicht einmal installieren.

Die grundlegendste Operation ist so einfach wie der Aufruf von rsync QUELLE ZIEL, um Dateien von einem Verzeichnis in ein anderes zu synchronisieren. Es gibt jedoch einige Optionen, die Sie berücksichtigen sollten

• -c vergleicht Dateiänderungen anhand der Prüfsumme, nicht der Änderungszeit
• -h gibt Zahlen in einem besser lesbaren Format aus
• -a behält Dateieigenschaften und Berechtigungen bei und kopiert Dateien und Verzeichnisse rekursiv
• -v zeigt Statusausgaben an
• --delete löscht Dateien vom Ziel, die nicht (mehr) in der Quelle gefunden werden
• --exclude verhindert die Synchronisierung angegebener Dateien wie des .git-Verzeichnisses und node_modules

Und schließlich möchten Sie die Dateien an einen Remote-Server senden, wodurch der vollständige Befehl wie folgt aussieht

rsync -chav --delete --exclude /.git/ --exclude /node_modules/ ./ [email protected]:/mydir

Sie könnten diesen Befehl von Ihrem lokalen Computer ausführen, um auf jeden Live-Server bereitzustellen. Aber wie cool wäre es, wenn er in einer kontrollierten Umgebung von einem sauberen Zustand aus laufen würde? Richtig, dafür sind Sie hier. Machen wir weiter.

Erstellen eines GitHub Actions Workflows

Mit GitHub Actions können Sie Workflows konfigurieren, die bei jedem GitHub-Ereignis ausgeführt werden. Obwohl es einen Marktplatz für GitHub Actions gibt, benötigen wir keinen davon, sondern erstellen unseren eigenen Workflow.

Um zu beginnen, gehen Sie zur Registerkarte „Actions“ Ihres Repositorys und klicken Sie auf „Set up a workflow yourself.“ Dies öffnet den Workflow-Editor mit einer .yaml-Vorlage, die im Verzeichnis .github/workflows Ihres Repositorys committed wird.

Beim Speichern überprüft der Workflow den Code Ihres Repos und führt einige echo-Befehle aus. name hilft, den Status und die Ergebnisse später zu verfolgen. run enthält die Shell-Befehle, die Sie in jedem Schritt ausführen möchten.

Definieren eines Bereitstellungstriggers

Theoretisch sollte jeder Commit auf dem Master-Branch bereit für die Produktion sein. Die Realität lehrt uns jedoch, dass Sie die Testergebnisse auch nach der Bereitstellung auf dem Produktionsserver testen müssen und diese planen müssen. Wir bei bleech halten es für eine Best Practice, nur an Werktagen – außer Freitagen und nur vor 16:00 Uhr – bereitzustellen, um sicherzustellen, dass wir Zeit haben, bei Problemen während der Geschäftszeiten zurückzusetzen oder zu beheben.

Eine einfache Möglichkeit, die manuelle Kontrolle zu erhalten, ist das Einrichten eines separaten Branchs nur zum Auslösen von Bereitstellungen. Auf diese Weise können Sie Ihren Master-Branch jederzeit, wenn Sie bereit sind, gezielt in diesen Branch mergen. Nennen Sie diesen Branch production, informieren Sie Ihr Team, dass Pushes auf diesen Branch nur vom Master-Branch erlaubt sind, und weisen Sie sie an, dies so zu tun

git push origin master:production

So ändern Sie den Workflow-Trigger, um nur bei Pushes auf diesen production-Branch ausgeführt zu werden

name: Deployment
on:
  push:
    branches: [ production ]

Theme erstellen und überprüfen

Ich gehe davon aus, dass Sie unser WordPress Starter Theme Flynt verwenden, das Abhängigkeitsmanagement über Composer und npm sowie einen vorkonfigurierten Build-Prozess mitbringt. Wenn Sie ein anderes Theme verwenden, ist der Build-Prozess wahrscheinlich ähnlich, erfordert aber möglicherweise Anpassungen. Und wenn Sie die erstellten Assets in Ihr Repository einchecken, können Sie alle Schritte bis auf den checkout-Befehl überspringen.

Für unser Beispiel stellen wir sicher, dass Node in der erforderlichen Version ausgeführt wird und die Abhängigkeiten vor dem Build installiert werden

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    
    - uses: actions/setup-node@v2
      with:
        node-version: 12.x

    - name: Install dependencies
      run: |
        composer install -o
        npm install

    - name: Build
      run: npm run build

Die Flynt-Build-Aufgabe führt schließlich Sass- und JavaScript-Dateien aus, lintet, kompiliert und transpilert sie, fügt dann Revisioning zu den Assets hinzu, um Probleme mit dem Browser-Cache zu vermeiden. Wenn etwas im Build-Schritt fehlschlägt, wird der Workflow abgebrochen, und Sie vermeiden so die Bereitstellung einer fehlerhaften Version.

Serverzugriff und Ziel konfigurieren

Damit der rsync-Befehl erfolgreich ausgeführt werden kann, benötigt GitHub Zugriff auf SSH auf Ihren Server. Dies kann erreicht werden, indem Sie Folgendes tun

1. Generieren Sie einen neuen SSH-Schlüssel (ohne Passphrase)
2. Fügen Sie den öffentlichen Schlüssel zu Ihrem ~/.ssh/authorized_keys auf dem Produktionsserver hinzu
3. Fügen Sie den privaten Schlüssel als Geheimnis mit dem Namen DEPLOY_KEY zum Repository hinzu

Der Sync-Workflow-Schritt muss den Schlüssel in einer lokalen Datei speichern, die Dateiberechtigungen anpassen und die Datei an den rsync-Befehl übergeben. Das Ziel muss auf Ihr WordPress-Theme-Verzeichnis auf dem Produktionsserver zeigen. Es ist praktisch, es als Variable zu definieren, damit Sie wissen, was Sie ändern müssen, wenn Sie den Workflow für zukünftige Projekte wiederverwenden.

- name: Sync
  env:
    dest: '[email protected]:/mydir/wp-content/themes/mytheme'
  run: |
    echo "${{secrets.DEPLOY_KEY}}" > deploy_key
    chmod 600 ./deploy_key
    rsync -chav --delete \
      -e 'ssh -i ./deploy_key -o StrictHostKeyChecking=no' \
      --exclude /deploy_key \
      --exclude /.git/ \
      --exclude /.github/ \
      --exclude /node_modules/ \
      ./ ${{env.dest}}

Je nach Ihrer Projektstruktur möchten Sie möglicherweise auch Plugins und andere Theme-bezogene Dateien bereitstellen. Um dies zu erreichen, ändern Sie Quelle und Ziel auf das gewünschte übergeordnete Verzeichnis, stellen Sie sicher, dass die ausgeschlossenen Dateien aktualisiert werden müssen, und prüfen Sie, ob Pfade im Build-Prozess angepasst werden müssen. 

Zusammensetzen der Teile

Wir haben alle notwendigen Schritte des CD-Prozesses behandelt. Jetzt müssen wir sie in einer Reihenfolge ausführen, die

1. Bei jedem Push auf den production-Branch auslösen
2. Abhängigkeiten installieren
3. Den Code erstellen und verifizieren
4. Das Ergebnis per rsync an einen Server senden

Der vollständige GitHub-Workflow wird wie folgt aussehen

name: Deployment
on:
  push:
    branches: [ production ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-node@v2
      with:
        node-version: 12.x
    - name: Install dependencies
      run: |
        composer install -o
        npm install
    - name: Build
      run: npm run build
    
    - name: Sync
      env:
        dest: '[email protected]:/mydir/wp-content/themes/mytheme'
      run: |
        echo "${{secrets.DEPLOY_KEY}}" > deploy_key
        chmod 600 ./deploy_key
        rsync -chav --delete \
          -e 'ssh -i ./deploy_key -o StrictHostKeyChecking=no' \
          --exclude /deploy_key \
          --exclude /.git/ \
          --exclude /.github/ \
          --exclude /node_modules/ \
          ./ ${{env.dest}}

Um den Workflow zu testen, committen Sie die Änderungen, ziehen Sie sie in Ihr lokales Repository und lösen Sie die Bereitstellung aus, indem Sie Ihren master-Branch auf den production-Branch pushen

git push origin master:production

Sie können den Status der Ausführung verfolgen, indem Sie zur Registerkarte „Actions“ in GitHub gehen, dann die letzte Ausführung auswählen und auf den „deploy“-Job klicken. Die grünen Häkchen zeigen an, dass alles reibungslos verlief. Wenn es Probleme gibt, überprüfen Sie die Protokolle des fehlgeschlagenen Schritts, um diese zu beheben.

Den vollständigen Bericht auf GitHub prüfen

---

Herzlichen Glückwunsch! Sie haben Ihr WordPress-Theme erfolgreich auf einem Server bereitgestellt. Die Workflow-Datei kann leicht für zukünftige Projekte wiederverwendet werden, was die Einrichtung kontinuierlicher Bereitstellungen zum Kinderspiel macht.

Um Ihren Bereitstellungsprozess weiter zu verfeinern, sind die folgenden Themen erwähnenswert

• Caching von Abhängigkeiten zur Beschleunigung des GitHub-Workflows
• Aktivieren des WordPress-Wartungsmodus während der Dateisynchronisierung
• Löschen des Website-Caches eines Plugins (wie z. B. Cache Enabler) nach der Bereitstellung