Den Checkout bei jedem Deployment mit GitHub Actions testen

Der vollständige Workflow zum Kopieren

Hier ist die ganze Datei. Der Job deploy bringt Ihre Website in Produktion. Danach lässt der Job tunnel-paiement Pathly Ihren Flow in einem echten Browser erneut abspielen, vom Produkt bis zur Zahlungsseite. Bricht ein Schritt, wird der Job rot.

Die Zeile needs: deploy legt die Reihenfolge fest. Der Job tunnel-paiement startet nur, wenn das Deployment erfolgreich war. Der Flow prüft also die Version, die gerade in Produktion gegangen ist, nicht die vorherige.

timeout_sec gibt der Action Zeit, auf das Ergebnis zu warten. Der Standardwert liegt bei 120 Sekunden. Ein Checkout führt über mehrere Seiten, deshalb lässt der Workflow fünf Minuten. Nach Ablauf dieser Frist bricht die Action ab und der Job schlägt fehl.

Drei Dinge müssen Sie noch vorbereiten: den Flow, den API-Schlüssel und die beiden Einstellungen des Repositorys. Die folgenden Abschnitte gehen sie in dieser Reihenfolge durch.

• GitHub pathly-action

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # Durch Ihren Deployment-Befehl ersetzen
      - run: ./scripts/deploy.sh

  tunnel-paiement:
    name: Checkout
    needs: deploy
    runs-on: ubuntu-latest
    steps:
      - name: Pathly Flow
        uses: pathlyhq/pathly-action@v1
        with:
          api_token: ${{ secrets.PATHLY_API_TOKEN }}
          operation: run-scenario
          scenario_id: ${{ vars.PATHLY_CHECKOUT_SCENARIO_ID }}
          timeout_sec: "300"

Warum nach dem Deployment testen

Ihre Tests vor dem Merge prüfen den Code. Die Produktion sehen sie nicht: ihre Umgebungsvariablen, ihren Cache, ihren Zahlungsanbieter, ihre Skripte von Drittanbietern. Ein Deployment kann den Checkout brechen, obwohl alle Tests grün sind.

Der typische Fall: Der Ping ist grün, der Flow ist rot. Die Website antwortet mit 200 und die Startseite wird angezeigt, aber der Button „Bestellen“ reagiert nicht mehr. Eine Verfügbarkeitsprüfung sieht das nicht. Ein Browser, der klickt, schon.

Diese Prüfung ersetzt Ihre Tests vor dem Merge nicht. Sie kommt danach. Die Tests sagen, dass der Code korrekt ist. Der Flow sagt, dass ein Kunde die Zahlungsseite noch erreicht, auf der echten Website, wenige Minuten nach dem Deployment.

Den Flow für den Checkout anlegen

Der Flow entsteht in der Konsole, mit dem Recorder, ohne Code zu schreiben. Sie öffnen Ihren Shop im Recorder und gehen den Weg eines Kunden. Pathly speichert jeden Klick als Schritt.

Typische Schritte: eine Produktseite öffnen, das Produkt in den Warenkorb legen, den Warenkorb öffnen, bis zur Zahlungsseite weitergehen. Fügen Sie am Ende eine Prüfung hinzu, zum Beispiel einen Text, den nur die Zahlungsseite zeigt.

Der Flow endet auf der Zahlungsseite. Er bezahlt nichts und gibt nur Testwerte ein. Wählen Sie ein Produkt, das immer verfügbar ist, möglichst eines nur für diese Prüfung.

Notieren Sie nach dem Speichern die Kennung des Flow. Sie ist eine UUID und steht in der Adresse der Flow-Seite in der Konsole. Im nächsten Schritt legen Sie sie in einer Variable des Repositorys ab.

Ein API-Schlüssel mit zwei Scopes

Legen Sie in der Konsole unter Einstellungen → API-Schlüssel einen Schlüssel an. Er beginnt mit sp_… und sein Geheimnis wird nur einmal angezeigt. Geben Sie ihm nur zwei Scopes: runs:trigger, um einen Run zu starten, und runs:read, um das Ergebnis zu lesen.

Legen Sie einen Schlüssel pro Repository an. Wird ein Repository kompromittiert, widerrufen Sie dessen Schlüssel, ohne die anderen anzufassen. Mit diesen beiden Scopes kann ein gestohlener Schlüssel keinen Flow anlegen, ändern oder löschen.

Öffnen Sie in GitHub Settings → Secrets and variables → Actions. Legen Sie den Schlüssel im Secret PATHLY_API_TOKEN ab. Legen Sie die Kennung des Flow in der Variable PATHLY_CHECKOUT_SCENARIO_ID ab. Die Kennung ist kein Geheimnis: Eine Variable genügt, und sie bleibt in den Logs lesbar.

Bevor Sie den Flow anbinden, machen Sie eine erste Prüfung mit operation: ping. Diese Operation prüft nur, ob die API den Schlüssel erkennt. Sie startet keinen Run.

- name: Pathly ping
  uses: pathlyhq/pathly-action@v1
  with:
    api_token: ${{ secrets.PATHLY_API_TOKEN }}
    operation: ping

run-scenario oder assert-scenario

Die Action bietet zwei Operationen, die sich ähneln. Nach einem Deployment brauchen Sie run-scenario. Sie startet mit POST /v1/scenarios/{id}/run einen neuen Run und fragt dann GET /v1/runs/{id} ab, bis ein Endstatus vorliegt. Das Ergebnis beschreibt also die Version, die Sie gerade ausgeliefert haben.

assert-scenario startet nichts. Sie liest das letzte bekannte Ergebnis des Flow, mit dem Scope scenarios:read. Dieses Ergebnis kann aus der Zeit vor dem Deployment stammen: Der Job wäre grün, obwohl die neue Version nie getestet wurde.

assert-scenario bleibt an anderer Stelle nützlich. Sie verbraucht keine Ausführung und antwortet sofort. Sie passt zu einer Prüfung vor einem riskanten Schritt, wenn der Flow ohnehin in regelmäßigen Abständen läuft. Direkt nach einem Deployment passt sie nicht.

- name: Pathly assert
  uses: pathlyhq/pathly-action@v1
  with:
    api_token: ${{ secrets.PATHLY_API_TOKEN }}
    operation: assert-scenario
    scenario_id: ${{ vars.PATHLY_CHECKOUT_SCENARIO_ID }}

Einen Fehlschlag lesen

Die Action deklariert drei Ausgaben: run_id, run_status und ok. run_status ist ok, fail oder error. Ist der Run nicht ok, schlägt der Job fehl. Sein Log zeigt dann die Kennung des Runs, seinen Status und seine Meldung: Beginnen Sie dort.

fail: Ein Schritt oder eine Prüfung des Flow schlägt fehl. Die Website antwortet, aber der Weg des Kunden ist unterbrochen. Genau diesen Fall soll die Prüfung abfangen: ein Button, der nicht mehr reagiert, ein leerer Warenkorb, eine Zahlungsseite, die nie erreicht wird.

error: Der Run ist wegen eines Netzwerk- oder Browserfehlers nicht bis zum Ende gelaufen. Website nicht erreichbar, Zeitüberschreitung beim Verbindungsaufbau, abgestürzter Browser. Eine Website, die nach dem Deployment gar nicht mehr antwortet, ergibt also error, nicht fail.

Für die Details rufen Sie GET https://api.pathlyhq.com/v1/runs/{id} mit demselben Schlüssel auf. Die Antwort liefert status, message und, wenn ein Screenshot existiert, screenshotUrl. Das ist ein signierter Link zum Screenshot des fehlgeschlagenen Schritts, 15 Minuten gültig. screenshotExpiresAt nennt den Zeitpunkt des Ablaufs. Rufen Sie die Route erneut auf, um einen neuen Link zu erhalten.

# RUN_ID: die Kennung aus dem Log des Jobs
curl -sS https://api.pathlyhq.com/v1/runs/$RUN_ID \
  -H "Authorization: Bearer $PATHLY_API_TOKEN" \
  | jq '{status, message, screenshotUrl, screenshotExpiresAt}'

curl -sS "https://api.pathlyhq.com/v1/runs?scenarioId=$PATHLY_CHECKOUT_SCENARIO_ID&limit=1" \
  -H "Authorization: Bearer $PATHLY_API_TOKEN" \
  | jq '.items[0] | {id, status, message}'

Reagieren: Rollback und Alarm

Ein roter Job nützt nichts, wenn niemand hinsieht. Fügen Sie einen Job rollback mit needs: tunnel-paiement und if: failure() hinzu. Er läuft nur, wenn die Prüfung fehlgeschlagen ist, und bringt die vorherige Version zurück in Produktion.

failure() ist wahr, sobald ein vorgelagerter Job fehlschlägt, das Deployment eingeschlossen. Die Bedingung needs.tunnel-paiement.result == 'failure' beschränkt den Rollback auf den Fehlschlag der Pathly-Prüfung allein.

Der Job ist bei fail wie bei error rot, aber die Reaktion ist verschieden. Bei fail ist der Weg des Kunden unterbrochen: Rollen Sie zurück. Bei error starten Sie den Job einmal neu. Kommt der Fehler wieder, rollen Sie ebenfalls zurück.

Informieren Sie auch das Team. Ein Webhook, der das Ereignis run.failed abonniert, leitet den Fehlschlag an Ihr Alarmierungswerkzeug weiter. Legen Sie ihn in der Konsole an oder per API mit einem Schlüssel mit alerting:write, getrennt vom Schlüssel der CI. Drittkanäle (Slack, Teams, Webhooks) gehören zu den kostenpflichtigen Tarifen.

  rollback:
    needs: tunnel-paiement
    if: failure() && needs.tunnel-paiement.result == 'failure'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # Durch Ihren Rollback-Befehl ersetzen
      - run: ./scripts/rollback.sh

# PATHLY_ALERTING_TOKEN: ein Schlüssel mit alerting:write, nicht der der CI
curl -sS -X POST https://api.pathlyhq.com/v1/webhooks \
  -H "Authorization: Bearer $PATHLY_ALERTING_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://www.example.com/hooks/pathly",
    "events": ["run.failed"]
  }'

Weiterführendes

Mehrere Shops: Legen Sie einen Flow pro Shop an und durchlaufen Sie deren Kennungen mit strategy.matrix. Jeder Shop bekommt seinen eigenen Job und sein eigenes Ergebnis. Mit fail-fast: false bricht der Fehlschlag eines Shops die Prüfung der anderen nicht ab.

Wartungsfenster: Wenn das Deployment die Website kurz unterbricht, öffnen Sie vor dem Deployment ein Fenster. Es schaltet die Alarme der regulären Überwachung für diesen Zeitraum stumm. Die Action hat dafür keine eigene Operation: Rufen Sie die API /v1/maintenance-windows mit einem anderen Schlüssel auf, der maintenance:write trägt.

ensure-scenario legt den Ping der Website an, wenn er noch nicht existiert. Gibt es ihn schon, bleibt er unverändert. Sie findet ihn über seinen Namen: Ein erneuter Lauf des Workflows erzeugt kein Duplikat. Diese Operation braucht den Scope scenarios:write, also einen anderen Schlüssel als den der Prüfung.

Zwei Deployments hintereinander: Ohne Schutz überschneiden sich zwei Prüfungen, und die zweite testet womöglich eine halb ausgelieferte Version. Ein concurrency-Block lässt den zweiten Lauf des Workflows warten, bis der erste beendet ist, Prüfung eingeschlossen.

  tunnel-paiement:
    needs: deploy
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        scenario_id:
          - ${{ vars.PATHLY_CHECKOUT_FR_SCENARIO_ID }}
          - ${{ vars.PATHLY_CHECKOUT_DE_SCENARIO_ID }}
    steps:
      - name: Pathly Flow
        uses: pathlyhq/pathly-action@v1
        with:
          api_token: ${{ secrets.PATHLY_API_TOKEN }}
          operation: run-scenario
          scenario_id: ${{ matrix.scenario_id }}
          timeout_sec: "300"

START=$(date -u +%Y-%m-%dT%H:%M:%SZ)
END=$(date -u -d "+15 minutes" +%Y-%m-%dT%H:%M:%SZ)

curl -sS -X POST https://api.pathlyhq.com/v1/maintenance-windows \
  -H "Authorization: Bearer $PATHLY_MAINTENANCE_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"startsAt\": \"$START\", \"endsAt\": \"$END\"}"

- name: Pathly Ping
  uses: pathlyhq/pathly-action@v1
  with:
    api_token: ${{ secrets.PATHLY_SETUP_TOKEN }}
    operation: ensure-scenario
    scenario_json: |
      {
        "name": "Home",
        "url": "https://www.example.com/",
        "intervalSec": 300
      }

concurrency:
  group: deploy-production
  cancel-in-progress: false

Typische Fallstricke

Das CDN liefert noch die alte Version aus. Der Flow prüft dann die vorherige Website, und der Job ist zu Unrecht grün. Leeren Sie den Cache im Job deploy und warten Sie das Ende der Leerung ab, bevor die Prüfung übernimmt.

Ein Bot-Schutz oder ein CAPTCHA blockiert den Browser von Pathly. Der Flow schlägt fehl, während Ihre Kunden durchkommen. Ein CAPTCHA stoppt diesen Browser wie jeden anderen Roboter: Halten Sie es von den Seiten fern, die der Flow durchläuft, oder sehen Sie in Ihrer Web Application Firewall eine Regel für diesen Testverkehr vor.

Das Testprodukt ist nicht mehr vorrätig. Der Button für den Warenkorb verschwindet, und der Flow wird rot, obwohl sich der Code nicht geändert hat. Reservieren Sie für den Test ein Produkt, das immer verfügbar ist.

Das Kontingent. Ein von der CI gestarteter Run zählt wie jeder andere zum Ausführungskontingent Ihres Tarifs. Ist das Kontingent erreicht und kein Ausführungspaket vorhanden, endet der Run mit fail und einer Kontingentmeldung, und der Job wird rot. Lesen Sie die Meldung, bevor Sie zurückrollen: Hier liegt es nicht an der Website.