CI/CD (Continuous Integration/Deployment)

Definition: CI/CD steht für Continuous Integration (CI) und Continuous Deployment/Delivery (CD). Continuous Integration bedeutet dass alle Entwickler ihre Code-Änderungen regelmäßig (mehrfach täglich) in ein gemeinsames Repository integrieren und automatische Tests ausgeführt werden. Continuous Deployment geht einen Schritt weiter: Jede erfolgreich getestete Änderung wird automatisch in die Produktionsumgebung deployt ohne manuelle Freigabe. Continuous Delivery hält die Codebase jederzeit deploybar, erfordert aber manuellen Schritt für Production-Deployment. Für Marketing-Teams ermöglicht CI/CD schnelle und fehlerreduzierte Deployments von Landingpages, A/B-Tests, Tracking-Implementierungen und SEO-Konfigurationen.

Erläuterung

Ohne CI/CD ist jedes Deployment ein Risiko: manueller Code-Upload auf Produktionsserver, keine automatischen Tests, keine konsistente Umgebung. Fehler die in einer regulären CI/CD-Pipeline in der Testphase aufgefangen würden, landen direkt auf der Live-Website und kosten Traffic und Conversions. Für Marketing-Teams ist CI/CD besonders relevant wenn Tracking-Änderungen, Meta-Tag-Updates oder Landingpage-Varianten schnell und sicher ausgerollt werden müssen.

CI/CD-Pipeline-Phasen

Source Stage: Entwickler pusht Code-Änderung in Git-Repository (GitHub, GitLab, Bitbucket); Pull Request / Merge Request triggert Pipeline-Start; Branch-basierte Pipelines erlauben Isolierung von Features; Code-Review vor Merge als erste Qualitätsstufe
Build Stage: Automatischer Build des Projekts (npm build, webpack, Docker Image Build); Fehler beim Build stoppen Pipeline; Abhängigkeiten werden installiert (npm install, pip install); Build-Artefakte für nächste Stages bereitgestellt; Build-Cache beschleunigt wiederholte Builds
Test Stage: Unit Tests (einzelne Funktionen); Integration Tests (Zusammenspiel von Komponenten); End-to-End Tests (Playwright, Cypress: simulieren Nutzerpfade im Browser); Linting und Code-Qualitätschecks; Performance-Tests; SEO-Checks (Canonical, Meta-Tags, robots.txt)
Staging Deployment: Deploy auf Staging/Preview-Umgebung (identisch mit Production aber nicht öffentlich); manuelle Prüfung durch QA, Marketing oder Stakeholder; Preview-URLs für Pull Requests (Vercel, Netlify); Trackingimplementierungen in Staging-Umgebung testen
Production Deployment: Automatisch (Continuous Deployment) nach erfolgter Test-Stage oder manuell genehmigt (Continuous Delivery); Blue-Green Deployment, Canary Release oder Rolling Update als Deployment-Strategien; automatischer Rollback bei erhöhter Fehlerrate nach Deployment

CI/CD-Tools und Plattformen

GitHub Actions: In GitHub integriert; YAML-basierte Workflow-Definition; großes Marketplace-Ökosystem für vorgefertigte Actions; kostenlos für öffentliche Repositories; Standard für GitHub-gehostete Projekte; einfache Integration mit Vercel, Netlify, AWS
GitLab CI/CD: In GitLab integriert; gitlab-ci.yml als Konfigurationsdatei; eingebautes Container Registry; Self-Hosted-Option für sensible Daten; Auto DevOps für automatische Pipeline ohne manuelle Konfiguration
Jenkins: Open-Source; sehr flexibel und erweiterbar; Self-Hosted; Groovy-basierte Jenkinsfile; Enterprise-Standard in größeren Unternehmen; höherer Administrationsaufwand als Cloud-Lösungen
Vercel/Netlify: Spezialisiert auf Frontend-Deployments; automatisches Preview-Deployment für jeden Branch/PR; sehr einfaches Setup für statische Sites und JAMstack; kostenlos für kleinere Projekte; integriertes CDN

Marketing-relevante CI/CD-Anwendungsfälle

Automatische SEO-Checks: Lighthouse-Audit als CI-Step; prüft automatisch Performance-Score, SEO-Score, fehlende Meta-Tags, Canonical-Tags, robots.txt-Konsistenz; bricht Build bei kritischen SEO-Regressionen ab; verhindert dass fehlerhafte noindex-Tags oder defekte Canonicals in Production gelangen
Tracking-Deployment-Sicherheit: Automatische Tests für Google Analytics und GTM Snippet-Präsenz; E2E-Tests die prüfen ob Conversion-Events bei Testbestellungen feuern; Staging-Prüfung von Pixel-Implementierungen vor Live-Gang
Feature Flags Integration: Neue Features per Feature Flag deployt statt direkt live; Feature in Production deployt aber deaktiviert; schrittweise Aktivierung für 5 % → 20 % → 100 % der Nutzer; Rollback durch Flag-Toggle ohne neues Deployment

Praxistipp: Fügen Sie in jede CI/CD-Pipeline einen automatischen Lighthouse-CI-Check ein (lighthouse-ci npm package): Dieser prüft bei jedem Deployment ob Performance-Score, SEO-Score und Accessibility-Score die definierten Mindestgrenzen einhalten. Konfigurieren Sie Schwellenwerte (z. B. Performance ≥ 80, SEO ≥ 90) und lassen Sie den Build fehlschlagen wenn diese unterschritten werden. Das kostet keine manuelle Prüfzeit und verhindert die häufigste Ursache für plötzliche Ranking-Einbrüche: versehentliche technische Regression durch ein unscheinbares Deployment.