CI/CD für Webprojekte: Automatisierte Deployments einfach gemacht

Eine CI/CD-Pipeline für ein Webprojekt muss drei Dinge können: bei jedem Push automatisch bauen, testen und ausrollen — und bei einem Fehler auf die letzte funktionierende Version zurückgehen. Für kleine Teams genügen dafür wenige Schritte und meist vorhandene Werkzeuge; entscheidend ist der Rollback, nicht die Anzahl der Stages.

Der häufigste Auslöser für eine kaputte Website ist kein Angriff, sondern ein Deployment: eine Datei vergessen, eine Umgebungsvariable nur lokal gesetzt, ein Build, der auf dem eigenen Rechner lief. Eine Pipeline behebt das nicht durch Magie, sondern dadurch, dass immer derselbe Ablauf ausgeführt wird — auch freitags um 17 Uhr.

##Was muss eine kleine Pipeline können?

Für ein mittelständisches Webprojekt reichen vier Schritte: Abhängigkeiten aus einer Lockdatei installieren, prüfen (Linter, Typprüfung, Tests), bauen, ausliefern. Entscheidend ist nicht die Zahl der Stufen, sondern dass ein Fehlschlag den Ablauf stoppt. Eine Pipeline, die trotz roter Tests deployt, ist ein automatisierter Weg, Fehler schneller in Produktion zu bringen.

• ›Reproduzierbare Installation: Lockdatei committen, exakte Versionen, kein Update während des Builds.
• ›Prüfen vor Bauen: Linter und Typprüfung kosten Sekunden und fangen die Hälfte der Fehler.
• ›Ein Artefakt bauen und genau dieses ausliefern — nicht auf dem Zielserver neu bauen.
• ›Geheimnisse aus dem Secret-Store, niemals im Repository oder im Build-Log.
• ›Deployment-Ergebnis sichtbar machen: eine Nachricht mit Version und Zeitpunkt.

##Warum gehört der Rollback zum Deployment?

Die Frage ist nicht, ob ein Release einmal schiefgeht, sondern wie lange es dauert, ihn zurückzunehmen. Praktikabel sind zwei Wege: das vorherige Artefakt erneut ausliefern oder auf den vorherigen Container-Tag zurückschalten. Beides muss vorher einmal geübt worden sein — ein Rollback, den niemand kennt, ist im Ernstfall eine Diskussion statt einer Maßnahme.

Datenbankänderungen brauchen eine eigene Regel, weil sie sich nicht ohne Weiteres zurücknehmen lassen. Bewährt hat sich, Migrationen additiv zu halten: erst die neue Spalte hinzufügen und beide Wege bedienen, im nächsten Release die alte entfernen. Dann bleibt jeder Zwischenstand lauffähig.

##Womit lohnt es sich zuerst?

Wenn heute noch von Hand deployt wird, ist die Reihenfolge klar: erst ein Skript, das den Ablauf beschreibt, dann derselbe Ablauf in der Pipeline, dann Prüfungen davor, zuletzt automatische Auslösung bei jedem Merge. Jeder Schritt ist einzeln nützlich, und niemand muss ein Wochenende in eine vollständige Automatisierung investieren, bevor sich etwas verbessert.

##Was darf eine Pipeline kosten?

Rechnen Sie in Minuten, nicht in Euro: Eine Pipeline, die zwanzig Minuten braucht, wird umgangen; eine, die drei Minuten braucht, wird benutzt. Die üblichen Bremsen sind eine vollständige Neuinstallation der Abhängigkeiten bei jedem Lauf und Tests, die gegen echte externe Dienste laufen. Ein Cache für Abhängigkeiten und ein Testlauf gegen lokale Attrappen bringen die Laufzeit meist unter fünf Minuten.

Bei den Kosten der Ausführung gilt dasselbe Maß: Für ein Projekt mit wenigen Deployments pro Woche reicht das kostenlose Kontingent der gängigen Anbieter bei Weitem. Wer es überschreitet, hat meist keine Kostenfrage, sondern eine Laufzeitfrage.

##Sind Vorschau-Umgebungen den Aufwand wert?

Sobald der Build reproduzierbar ist, kostet eine Umgebung pro Branch fast nichts mehr — und sie verändert die Zusammenarbeit spürbar: Kundinnen und Kolleginnen sehen die Änderung, bevor sie live ist, statt sie sich anhand von Screenshots vorzustellen. Wichtig ist nur, diese Umgebungen mit noindex auszuliefern und nach dem Merge wieder abzubauen.