Computer steht auf einem Tisch

CI/CD-Ready — Deployment

GitLab-Pipelines prüfen Code-Qualität, 
führen End-to-End-Tests, Lighthouse-Checks und 
visuelle Regressionstests durch – 
bevor ein atomisches Deployment live geht.

Eine automatisierte Deployment-Pipeline stellt sicher, dass Änderungen zuverlässig und reproduzierbar ausgeliefert werden – ohne manuelle Fehler und mit gleichbleibender Qualität. Durch die automatisierten Schritte von Code-Qualitätsprüfung über Tests bis hin zum Deployment verkürzt sich die Time-to-Market deutlich. Gleichzeitig schaffen transparente Pipeline-Läufe und ein zentrales Dashboard volle Nachvollziehbarkeit für Entwicklung, QA und Fachbereich. So wird jedes Release kalkulierbar, messbar und bleibt auch bei wachsender Komplexität stabil.

Die vier Qualitätsstufen der Pipeline

Code Quality

PHPStan, PHPCS und ESLint prüfen automatisch Codequalität und Coding Standards bei jedem Push.

E2E Tests

Playwright testet alle Komponenten auf Create, Edit und Delete – vollautomatisch im CI.

Lighthouse

Performance, Accessibility und SEO werden mit Lighthouse gegen definierte Schwellwerte geprüft.

Visual Regression

BackstopJS erkennt unerwartete visuelle Änderungen durch Screenshot-Vergleiche auf Pixel-Ebene.

Stufe 1: Code Quality

Die erste Pipeline-Stufe stellt sicher, dass der Code den definierten Qualitätsstandards entspricht, bevor aufwändigere Tests gestartet werden.

  • PHPStan (Level 6) – Statische Analyse für PHP: erkennt Typfehler, undefinierte Variablen und nicht erreichbaren Code.
  • PHP_CodeSniffer (Drupal-Standard) – Prüft Coding Standards, Dokumentation und Formatierung nach den offiziellen Drupal-Richtlinien.
  • ESLint – Analysiert JavaScript und TypeScript auf Fehler und Stilprobleme im Frontend-Code.
  • Composer Validate – Verifiziert die Integrität von composer.json und composer.lock.

Schlägt eine dieser Prüfungen fehl, wird die Pipeline sofort gestoppt und der Entwickler per GitLab-Notification informiert.

Stufe 2: E2E Tests mit Playwright

Playwright führt vollständige End-to-End-Tests im echten Browser durch. Jede Canvas-Komponente wird in den drei kritischen Interaktionsszenarien getestet.

Create

Erstellt jede Komponente im Canvas-Editor, befüllt alle Pflichtfelder und verifiziert, dass die Komponente korrekt auf dem Frontend gerendert wird.

Edit

Öffnet bestehende Komponenten, ändert Inhalte und Einstellungen und prüft, ob die Änderungen gespeichert und korrekt dargestellt werden.

Delete

Löscht Komponenten aus dem Canvas und verifiziert, dass sie vollständig entfernt wurden und keine Rückstände im DOM verbleiben.

Stufe 3: Lighthouse

Lighthouse misst automatisch Performance, Accessibility, Best Practices und SEO für jede definierte Seite.

  • Performance ≥ 85 – Core Web Vitals, LCP, CLS, FID
  • Accessibility ≥ 90  – WCAG-Konformität, ARIA-Labels, Kontraste
  • SEO ≥ 90 – Meta-Tags, Canonical URLs, strukturierte Daten
  • Best Practices ≥ 85 - HTTPS, keine Console-Errors, sichere Abhängigkeiten

Unterschreitet eine Seite einen Schwellwert, bricht die Pipeline ab.

Stufe 4: Visual Regression

BackstopJS erstellt bei jedem Pipeline-Lauf Screenshots aller kritischen Seitenansichten und vergleicht sie pixel-genau mit den Referenzbildern.

  • Desktop, Tablet, Mobile – alle Breakpoints werden getestet
  • Diff-Visualisierung  – abweichende Bereiche werden farblich markiert
  • Referenz-Update  – neue Referenzbilder per GitLab-Job erstellt
  • Mismatch-Toleranz 0.1% – minimale Schwelle für Rendering-Unterschiede

Visuelle Regressionen werden sofort als Artefakt im Pipeline-Report sichtbar.

Alle Testergebnisse im GitLab Dashboard

Playwright HTML-Report, Lighthouse-Ergebnisse, BackstopJS-Diffs und PHPStan-Output werden als GitLab Pages als zentrales Dashboard publiziert. Kein lokales Setup nötig – alle Testergebnisse sind über eine URL im Browser einsehbar.

Atomic Deployment – Zero Downtime

Das Deployment erfolgt atomar: Die neue Version wird vollständig vorbereitet, bevor per Symlink-Swap auf sie umgestellt wird. Die Seite ist zu keinem Zeitpunkt während des Deployments nicht erreichbar.

Build & Vorbereitung

Composer Install, Theme-Build (Tailwind), Config-Import und Datenbank-Updates werden in einem isolierten Release-Verzeichnis ausgeführt. Die laufende Seite bleibt unberührt.

Symlink-Swap

Ein einziger atomarer Symlink-Wechsel aktiviert die neue Version. Der Wechsel dauert Millisekunden – laufende Requests werden noch vom alten Release beantwortet.

Smoke Tests & Rollback

Nach dem Swap prüfen Smoke Tests automatisch kritische Routen. Schlägt ein Test fehl, wird der Symlink sofort auf das vorherige Release zurückgesetzt.