Smoke Tests für Magento nach dem Deployment automatisieren

1. Warum Smoke Tests unverzichtbar sind

Ein Deployment-Prozess, der keine Verifikation nach dem Symlink-Wechsel enthält, endet technisch, aber nicht fachlich. Der Pipeline-Job hat Exit-Code 0 gemeldet, der Symlink zeigt auf das neue Release-Verzeichnis, der Cache wurde geleert — aber niemand hat überprüft, ob Magento tatsächlich korrekt antwortet. In der Praxis sind einige der häufigsten Post-Deploy-Probleme nicht durch den Deployment-Prozess selbst verursacht, sondern durch Faktoren, die erst nach dem Wechsel sichtbar werden: eine Klasse, die in der neuen Version einen Autoload-Fehler auslöst, ein Cache, der nicht vollständig geleert wurde, eine Shared-Datei, die fehlt oder falsche Berechtigungen hat.

Smoke Tests sind einfache, schnelle Prüfungen, die bestätigen, dass die wichtigsten Funktionen der Anwendung nach dem Deploy noch grundlegend funktionieren. Sie sind kein Ersatz für umfassende Integration- oder End-to-End-Tests, die Minuten oder Stunden dauern — sie sind das 60-Sekunden-Netz, das offensichtliche Ausfälle sofort erkennt und bei einem automatisierten Deployment einen Rollback auslösen kann, bevor der erste Endkunde den Fehler sieht.

In GitLab CI/CD gehören Smoke Tests in die verify-Stage, die nach der deploy-Stage läuft. Wenn ein Smoke-Test-Job fehlschlägt, schlägt die gesamte Pipeline fehl. Das ist das Signal, das entweder einen manuellen Rollback-Job auslöst oder — in einem vollautomatisierten Setup — direkt den Rollback-Schritt triggert. Mit dieser Struktur ist der Deployment-Prozess nicht bei deployed abgeschlossen, sondern erst bei deployed und verifiziert.

2. Welche Smoke Tests für Magento sinnvoll sind

Smoke Tests für Magento lassen sich in drei Kategorien einteilen: HTTP-Checks testen, ob bestimmte URLs des Shops korrekte HTTP-Statuscodes zurückgeben und bestimmte Inhalte enthalten. CLI-Health-Checks prüfen über SSH auf dem Server den Zustand der Magento-Installation — Cache-Status, Maintenance-Mode-Status, Modul-Status. Service-Checks prüfen, ob externe Dienste wie Redis, RabbitMQ oder OpenSearch erreichbar und funktional sind.

Für die meisten Magento-Setups reichen zehn bis fünfzehn gezielte Checks aus, um die kritischsten Pfade abzudecken. Die wichtigsten sind: HTTP 200 für die Startseite, die Kategorie- und Produktseite, den Checkout und die Kundenlogin-Seite. HTTP 200 für den Health-Check-Endpoint (falls vorhanden). Cache-Status via CLI — kein einziger Cache-Typ sollte den Status disabled haben außer wenn explizit gewollt. Maintenance-Mode-Status — muss 0 (deaktiviert) sein. Magento-Deployment-Logs auf Fehler der letzten fünf Minuten prüfen. Diese Checks dauern zusammen weniger als 30 Sekunden und decken die häufigsten Post-Deploy-Fehlerbilder ab.

3. HTTP-Checks: Statuscode und Response-Inhalt prüfen

HTTP-Checks mit curl sind das einfachste und zuverlässigste Mittel für externe Smoke Tests. Das Flag -f bei curl lässt den Befehl mit einem Fehlercode beenden, wenn der HTTP-Statuscode 4xx oder 5xx ist. Das Flag --max-time setzt einen Timeout, sodass hängende Anfragen den Pipeline-Job nicht ewig blockieren. Für komplexere Prüfungen kann grep oder jq eingesetzt werden, um den Response-Body auf erwartete Inhalte zu prüfen — zum Beispiel ob die Startseite tatsächlich den Shop-Namen enthält und nicht eine Fehlermeldung oder einen leeren Body.

Ein wichtiger Aspekt bei HTTP-Checks in CI-Pipelines: Der GitLab-Runner muss Netzwerkzugang zur Ziel-URL haben. Wenn der Produktionsserver nicht aus dem Internet erreichbar ist, muss der Runner im selben Netzwerksegment wie der Server laufen oder über einen internen DNS-Namen angesprochen werden. Für Staging-Umgebungen ist das in der Regel unkompliziert. Für Production-Server hinter Firewalls oder in privaten Netzwerken muss der Self-Hosted-Runner explizit Netzwerkzugang konfiguriert bekommen.

4. CLI-Health-Checks über SSH

CLI-Health-Checks laufen über SSH auf dem Zielserver und rufen dort Magento-Befehle auf. Sie ergänzen die HTTP-Checks um interne Zustände, die von außen nicht sichtbar sind: Cache-Status, Wartungsmodus, Modul-Aktivierung und Deployment-Log-Fehler. Der SSH-Key für diese Verbindung ist bereits als Protected-Variable in GitLab gespeichert und wird im Deploy-Job verwendet — derselbe Key kann im Verify-Job genutzt werden.

Der wichtigste CLI-Check für Magento nach einem Deploy ist bin/magento cache:status. Er gibt den Status aller Cache-Typen aus — wenn einer der Cache-Typen als 0 (deaktiviert) angezeigt wird, obwohl er aktiviert sein sollte, deutet das auf ein Problem mit dem Deploy hin. Ebenso kritisch: bin/magento maintenance:status muss 0 zurückgeben. Ein vergessenes maintenance:disable am Ende des Deploy-Skripts ist ein klassischer Fehler, der den Shop für Endkunden unerreichbar macht — ein Check, der genau das erkennt, ist unverzichtbar.

5. Vollständiger verify-Job in GitLab CI/CD

Der folgende verify-Job kombiniert HTTP-Checks und CLI-Health-Checks in einem einzigen GitLab-Job, der nach dem erfolgreichen Deploy-Job läuft. Bei Fehlschlag schlägt der gesamte Job fehl, was die Pipeline als gescheitert markiert und Benachrichtigungen an das Team auslöst.

# .gitlab-ci.yml — verify stage with smoke tests for Magento
verify:production:
  stage: verify
  image: alpine:latest
  before_script:
    # Install curl and openssh for HTTP and CLI checks
    - apk add --no-cache curl openssh-client bash
    # Configure SSH for deployment server access
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
  script:
    # --- HTTP Smoke Tests ---
    # Check homepage: must return HTTP 200
    - |
      curl -sf --max-time 15 --retry 3 --retry-delay 5 \
        -o /dev/null -w "HTTP %{http_code} homepage\n" \
        "https://${SHOP_DOMAIN}/" || (echo "FAIL: Homepage did not return 200" && exit 1)
    # Check category page: must return HTTP 200
    - |
      curl -sf --max-time 15 \
        -o /dev/null -w "HTTP %{http_code} category\n" \
        "https://${SHOP_DOMAIN}/catalogsearch/result/?q=test" || exit 1
    # Check checkout: must return HTTP 200 (not redirect loop or 500)
    - |
      curl -sf --max-time 15 -L \
        -o /dev/null -w "HTTP %{http_code} checkout\n" \
        "https://${SHOP_DOMAIN}/checkout/" || exit 1
    # Check customer login page
    - |
      curl -sf --max-time 15 \
        -o /dev/null -w "HTTP %{http_code} customer-login\n" \
        "https://${SHOP_DOMAIN}/customer/account/login/" || exit 1
    # --- CLI Health Checks via SSH ---
    # Check maintenance mode: must be disabled (output: Status: 0)
    - |
      ssh -o StrictHostKeyChecking=no \
        "${DEPLOY_USER}@${DEPLOY_HOST}" \
        "cd ${DEPLOY_PATH}/current && php bin/magento maintenance:status" \
        | grep -q "Status: 0" || (echo "FAIL: Maintenance mode is still enabled" && exit 1)
    # Check cache status: no cache type should be disabled
    - |
      ssh "${DEPLOY_USER}@${DEPLOY_HOST}" \
        "cd ${DEPLOY_PATH}/current && php bin/magento cache:status" \
        | grep -v "^$" | grep -v "Current status" \
        | awk '{print $NF}' | grep -q "^0$" \
        && echo "FAIL: One or more cache types are disabled" && exit 1 || true
    # Check Magento deployment log for recent errors
    - |
      ssh "${DEPLOY_USER}@${DEPLOY_HOST}" \
        "find ${DEPLOY_PATH}/current/var/log -name 'support_report*.log' \
          -newer ${DEPLOY_PATH}/current/var/.deploy_timestamp \
          -exec grep -l 'ERROR\|CRITICAL' {} \;" \
        | grep -q "." \
        && echo "WARN: Error logs found after deployment" || true
  environment:
    name: production
  when: on_success
  allow_failure: false
  tags:
    - deploy
    - shell
  needs:
    - job: deploy:production

Drei Details in diesem verify-Job sind besonders wichtig: Erstens verwendet curl die Flags --retry 3 und --retry-delay 5, sodass vorübergehende Netzwerkprobleme nicht sofort zu einem Testfehler führen. Magento braucht nach dem Cache-Flush manchmal einige Sekunden, bis der erste Request vollständig gerendert wird — Wiederholungsversuche überbrücken diese kurze Warmup-Phase. Zweitens ist allow_failure: false explizit gesetzt: Der Job darf nicht als Warnung durchgehen. Drittens ist needs: [deploy:production] gesetzt, sodass der verify-Job direkt nach dem Deploy-Job startet, ohne auf andere parallele Jobs zu warten.

6. Automatisches Rollback bei fehlgeschlagenen Tests

Wenn ein Smoke-Test-Job fehlschlägt, ist das der Zeitpunkt, zu dem entweder manuell oder automatisch ein Rollback eingeleitet wird. GitLab unterstützt beide Modelle. Beim manuellen Modell gibt es einen Rollback-Job mit when: manual in der rollback-Stage, der nur bei einem gescheiterten verify-Job angeboten wird. Ein Entwickler klickt dann manuell auf den Rollback-Button in der GitLab-Pipeline-Ansicht. Das gibt dem Team Kontrolle, bevor der Rollback ausgeführt wird — sinnvoll, wenn der Verify-Job manchmal falsch-positive Fehler produziert.

Beim automatischen Rollback-Modell wird der Rollback-Job mit when: on_failure konfiguriert und läuft automatisch, wenn der verify-Job fehlschlägt. Das minimiert die Zeit, in der ein defektes Deployment aktiv ist. Das Risiko: Ein falsch-positiver Smoke-Test-Fehler (zum Beispiel durch einen kurzen Netzwerkausfall während des Tests) löst einen unnötigen Rollback aus. Deshalb ist es wichtig, die Smoke Tests robust zu gestalten — mit Retry-Mechanismen, realistischen Timeouts und Checks, die wirklich Magento-Probleme erkennen und nicht infrastrukturelle Schwankungen.

7. Timing: wann Smoke Tests laufen sollten

Smoke Tests müssen nach dem Symlink-Wechsel und nach dem Cache-Flush laufen — nicht davor. Würden sie vor dem Cache-Flush ausgeführt, testeten sie unter Umständen noch Responses aus dem alten Cache und erkennten keine Probleme mit dem neuen Release. Das korrekte Timing in der Pipeline: Deploy-Job (Symlink, env.php, Cache-Flush, maintenance:disable) → verify-Job (Smoke Tests).

Ein weiteres Timing-Problem tritt auf, wenn Magento nach dem Cache-Flush und Maintenance-Disable noch einige Sekunden für das Aufwärmen des neuen Cache braucht. Der erste Request nach dem Cache-Flush ist immer langsamer als folgende, weil Magento dann Configuration, Layout und Block-Ausgaben neu berechnet. Wenn der Smoke Test zu aggressiv ist — sehr kurzer Timeout, keine Retries — schlägt er möglicherweise genau bei diesem langsamen ersten Request fehl. Die Lösung: nach dem deploy-Job eine kurze Wartezeit (10–15 Sekunden) einbauen oder im curl-Befehl Retries mit Verzögerung nutzen.

8. Vergleich: verschiedene Test-Strategien

Es gibt verschiedene Ansätze, wie Smoke Tests nach Deployments implementiert werden können. Der Unterschied liegt im Aufwand, der Zuverlässigkeit und der Tiefe der Prüfung.

Die empfohlene Strategie für die meisten Magento-Teams ist die Kombination aus curl HTTP-Checks und SSH CLI-Checks: Sie ist in weniger als 60 Sekunden abgeschlossen, benötigt keine zusätzlichen Test-Frameworks und deckt die häufigsten Post-Deploy-Fehlerbilder ab. Playwright oder Cypress sind sinnvoll als separate Qualitätssicherung in der Test-Stage vor dem Deploy, nicht als Smoke Tests nach dem Deploy, weil sie zu zeitintensiv für die verify-Stage sind.

9. Typische Fehler bei Smoke Tests

Der häufigste Fehler bei Smoke Tests ist das Testen gegen eine URL, die Caching auf Infrastrukturebene (CDN, Varnish) betreibt und noch den alten Cache ausliefert, obwohl der Magento-Applikations-Cache bereits geleert wurde. Ein curl-Check gegen https://shop.example.com/ kann HTTP 200 zurückgeben, aber der Inhalt stammt noch aus Varnish-Cache des alten Releases. Lösung: Smoke Tests mit Cache-Control: no-cache-Header senden oder direkt gegen den Webserver ohne Varnish testen, sofern möglich.

Ein zweiter Fehler ist ein zu kurzes --max-time ohne Retries. Der erste Request nach dem Cache-Flush kann 5–10 Sekunden dauern, wenn Magento Configuration und Layout neu aufbauen muss. Ein Timeout von 5 Sekunden ohne Retry schlägt bei diesem ersten Request fehl, obwohl Magento korrekt funktioniert. Immer --retry 2 oder --retry 3 kombiniert mit einem angemessenen Timeout von 15–20 Sekunden verwenden. Ein dritter Fehler ist das Prüfen von zu vielen URLs im Smoke-Test-Job, was die Laufzeit auf mehrere Minuten ausdehnt. Smoke Tests sollen schnell sein — maximal zehn bis fünfzehn Checks, die zusammen unter 60 Sekunden bleiben.

10. Zusammenfassung

Automatisierte Smoke Tests nach Magento-Deployments sind der fachliche Abschluss eines Deployment-Prozesses. Ein Deployment ohne verify-Stage endet technisch — aber nicht mit der Gewissheit, dass Magento korrekt funktioniert. Die Kombination aus curl HTTP-Checks (Startseite, Kategorie, Checkout, Login) und SSH CLI-Checks (Maintenance-Status, Cache-Status) deckt die häufigsten Post-Deploy-Fehlerbilder in weniger als 60 Sekunden ab.

In GitLab CI/CD gehören Smoke Tests in die verify-Stage mit when: on_success und allow_failure: false. Bei fehlgeschlagenen Tests schlägt die Pipeline fehl und das Team wird benachrichtigt. Ein Rollback-Job in der rollback-Stage mit when: on_failure oder when: manual gibt dem Team die Möglichkeit, schnell zum vorherigen Release zurückzukehren. Mit dieser Struktur ist der Deployment-Prozess komplett: Build, Test, Deploy — und verifiziert.

11. FAQ: Smoke Tests für Magento nach dem Deployment