CI/CD-Pipeline erstellen

Eine CI/CD-Pipeline erstellen bedeutet nicht, ein paar Schritte in einem Repository zu automatisieren. Sie definieren damit, unter welchen Bedingungen Änderungen in ein digitales Produkt gelangen, wer sie freigibt und wie schnell sich Fehler wieder zurücknehmen lassen. Für Anwendungen mit Nutzern, Schnittstellen und geschäftskritischen Prozessen ist das eine Betriebsentscheidung, keine bloße Entwickleraufgabe.

Der häufigste Fehler liegt im falschen Startpunkt: Teams wählen zuerst ein Werkzeug und modellieren anschließend ihren Prozess darum herum. Sinnvoller ist die umgekehrte Reihenfolge. Erst müssen Risiko, Architektur, Release-Frequenz und Betriebsanforderungen klar sein. Dann lässt sich entscheiden, welche Prüfungen und Freigaben eine Pipeline tatsächlich braucht.

Was eine CI/CD-Pipeline leisten muss

CI steht für Continuous Integration. Jede Änderung wird automatisiert gebaut und gegen definierte Qualitätskriterien geprüft. CD kann Continuous Delivery oder Continuous Deployment bedeuten. Bei Delivery ist ein Release jederzeit vorbereitet, die produktive Freigabe erfolgt bewusst. Bei Deployment wird eine erfolgreich geprüfte Änderung automatisiert ausgerollt.

Für viele etablierte Unternehmen ist Continuous Delivery der passende Einstieg. Ein automatischer Produktionsrollout kann sinnvoll sein, wenn Änderungen klein, gut testbar und technisch isoliert sind. Bei Datenmigrationen, Integrationen in Dynamics 365, regulatorischen Anforderungen oder Anwendungen mit hohen Verfügbarkeitsansprüchen bleibt eine explizite Freigabe oft die vernünftigere Entscheidung. Automatisierung ersetzt keine Verantwortung, sie macht Verantwortung nachvollziehbar.

Eine tragfähige Pipeline beantwortet im Kern vier Fragen: Ist die Änderung fachlich und technisch korrekt? Lässt sie sich sicher in die Zielumgebung bringen? Ist die neue Version nach dem Deployment tatsächlich nutzbar? Und wie wird der vorherige Zustand wiederhergestellt, wenn eine dieser Annahmen nicht stimmt?

Vor dem Aufbau: Risiken und Lieferweg festlegen

Bevor eine Pipeline konfiguriert wird, braucht das Projekt einen klaren Lieferweg. Dazu gehören mindestens die Repository-Strategie, Umgebungen, Freigaberegeln und der Umgang mit Konfigurationen. Eine typische Kette führt von einer lokalen Entwicklungsumgebung über Test oder Staging bis zur Produktion. Das heißt jedoch nicht, dass jede Umgebung eine identische Kopie der Produktion sein muss. Das wäre bei komplexen Fremdsystemen häufig unverhältnismäßig teuer.

Entscheidend ist, welche Risiken wo geprüft werden. Unit-Tests lassen sich schnell bei jeder Änderung ausführen. Integrationstests benötigen häufig Datenbanken, Message Queues oder externe APIs. End-to-End-Tests bilden reale Nutzerabläufe ab, sind aber langsamer und störanfälliger. Wer alle Tests bei jedem kleinen Commit ausführt, erkauft sich hohe Rückmeldezeiten. Wer nur am Ende testet, findet Fehler zu spät. Eine gute Pipeline verteilt Prüfungen deshalb nach Geschwindigkeit und Aussagekraft.

Auch Branching ist keine Glaubensfrage. Kurzlebige Feature-Branches mit Pull Requests unterstützen Reviews und isolieren Änderungen. Ein trunk-basierter Ansatz reduziert Merge-Konflikte und beschleunigt die Auslieferung, verlangt aber kleine Änderungen, Feature Flags und hohe Testdisziplin. Für ein wachsendes Produktteam kann beides funktionieren. Maßgeblich ist, ob der gewählte Ansatz verlässliche Releases ermöglicht und im Alltag eingehalten wird.

CI/CD-Pipeline erstellen: Der Ablauf in vier Phasen

Bei dreißigelf folgt der Aufbau einer Lieferkette derselben Logik wie die Produktverantwortung: verstehen und entscheiden, umsetzen und prüfen, integrieren und absichern, betreiben und weiterentwickeln. Die Pipeline ist dabei Teil der Architektur.

Verstehen und entscheiden

Zunächst wird geklärt, was ausgeliefert wird und welche Folgen ein fehlgeschlagenes Release hätte. Ein statisches Frontend, ein NestJS-Backend mit Datenbankmigrationen und eine mobile App haben unterschiedliche Lieferwege. Mobile Anwendungen durchlaufen zusätzlich Prüfungen und Freigaben der App Stores. Kubernetes-Workloads brauchen eine andere Rollback-Strategie als eine einzelne Serverless Function.

In dieser Phase werden auch messbare Qualitätsgrenzen definiert. Beispiele sind ein erfolgreiches Build, Linting, Type-Checking, eine Mindestabdeckung für kritische Module, Sicherheitsprüfungen für Abhängigkeiten und ein reproduzierbares Artefakt. Wichtig ist die Reihenfolge: Ein Build-Artefakt wird einmal erzeugt und anschließend in die Umgebungen befördert. Es sollte nicht für Staging und Produktion erneut aus unterschiedlichem Quellzustand gebaut werden.

Umsetzen und prüfen

Die CI-Stufe startet idealerweise bei jedem Pull Request. Sie installiert Abhängigkeiten reproduzierbar, erstellt das Build und führt die schnellen Prüfungen aus. Bei Container-Anwendungen entsteht dabei ein versioniertes Image, das mit Commit-ID oder Release-Tag eindeutig zuordenbar ist.

Tests allein reichen nicht. Statische Codeanalyse findet Fehlerklassen, bevor sie zur Laufzeit entstehen. Dependency-Scans decken bekannte Schwachstellen in Bibliotheken auf. Secret-Scanning verhindert, dass Zugangsdaten ins Repository gelangen. Für sensible Systeme können zusätzlich Container-Scans und Prüfungen der Infrastructure-as-Code-Konfiguration erforderlich sein. Nicht jede Warnung rechtfertigt einen Release-Stopp. Kritikalität, Erreichbarkeit und vorhandene Gegenmaßnahmen müssen bewertet werden. Eine Pipeline, die bei jeder theoretischen Abweichung blockiert, wird umgangen statt genutzt.

Pull Requests brauchen außerdem fachlich sinnvolle Reviews. Automatisierte Checks beantworten, ob Regeln erfüllt sind. Sie beantworten nicht, ob eine neue Schnittstelle langfristig verständlich bleibt oder eine Änderung fachliche Nebenwirkungen auslöst. Gerade bei Integrationen und Datenmodellen bleibt die Prüfung durch erfahrene Entwickler und Verantwortliche notwendig.

Integrieren und absichern

Nach dem Merge wird das geprüfte Artefakt in eine Integrations- oder Staging-Umgebung ausgerollt. Hier zeigen sich Fehler, die isolierte Tests nicht erfassen: falsche Umgebungsvariablen, fehlende Berechtigungen, nicht kompatible API-Versionen oder Migrationen mit unerwarteter Laufzeit.

Datenbankmigrationen verdienen besondere Aufmerksamkeit. Ein einfaches Rollback des Anwendungscodes genügt nicht, wenn das Datenmodell bereits verändert wurde. Bewährt haben sich vorwärtskompatible Migrationen: Zuerst wird eine neue Struktur ergänzt, dann nutzt die Anwendung sie schrittweise, erst später wird alter Code oder eine alte Spalte entfernt. Dieser Ansatz kostet etwas mehr Planung, verhindert aber Ausfälle bei der Rücknahme eines Releases.

Der produktive Rollout sollte kontrolliert erfolgen. Bei Kubernetes bieten sich Rolling Updates an, bei kritischen Änderungen auch Canary-Releases oder Blue-Green-Deployments. Welche Variante angemessen ist, hängt von Traffic, Kosten und Rückfallrisiko ab. Ein kleines internes System benötigt selten eine aufwendige Canary-Infrastruktur. Eine Plattform mit vielen parallelen Nutzern kann davon deutlich profitieren.

Nach dem Deployment prüfen Health-Checks, ob Container oder Prozesse laufen. Aussagekräftiger sind ergänzende Smoke-Tests: Ist der Login erreichbar, antwortet eine zentrale API, kann ein Kernprozess ausgeführt werden? Erst wenn diese Kriterien erfüllt sind, gilt die Auslieferung als erfolgreich. Bei Fehlverhalten sollte die Pipeline automatisch stoppen und, soweit technisch möglich, auf die vorherige Version zurückrollen.

Betreiben und weiterentwickeln

Eine Pipeline endet nicht mit dem grünen Deployment. Sie braucht Monitoring, Protokollierung und klare Alarmierungswege. Ohne Metriken zu Fehlerquoten, Latenzen, Ressourcenverbrauch und Verfügbarkeit bleibt ein Rollout eine Annahme. Mit diesen Signalen lässt sich feststellen, ob eine neue Version den Betrieb beeinträchtigt, obwohl alle vorherigen Tests bestanden haben.

Ebenso wichtig sind regelmäßige Pflege und nachvollziehbare Zugriffsrechte. Build-Runner, Registry-Zugänge, Deployment-Secrets und Cloud-Rollen müssen geprüft und rotierbar sein. Abhängigkeiten der Pipeline selbst altern. Wer sie nicht aktualisiert, verlagert technische Schulden in genau den Prozess, der sichere Änderungen ermöglichen soll.

Typische Fehlentscheidungen und ihre Folgen

Eine einzige Pipeline für Entwicklung, Test und Produktion ohne getrennte Berechtigungen schafft unnötige Risiken. Ebenso problematisch sind manuelle Hotfixes direkt auf Produktionsservern. Sie erzeugen Zustände, die im Repository nicht abgebildet sind und beim nächsten Deployment verschwinden können.

Auch lange Laufzeiten sind ein betriebliches Problem. Wenn Entwickler 45 Minuten auf eine Rückmeldung warten, werden Änderungen größer und seltener integriert. Besser ist eine schnelle erste Prüfstufe und eine nachgelagerte, umfassendere Testkette. Parallelisierung, Caching und gezielte Testauswahl können helfen, dürfen aber die Reproduzierbarkeit nicht beschädigen.

Schließlich ist ein grüner Pipeline-Status kein Verfügbarkeitsversprechen. Er belegt nur, dass die definierten Regeln erfüllt wurden. Ob diese Regeln ausreichend sind, zeigt sich an Incidents, Fehlerschwerpunkten und der Fähigkeit des Teams, Releases kontrolliert zurückzunehmen. Genau deshalb gehören Entwicklung und Betrieb zusammen.

Eine gute Pipeline macht Veränderungen nicht risikolos. Sie sorgt dafür, dass Risiken früh sichtbar werden, Releases wiederholbar bleiben und bei Problemen eine belastbare Reaktion möglich ist. Der richtige nächste Schritt ist daher nicht das nächste CI-Tool, sondern ein gemeinsamer Blick auf Ihren aktuellen Lieferweg: Wo entsteht heute Unsicherheit, und welche automatisierte Prüfung würde sie konkret reduzieren?