Was ist CI/CD? Continuous Integration und Delivery erklärt

Was ist CI CD?

CI/CD ist eine Arbeitsweise in der Softwareentwicklung: Jede Codeänderung wird automatisch gebaut und getestet (Continuous Integration), und die geprüfte Version wird automatisch zur Veröffentlichung vorbereitet oder gleich ausgeliefert (Continuous Delivery oder Continuous Deployment). So wird aus einem riskanten Releasetag eine kleine, wiederholbare Routine.

Ein einfacher Vergleich hilft: Stellen Sie sich ein Fließband mit Qualitätskontrolle vor. Rohteile (Codeänderungen) laufen auf das Band, und jede Station (Build, Test, Sicherheitsscan) misst das Teil und sortiert fehlerhafte aus. Die guten Teile verpackt das Team und macht sie versandfertig. Niemand greift von Hand ein, denn die Regeln gelten für alle gleich.

Die Frage „Was ist CI CD“ klingt nach einem Werkzeug, beschreibt aber eine Methode. Anders gesagt beantwortet sie zwei getrennte Fragen in einem automatischen Ablauf. Der erste Teil, CI, fragt, ob der Code in Ordnung ist. Der zweite Teil, CD, fragt, wie dieser gute Code zu den Nutzern kommt. Deshalb gilt die Idee unabhängig vom Werkzeug, das Sie später wählen.

Was ist CI CD in der Praxis? So funktioniert Continuous Integration

Continuous Integration (CI) heißt: Alle im Team führen ihre Änderungen häufig im gemeinsamen Code zusammen, und jede Zusammenführung löst automatisch einen Build und einen Testlauf aus. Martin Fowlers klassischer Artikel zu Continuous Integration betont genau das: Integrationsprobleme sollen Sie sofort entdecken, nicht erst nach Wochen.

In der Praxis ist die Logik einfach. Zunächst schickt ein Entwickler seine Änderung an die Versionsverwaltung. Dann holt ein Server sie in einer sauberen Umgebung ab, baut sie und führt die Tests aus. Danach sehen Sie nach wenigen Minuten grün oder rot. Bei Rot ist die Korrektur günstig, weil der Fehler noch frisch ist.

Die saubere Umgebung ist dabei besonders wichtig. Auf dem Rechner eines Entwicklers sammeln sich über Jahre Einstellungen, installierte Werkzeuge und vergessene Dateien an. Die Pipeline startet dagegen jedes Mal bei null, also ohne Altlasten. Somit weicht der Satz „bei mir läuft es“ einem objektiven Ergebnis: Scheitert es in der sauberen Umgebung, dann scheitert es eben.

Falls Ihnen die Versionsverwaltung noch fremd ist, lesen Sie zuerst unsere Anleitung zu Git und GitHub mit den wichtigsten Befehlen. Denn CI setzt direkt auf diesem Ablauf auf.

Vor allem schnelles Feedback ist der wertvollste Ertrag von CI. Ein Test, der in fünf Minuten antwortet, bekommt sofort eine Korrektur. Dauert er Stunden, wechselt der Entwickler dagegen die Aufgabe und vergisst den Fehler. Daher ordnen Teams ihre Tests nach Geschwindigkeit.

Die Grundgewohnheiten von CI sehen so aus:

• Sie halten Änderungen klein und führen sie täglich im gemeinsamen Zweig zusammen.
• Außerdem machen Sie Build und Tests mit einem einzigen Befehl ausführbar.
• Weil ein kaputter Build alle blockiert, beheben Sie ihn sofort und mit Priorität.
• Danach stellen Sie schnelle Tests nach vorn und langsame ans Ende.

Wie beeinflusst die Verzweigungsstrategie die Continuous Integration?

Der Kern von CI ist also häufiges Zusammenführen. Deshalb sind langlebige Zweige der größte Feind. Lebt ein Zweig wochenlang getrennt vom Hauptcode, endet der Zusammenführungstag in einem großen Konflikt. Aus diesem Grund rät auch Fowlers Artikel zu kleinen, häufigen Zusammenführungen in die Hauptlinie.

In der Praxis sehen Sie zwei verbreitete Modelle. Im ersten öffnet ein Entwickler einen kurzlebigen Zweig, macht eine kleine Änderung und bringt sie per Merge Request zurück. Im zweiten schickt das Team winzige Schritte direkt in den Hauptzweig.

Beide Modelle teilen eine Regel: Der Hauptzweig bleibt grün. Dafür schützen Sie ihn, und zudem verlangen Sie vor jeder Zusammenführung eine erfolgreiche Pipeline.

Was tun Sie bei einer halbfertigen Funktion? Sie halten den Code stattdessen hinter einem Schalter verborgen. Das ist deutlich sicherer, weil kein Zweig wochenlang offen bleibt. Mehr dazu lesen Sie weiter unten.

Was ist der Unterschied zwischen Continuous Delivery und Continuous Deployment?

Die Buchstaben CD stehen für zwei verschiedene Ideen, und genau hier beginnt das meiste Durcheinander. Bei Continuous Delivery ist jede Version, die die Tests besteht, jederzeit veröffentlichungsbereit. Allerdings trifft ein Mensch die letzte Entscheidung für den Livegang.

Continuous Deployment dagegen geht einen Schritt weiter. Eine Änderung, die alle automatischen Prüfungen besteht, geht ohne Freigabe in Produktion. Somit sitzt kein Mensch mehr dazwischen.

Der Unterschied in der Praxis: Bei Delivery entscheiden Sie selbst, wann Sie eine fertige Version freigeben. Bei Deployment überlassen Sie diese Entscheidung dagegen der Qualität Ihrer Tests und Prüfungen. Folglich brauchen Sie dafür starke Testabdeckung und einen schnellen Rückweg.

Zum Beispiel kann eine kleine Textkorrektur auf einer Nachrichtenseite nach bestandenen Prüfungen binnen Minuten live gehen, was zu Deployment passt. Eine Änderung am Bezahlablauf will das Team dagegen vielleicht noch einmal von Hand prüfen, das ist das Delivery Modell. Beide Modelle können also im selben Team auf verschiedenen Pipelines nebeneinander laufen.

Martin Fowlers Beschreibung von Continuous Delivery stützt diese Trennung. Entscheidend ist also, dass sich Software jederzeit sicher veröffentlichen lässt. Wie oft Sie tatsächlich veröffentlichen, ist eine geschäftliche Entscheidung.

Aus welchen Phasen besteht eine typische CI CD Pipeline?

Eine Pipeline ist die geordnete Liste automatischer Phasen, die eine Änderung vom Code bis zur Produktion durchläuft. Jede Phase hängt vom Erfolg der vorherigen ab, daher bricht eine Kette bei einem Fehler früh ab. Bricht eine ab, stoppt die Pipeline, und spätere Phasen laufen nicht.

In den meisten Projekten sehen Sie diese Phasen:

1. Quelle: Ein Entwickler schickt eine Änderung oder öffnet einen Merge Request, und das startet die Pipeline.
2. Build: Die Pipeline übersetzt den Code, lädt Abhängigkeiten und erzeugt ein lauffähiges Ergebnis.
3. Test: Unit Tests, Integrationstests und je nach Bedarf Tests über den ganzen Ablauf laufen durch.
4. Prüfung von Sicherheit und Qualität: Werkzeuge prüfen Schwachstellen in Abhängigkeiten, Codequalität und versehentlich eingecheckte Geheimnisse.
5. Paketieren: Das Ergebnis wird zu einem transportablen Paket oder Container Image mit einer Versionsnummer.
6. Auslieferung: Das Paket geht zuerst in die Testumgebung, nach Freigabe in die Produktion.
7. Prüfen und überwachen: Nach dem Livegang starten Gesundheitsprüfungen und Monitoring.

Diese Reihenfolge ist allerdings kein festes Gesetz. Eine kleine Website hat zum Beispiel nur Build, Test und Auslieferung. Ein großes Produkt zerlegt dagegen jede Phase in eigene Unterschritte.

Die ganze Pipeline liegt als Konfiguration beim Quellcode, also prüfen Sie sie wie Code. Ein weiteres Prinzip lautet „früh scheitern“: Die billigsten Prüfungen laufen zuerst, die teuren zuletzt. Ist etwas falsch, stoppt die Pipeline dann, ohne Zeit zu verschwenden.

Wie läuft eine einzelne Änderung durch die Pipeline? Ein Beispielszenario

Machen wir es konkret. In einem E-Commerce Team korrigiert eine Entwicklerin die Rabattberechnung auf der Warenkorbseite. Sie arbeitet in einem eigenen Zweig und öffnet dann einen Merge Request. Dann startet die Pipeline.

Zuerst baut die Pipeline den Code. Danach laufen die Unit Tests, und ein Test findet eine unerwartete Rundungsabweichung bei der Prozentrechnung. Folglich wird die Pipeline rot und blockiert die Zusammenführung. Die Entwicklerin behebt den Fehler noch am selben Tag, und die Pipeline wird grün.

Nach der Zusammenführung erzeugt die Pipeline das Paket und legt es in der Testumgebung ab. Danach prüfen dort automatische Tests den Warenkorbablauf. Bestehen sie, wartet die Version im Delivery Modell auf Freigabe oder geht im Deployment Modell von allein live. Das ist ein Beispielszenario, kein echter Kundenfall.

Beachten Sie den Kern: Das Team hat den Fehler entdeckt, bevor ein Kunde ihn sah, und zum günstigsten Zeitpunkt. Ohne Pipeline würde der Fehler wohl erst Tage später in der Produktion auffallen, weil niemand die Änderung prüft. Kunden würden sich beschweren, und das Team müsste dann suchen, welche Änderung schuld ist. CI durchtrennt diese Kette ganz am Anfang.

Welche Tests sollte eine Pipeline in welcher Reihenfolge ausführen?

Die Testpyramide ist ein Denkmodell: viele schnelle Tests unten, wenige langsame Tests oben. Eine Pipeline folgt daher derselben Logik. Zunächst laufen die schnellsten und billigsten Prüfungen. Tritt dort ein Fehler auf, müssen Sie die teuren Tests gar nicht erst starten.

• Statische Prüfungen: Format, Typen und einfache Qualitätsregeln sind in Sekunden fertig und kommen an den Anfang.
• Unit Tests: Sie prüfen eine einzelne Funktion oder Klasse ohne äußere Abhängigkeiten.
• Integrationstests: Sie prüfen, ob mehrere Teile mit echten Komponenten wie einer Datenbank zusammenarbeiten.
• Tests über den ganzen Ablauf: Sie spielen einen Nutzerweg von Anfang bis Ende durch, sind aber langsamer und anfälliger.

Zum Beispiel können Sie in einem Bestellformular die Summenberechnung mit Unit Tests hundertfach billig prüfen. Den vollständigen Ablauf im Browser prüfen Sie dagegen nur mit wenigen kritischen Szenarien, denn solche Tests kosten mehr Zeit. So bleibt die Pipeline schnell und schützt trotzdem die wichtigsten Wege.

Langsame Tests parallel laufen zu lassen, verkürzt außerdem die Gesamtzeit. Dafür müssen die Tests allerdings voneinander unabhängig sein. Wer tiefer in den Beruf einsteigen möchte, findet in unserem Beitrag Was macht ein Testautomatisierer mehr Hintergrund.

Wie passen Umgebungen (Entwicklung, Test, Produktion) in eine Pipeline?

Eine Umgebung ist ein eigener Aufbau, in dem die Software läuft. Eine Pipeline nutzt meist mindestens drei: Entwicklung, Test (oder Staging) und Produktion. Folglich beantwortet jede eine andere Frage.

• Entwicklungsumgebung: Der Rechner des Entwicklers oder ein gemeinsamer Spielplatz. Tempo zählt hier, und die Daten sind nicht echt.
• Testumgebung: Eine Kopie, die der Produktion möglichst ähnlich sieht. Hier laufen automatische und manuelle Prüfungen.
• Produktionsumgebung: Das System, das echte Nutzer verwenden. Dorthin gelangen nur Pakete, die die Pipeline geprüft hat.

Die goldene Regel lautet: Dasselbe Paket wandert unverändert durch die Umgebungen. Bauen Sie in der Produktion neu, was Sie im Staging getestet haben, liefern Sie also womöglich etwas anderes aus. Umgebungsspezifische Einstellungen halten Sie deshalb außerhalb des Pakets in einer Konfiguration, die Sie von außen übergeben.

Wie ähnlich die Testumgebung der Produktion ist, bestimmt auch die Qualität der gefundenen Fehler. Weichen Datenbankversion, Betriebssystem oder Netzwerkeinstellungen ab, bestehen Tests, und in der Produktion knallt es trotzdem. Konkret sind Container ein verbreiteter Weg, diese Lücke zu verkleinern.

Geheimnisse und Passwörter gehören außerdem nie in den Code. Stattdessen bietet das CI CD Werkzeug einen geschützten Speicher für Variablen.

Was ist CI CD, und worin unterscheidet es sich vom manuellen Release?

Den Unterschied sehen Sie am besten, wenn Sie die drei Ansätze nebeneinanderstellen. Die Tabelle zeigt außerdem, wo ein Team gerade steht.

Die Schlussfolgerung ist klar: CI ist die Voraussetzung für CD. Wer ungetesteten Code an eine automatische Veröffentlichung koppelt, beschleunigt somit nur die Fehler.

Lesen Sie die Tabelle wie eine Leiter. Jede Sprosse baut auf der unteren auf, daher müssen Sie nicht alle auf einmal nehmen. Viele Teams bleiben lange auf der Stufe CI, und das ist trotzdem völlig gesund. Wenn jemand fragt, was ist CI CD für das eigene Team, beginnt die ehrliche Antwort also bei der aktuellen Lage.

Was bringt CI CD einem Team?

Der Gewinn besteht nicht aus einer Sache, sondern aus mehreren Effekten, die sich gegenseitig stärken. Wir halten sie konkret und nennen keine Zahlen, denn der Nutzen schwankt von Team zu Team.

Erstens wird das Feedback schneller. Der Entwickler sieht den Fehler, weil er den Code noch im Kopf hat. Zweitens sinkt die Angst vor dem Release. Kleine, häufige Veröffentlichungen bergen viel weniger Risiko als große, seltene. Geht etwas schief, schauen Sie auf eine einzelne Änderung, statt einen Schuldigen zu suchen.

Drittens entsteht also Wiederholbarkeit. Weil die Releaseschritte als Pipelinebeschreibung festgehalten sind, schrumpft das Problem „bei mir ging es“. Eine neue Kollegin kann außerdem schon am ersten Tag sicher ein Release auslösen.

Viertens verteilt sich das Wissen. Der Releaseprozess steckt also nicht im Kopf einer Person. Geht jemand in den Urlaub oder verlässt die Firma, stehen die Veröffentlichungen nicht still.

Außerdem merken auch Kunden den Unterschied. Fehlerkorrekturen kommen in Stunden statt Tagen in die Produktion, daher stoßen Nutzer seltener auf Probleme. Für Marketingteams ist das ebenfalls wertvoll: Eine Korrektur auf einer Kampagnenseite kann live gehen, ohne den geplanten Releasetermin abzuwarten.

Woran messen Sie den Erfolg von CI CD?

Die Pipeline aufzubauen ist allerdings nur der Anfang. Um Verbesserungen zu sehen, müssen Sie daher messen. Das Forschungsprogramm DORA schlägt vor, die Lieferleistung mit Kennzahlen zu verfolgen, etwa wie oft Sie ausliefern, wie lange eine Änderung bis zur Produktion braucht, wie viele Änderungen Probleme verursachen und wie schnell sich der Dienst erholt. Die aktuellen Definitionen lesen Sie auf der offiziellen Seite von DORA.

Nutzen Sie diese Kennzahlen, um das System zu verbessern, nicht um Personen zu vergleichen. Drückt man jemanden, eine Zahl zu erhöhen, findet das Team Wege, sie zu schönen.

Auch einfachere Anzeiger helfen Ihrem eigenen Team:

• Die durchschnittliche Dauer der Pipeline und ihre Entwicklung über die Zeit.
• Der Anteil der Merge Requests, bei denen die Pipeline rot wird.
• Die Zahl instabiler Tests, die am selben Code mal bestehen und mal scheitern.
• Die Zeit vom Entdecken eines Fehlers bis zur Behebung.

Zielzahlen nennen wir hier nicht, denn ein guter Wert unterscheidet sich von Team zu Team. Wichtig ist also, ob Ihre eigene Kurve nach oben oder unten zeigt.

Wie funktionieren Rollback und schrittweise Veröffentlichung in CI CD?

Eine automatische Veröffentlichung ohne automatischen Rückweg ist nur die halbe Arbeit. Rollback heißt, bei einem Problem in der Produktion schnell zur letzten guten Version zurückzukehren. Weil Sie Pakete mit Versionsnummern aufbewahren, genügt oft das erneute Einspielen des älteren Pakets.

Die schrittweise Veröffentlichung verteilt außerdem das Risiko. Sie öffnen die neue Version zunächst für einen kleinen Teil der Nutzer. Bleibt das Monitoring ruhig, erweitern Sie dann den Anteil. Dadurch trifft auch eine fehlerhafte Version nur eine kleine Gruppe statt aller.

Hier kommen Feature Flags ins Spiel. Sie liefern den Code aus, halten die Funktion aber per Schalter aus, sodass die Entscheidung über das Einschalten vom Release getrennt ist. Unser Beitrag Was ist ein Feature Flag erklärt diesen Ansatz ausführlich, deshalb wiederholen wir ihn hier nicht.

Dennoch hat die schrittweise Veröffentlichung ohne Monitoring in Echtzeit wenig Sinn. Beobachten Sie Signale wie Fehlerquote, Antwortzeit und Rückmeldungen der Nutzer. Legen Sie vorher fest, wer bei welchem Schwellenwert über einen Rollback entscheidet, denn Diskussionen im Störfall kosten Zeit.

Datenbankänderungen verlangen allerdings besondere Sorgfalt. Zerlegen Sie eine Schemaänderung nicht in rückwärtskompatible Schritte, können Sie den Code zurückrollen, die Daten aber nicht.

Gilt CI CD nur für Websites?

Nein, die Logik funktioniert für jede Art von Software. Eine mobile App, ein Desktopprogramm, eine Bibliothek, eine Infrastrukturbeschreibung und sogar eine Dokumentationsseite können denselben Ablauf nutzen: Eine Änderung kommt an, wird automatisch geprüft, verpackt und ausgeliefert.

Nur der letzte Schritt unterscheidet sich, somit bleibt die Logik gleich. Bei einer Website heißt Deployment, die neue Version auf einem Server abzulegen. Bei einer mobilen App hängt der letzte Schritt oft an der Prüfung durch den App Store, daher bleiben Teams meist bei Continuous Delivery.

Zudem profitiert auch eine Unternehmenswebsite. Zum Beispiel beseitigt eine Pipeline, die die Seite bei jeder Inhaltsänderung neu baut und veröffentlicht, Fehler beim manuellen Kopieren von Dateien. Selbst wenn die Person wechselt, die veröffentlicht, bleibt der Prozess derselbe.

Wie bauen Sie Sicherheitsprüfungen in die Pipeline ein?

Sicherheit sollte daher eine Gewohnheit in jeder Phase sein, nicht eine einzelne Kontrolle am Ende. Man spricht oft vom „Linksverschieben“: Je früher Sie ein Problem finden, desto billiger ist die Behebung.

Typische Prüfungen sind:

• Prüfung der Abhängigkeiten: Sie klärt, ob die genutzten Bibliotheken bekannte Schwachstellen haben.
• Suche nach Geheimnissen: Sie fängt ein Passwort oder einen Zugriffsschlüssel ab, der versehentlich im Code gelandet ist.
• Statische Codeanalyse: Sie sucht riskante Muster, ohne den Code auszuführen.
• Prüfung von Container Images: Sie findet veraltete oder anfällige Pakete im Image.

Unser OWASP Top 10 Leitfaden hilft Ihnen bei der Auswahl, auf welche Risiken Sie achten. Für die Containerseite lesen Sie Was ist Docker.

Die Pipeline selbst ist ebenfalls ein Angriffsziel, denn dort laufen Freigaberechte und Geheimnisse zusammen. Vergeben Sie deshalb Zugriffe nach dem Prinzip der minimalen Rechte, wählen Sie Erweiterungen von Drittanbietern sorgfältig aus und prüfen Sie auch Änderungen an der Pipelinebeschreibung.

Eine Warnung: Scanner sind allerdings nicht perfekt. Statt jeden Fund als Sperre zu behandeln, setzen Sie Prioritäten und lassen nur kritische Funde die Pipeline stoppen.

Welche Arten von CI CD Werkzeugen gibt es?

Zunächst können Sie Werkzeuge in zwei Hauptgruppen teilen. Die erste sind gehostete Dienste: Ein Anbieter betreibt die Infrastruktur, und Sie schreiben nur die Pipelinebeschreibung. Die zweite sind Werkzeuge auf eigenen Servern, bei denen Installation, Updates und Sicherung bei Ihnen liegen.

Manche Projekte wählen deshalb eine Mischung. Der größte Teil der Pipeline läuft dann im gehosteten Dienst, während sensible Auslieferungsschritte auf einem Runner auf Ihrem eigenen Server laufen.

Stellen Sie bei der Auswahl drei Fragen. Wo liegt Ihr Code schon? Verlangen Datenschutz oder Compliance, dass der Code im Haus bleibt? Wer pflegt die Pipeline? Die Antworten wiegen also oft schwerer als der Name des Werkzeugs.

Als Beispiele aus offiziellen Dokumentationen nennen wir GitHub Actions und GitLab CI/CD, bekannte Vertreter der beiden Welten. Außerdem lassen beide Sie die Pipeline in einer Konfigurationsdatei im Repository beschreiben. Das ist keine Empfehlung, sondern ein Hinweis auf gut lesbare Dokumentation. Die richtige Wahl hängt von Ihrem Technologiestack ab.

Wie arbeiten Werkzeuge wie GitHub Actions und GitLab CI im Prinzip?

Die Werkzeuge nennen Dinge unterschiedlich, teilen aber ein Modell. Zunächst löst ein Ereignis, etwa ein Push oder ein Merge Request, die Pipeline aus. Dann läuft der ausgelöste Job auf einem Runner in einer sauberen Umgebung. Ein Runner ist die vorübergehende Maschine, die die Arbeit erledigt.

Die Pipelinebeschreibung liegt als Konfigurationsdatei im Repository. Darin legen Sie zum Beispiel Jobs, Reihenfolge, Bedingungen und Umgebungsvariablen fest. Weil die Beschreibung zusammen mit dem Code in die Versionsverwaltung geht, kann das Team die Pipeline selbst prüfen und zurücksetzen.

Ergebnisse von Jobs, etwa ein Buildpaket oder ein Testbericht, speichert das Werkzeug als Artefakte und gibt sie an spätere Phasen weiter. Ebenso funktioniert ein Cache, damit Sie Abhängigkeiten nicht jedes Mal neu laden.

Manche Werkzeuge unterstützen zudem Matrixläufe. Das heißt, derselbe Test läuft parallel mit mehreren Kombinationen aus Betriebssystemen oder Sprachversionen. Autoren von Bibliotheken schätzen das sehr, Teams mit nur einem Produkt brauchen es meist nicht.

Für Einzelheiten nutzen Sie die offiziellen Quellen: die Dokumentation von GitHub Actions und die Dokumentation von GitLab CI/CD. Menünamen und Syntax ändern sich mit der Zeit, prüfen Sie deshalb dort den aktuellen Stand.

Wo sollte ein kleines Team mit CI CD anfangen?

Versuchen Sie also nicht, alles auf einmal zu bauen. Denn kleine Schritte fördern Lernen und Vertrauen. Die folgende Reihenfolge funktioniert gut für kleine Teams.

1. Halten Sie Ihren Code in einer Versionsverwaltung und einigen Sie sich auf einen gemeinsamen Hauptzweig.
2. Stellen Sie sicher, dass Sie Build und Test mit einem Befehl ausführen können.
3. Richten Sie eine erste Pipeline nur für Build und Test ein, die bei jedem Merge Request läuft.
4. Blockieren Sie die Zusammenführung, solange die Pipeline rot ist.
5. Bauen Sie das Paket an einer einzigen Stelle und geben Sie ihm eine Versionsnummer.
6. Ergänzen Sie die automatische Auslieferung in eine Testumgebung.
7. Binden Sie die Produktion zuerst mit Freigabe an (Delivery) und denken Sie an Automatisierung, sobald das Vertrauen wächst.
8. Schreiben Sie den Rollbackschritt auf und proben Sie ihn einmal.

Haben Sie noch gar keine Tests, schreiben Sie zuerst einige für kritische Abläufe wie Anmeldung, Bezahlvorgang und Formularversand.

In den ersten Wochen ist das Ziel eine funktionierende Pipeline, nicht eine perfekte. Außerdem lohnt es sich, Pipelinemeldungen an einen Ort zu schicken, den alle sehen, etwa den Teamchat. Dann fällt eine rote Pipeline schnell auf, und niemand muss fragen, ob sie kaputt ist.

Was gehört in eine CI CD Checkliste für den Einstieg?

Um die Frage „Was ist CI CD“ in die Praxis zu übersetzen, prüfen Sie sich vor und nach dem Bau der Pipeline mit dieser Liste. Jeder Punkt hat eine Ja oder Nein Antwort.

• Laufen Build und Tests bei jedem Merge Request automatisch?
• Ist die Pipeline kurz genug, dass Entwickler nicht aufhören zu warten?
• Sind Ihre Tests stabil, oder scheitern sie ab und zu ohne Grund?
• Liegen Geheimnisse außerhalb des Codes im geschützten Speicher des Werkzeugs?
• Führen Sie in Test und Produktion dasselbe Paket aus?
• Wer darf ein Release in die Produktion auslösen, und ist diese Berechtigung dokumentiert?
• Ist Ihr Rollbackweg aufgeschrieben, und haben Sie ihn je ausprobiert?
• Gibt es nach dem Release Monitoring und Warnungen?
• Liegt die Pipelinebeschreibung in der Versionsverwaltung und ist sie offen für Prüfung?

Jeder Punkt, den Sie mit Nein beantworten, ist Ihre nächste Verbesserungsaufgabe. Sie müssen dennoch nicht alle in derselben Woche lösen.

Welche Fehler passieren bei CI CD am häufigsten?

Zu wissen, was ist CI CD, zählt viel, und zu wissen, was schiefgehen kann, ebenso. Fehler entstehen meist aus Gewohnheit, nicht durch das Werkzeug, also lassen sie sich vermeiden.

Der erste Fehler ist Automatisierung ohne Tests. Ist die Pipeline grün, prüft aber nichts, haben Sie nur trügerische Sicherheit. Der zweite Fehler sind dagegen instabile Tests. Ein Test, der am selben Code mal besteht und mal scheitert, gewöhnt das Team daran, Rot zu ignorieren.

Der dritte Fehler ist eine zu langsame Pipeline. Dauert sie eine halbe Stunde, wechseln Entwickler die Aufgabe und verlieren den Zusammenhang. Stellen Sie schnelle Tests nach vorn und lassen Sie schwere Tests parallel laufen.

Der vierte Fehler sind manuelle Einstellungen nur in der Produktion. Eine von Hand geänderte Einstellung auf dem Server verschwindet nämlich bei der nächsten Auslieferung still. Beschreiben Sie deshalb alles als Konfiguration.

Der fünfte Fehler ist, dass Geheimnisse in Code oder Protokolle gelangen. Bedenken Sie, dass die Ausgabe der Pipeline für viele sichtbar sein kann. Ein Befehl, der ein Passwort ausgibt, schafft daher ein ernstes Risiko.

Der sechste Fehler ist, die Pipeline an eine einzige Person zu binden. Versteht nur eine Person sie, steht der Prozess sonst still, wenn diese fehlt. Verteilen Sie das Wissen im Team und stützen Sie die Beschreibung mit einem kurzen Dokument.

Wann ist CI CD überflüssig oder riskant?

Dennoch nützt CI CD nicht jedem Projekt gleich viel. Ehrlich gesagt lohnt sich eine vollständige Pipeline für eine einmalige kleine Seite womöglich nicht. Eine Schaufensterseite, die sich nur wenige Male im Jahr ändert und keine Tests hat, dürfen Sie durchaus von Hand veröffentlichen.

Das Risiko selbst entsteht dagegen durch schlecht aufgebaute Automatisierung. Eine Pipeline ohne Sicherheitsprüfungen trägt auch eine fehlerhafte oder böswillige Änderung schnell in die Produktion. Beschränken Sie daher Freigaberechte, Freigaben für Zusammenführungen und den Zugriff auf Geheimnisse mit Sorgfalt.

In regulierten Bereichen, etwa bei Systemen mit personenbezogenen Daten, brauchen Sie womöglich Änderungsprotokolle und Freigabespuren. Dann geben Sie die Automatisierung nicht auf, sondern bauen Freigabeschritte ein, die eine Spur hinterlassen. Für rechtliche Anforderungen holen Sie daher rechtlichen Rat ein. Dieser Beitrag ist keine Rechtsberatung.

Wie grenzen Sie CI CD von Microservices, Docker und JWT ab?

In der Softwarewelt überschneiden sich Begriffe, daher ist Verwirrung normal. Die folgende Tabelle zeigt zusammengefasst, wie sich CI CD von seinen Nachbarn unterscheidet. Jeder Nachbar hat einen eigenen Beitrag, deshalb geben wir hier nur kurzen Kontext.

In unserem Beitrag zu Microservices Architektur im Vergleich zum Monolith erklären wir, warum zerlegte Anwendungen mehr Automatisierung brauchen. Der Beitrag Was ist ein JWT behandelt die Authentifizierung. Die einzige direkte Verbindung zu CI CD ist das sichere Aufbewahren der Schlüssel in der Pipeline.

Wie richten Sie eine CI CD Pipeline für Ihr eigenes Projekt ein?

Eine Pipeline aufzubauen heißt weniger, ein Werkzeug zu wählen, als den Prozess zu beschreiben. Schreiben Sie zunächst auf, wie Ihr Team heute veröffentlicht. Wer macht es, mit welchen Schritten, wie oft? Danach automatisieren Sie die drei schmerzhaftesten Schritte.

Ist Ihre Codebasis groß, verschieben Sie nicht alles auf einmal. Binden Sie zunächst einen Dienst oder ein Modul an die Pipeline an und übertragen Sie das Gelernte auf die übrigen. Ein kurzer Pilot birgt weniger Risiko als ein großer Umzug.

Auch die Wahl des Piloten hilft. Beginnen Sie mit einem Bestandteil, der sich oft ändert, aber nicht kritisch ist. Dort machen Sie Ihre Fehler, lernen daraus und gehen vorbereitet an die kritischen Teile. Das ist zugleich die praktische Antwort auf die Frage, was ist CI CD für Ihr Team: ein Prozess, der klein anfängt, lernt und wächst.

Als Talha Aslan und Team behandeln wir den Releaseprozess bei individueller Software als Teil des Entwurfs. Planen Sie eine Auslieferungspipeline für Ihr eigenes Produkt, können wir Ihren Bedarf gemeinsam im Rahmen unserer individuellen Softwareentwicklung einschätzen. Vor dem Start einer Website hilft Ihnen außerdem unsere Checkliste zum Testen vor dem Livegang.

Was ist CI CD in einer Zusammenfassung? Das Wichtigste im Überblick

Kurz gesagt ist CI/CD eine Disziplin, die Codeänderungen automatisch baut, testet und sicher für die Veröffentlichung vorbereitet. CI fängt Probleme früh ab. Delivery hält jede Version bereit. Deployment automatisiert zudem den letzten Schritt.

Der Erfolg ruht auf drei Beinen: verlässliche Tests, eine schnelle Pipeline und ein erprobter Rückweg. Fehlt eines davon, bringt Automatisierung Risiko statt Ruhe.

Zum Schluss die Frage in einem Satz: CI/CD ist der automatische Weg, Software oft, in kleinen Stücken und mit Vertrauen auszuliefern. Fangen Sie klein an, messen Sie und wachsen Sie danach. Die Wahl des Werkzeugs zählt weniger als die Qualität der Pipeline. Die beste Pipeline ist die, die Ihr Team sicher und ohne Langeweile nutzt.