CI/CD-Pipeline für Webanwendungen: Praxisleitfaden

Kurz gefasst: Eine CI/CD-Pipeline prüft jede Codeänderung automatisch und bringt sie auf Knopfdruck oder vollautomatisch in Produktion. Für eine typische Webanwendung reichen dafür wenige Stufen: Abhängigkeiten installieren, Linting und Typprüfung, Tests, Build, Deployment auf eine Vorschau-Umgebung und schließlich auf Produktion. Mit GitHub Actions oder GitLab CI ist eine solche Pipeline an einem Tag aufgesetzt. Der eigentliche Aufwand liegt darin, sie schnell und zuverlässig zu halten.

Was CI und CD eigentlich bedeuten

Continuous Integration (CI) heißt: Jede Änderung wird früh in den Hauptzweig integriert und dabei automatisch gebaut und getestet. Fehler fallen so auf, solange sie noch klein sind. Continuous Delivery bedeutet, dass jeder erfolgreiche Stand jederzeit auslieferbar ist. Continuous Deployment geht einen Schritt weiter und spielt ihn ohne manuelle Freigabe aus.

Für die meisten Teams ist Continuous Delivery mit einem bewussten Klick für Produktion ein guter Mittelweg. Wer viele Tests und gutes Monitoring hat, kann später auf vollautomatisches Deployment umstellen.

Die Stufen einer praxistauglichen Pipeline

Prüfen: Linting, Typen, Formatierung

Die erste Stufe ist die schnellste und fängt die meisten banalen Fehler ab. ESLint, Prettier und bei TypeScript-Projekten tsc --noEmit laufen in Sekunden bis wenigen Minuten. Sie sollten bei jedem Pull Request laufen und einen Merge blockieren, wenn sie fehlschlagen.

Testen

Unit-Tests prüfen einzelne Funktionen, Integrationstests das Zusammenspiel mit Datenbank und API, End-to-End-Tests mit Playwright oder Cypress den Weg durch die Oberfläche. E2E-Tests sind langsam und anfälliger, deshalb reicht meist eine kleine Auswahl für die kritischen Abläufe wie Login und Checkout. Mehr zur Gewichtung finden Sie in unserem Beitrag zu Teststrategien für React-Anwendungen.

Build und Artefakt

Der Build sollte genau einmal entstehen und dann unverändert durch alle Umgebungen wandern, etwa als Docker-Image mit eindeutigem Tag. Wer für Staging und Produktion getrennt baut, testet streng genommen nicht das, was später live geht. Umgebungsspezifische Werte gehören in Umgebungsvariablen, nicht in den Build.

Vorschau-Umgebungen

Für jeden Pull Request eine eigene, kurzlebige Umgebung mit eigener URL: Das macht Reviews für Entwickler und Fachabteilung deutlich einfacher. Plattformen wie Vercel oder Netlify bieten das von Haus aus, bei eigener Infrastruktur lässt es sich mit Containern und etwas Automatisierung nachbauen.

Deployment und Rollback

Das Deployment auf Produktion sollte reproduzierbar und umkehrbar sein. Blue-Green- oder Rolling-Deployments vermeiden Ausfallzeiten, und ein Rollback auf das vorherige Image muss mit einem Befehl möglich sein. Datenbankmigrationen sind dabei der heikle Teil. Wie Sie sie ohne Downtime ausrollen, beschreibt unser Artikel zu Datenbankmigrationen ohne Ausfallzeit.

Welche Werkzeuge sich eignen

Liegt Ihr Code auf GitHub, ist GitHub Actions meist die naheliegende Wahl. GitLab CI ist ähnlich mächtig und lässt sich komplett selbst hosten, was für Unternehmen mit strengen Datenschutzvorgaben interessant ist. Ergänzend verwaltet man die Infrastruktur, auf die deployt wird, am besten ebenfalls als Code, etwa mit Terraform. Wie das aussieht, zeigt unser Beitrag zu Infrastructure as Code mit Terraform.

Bei Monorepos mit mehreren Paketen helfen Werkzeuge wie Turborepo oder Nx, nur das neu zu bauen und zu testen, was sich tatsächlich geändert hat.

Typische Stolpersteine

Langsame Pipelines sind der häufigste Grund, warum Teams sie umgehen. Cachen Sie Abhängigkeiten und Build-Ergebnisse, lassen Sie unabhängige Jobs parallel laufen und halten Sie die Rückmeldung für einen Pull Request möglichst kurz.

Instabile Tests, die mal grün und mal rot sind, zerstören das Vertrauen in die Pipeline. Reparieren oder entfernen Sie sie, statt den Job einfach neu zu starten. Und Zugangsdaten gehören in den Secret-Speicher des CI-Systems, niemals ins Repository. Geben Sie jedem Job nur die Rechte, die er wirklich braucht.

Zuletzt: Nach dem Deployment endet die Arbeit nicht. Ohne Monitoring und Alerts merken Sie einen fehlerhaften Release erst, wenn Kunden anrufen.

Häufige Fragen (FAQ)

Lohnt sich CI/CD auch für kleine Projekte?

Ja. Schon eine einfache Pipeline mit Linting, Tests und automatischem Deployment verhindert viele Fehler, die bei manuellem Hochladen passieren. Der Einrichtungsaufwand ist bei kleinen Projekten gering und zahlt sich schnell aus.

GitHub Actions oder GitLab CI?

Das hängt vor allem davon ab, wo Ihr Code liegt. Beide decken die typischen Anforderungen einer Webanwendung ab. GitLab lässt sich vollständig selbst betreiben, was bei strengen Vorgaben zum Datenstandort ein Argument sein kann.

Wie lange darf eine Pipeline dauern?

So kurz wie möglich. Wenn Entwickler für jeden Pull Request lange auf Rückmeldung warten, arbeiten sie an anderen Dingen weiter und verlieren den Kontext. Caching, parallele Jobs und eine schlanke Auswahl an E2E-Tests helfen dabei am meisten.

Sollte jede Änderung automatisch live gehen?

Nicht zwingend. Viele Teams fahren gut mit automatischem Deployment auf Staging und einer bewussten Freigabe für Produktion. Vollautomatisches Deployment setzt eine gute Testabdeckung, Monitoring und einen schnellen Rollback voraus.

Fazit

Eine gute CI/CD-Pipeline besteht aus wenigen kleinen, verlässlichen Stufen, die jede Änderung durchlaufen muss. Entscheidend ist, dass das Team ihr vertraut: Sie muss schnell sein, stabile Ergebnisse liefern und im Ernstfall einen Rollback erlauben. Wenn Sie für Ihre Webanwendung eine solche Grundlage aufbauen möchten, unterstützen wir Sie gern im Rahmen unserer Webentwicklung.