Was ist CI/CD?

CI/CD steht für Continuous Integration und Continuous Delivery beziehungsweise Continuous Deployment: Jede Änderung am Code wird automatisch geprüft, gebaut und für die Auslieferung vorbereitet. Das Ergebnis sind kleine, getestete Updates statt seltener, riskanter Großumstellungen.

CI/CD ist das technische Herzstück von DevOps. Für Auftraggeber zählt vor allem eine Folge: Nach einem Update funktioniert die Anwendung weiterhin.

Die drei Begriffe hinter CI/CD

Im Mittelstand ist Continuous Delivery meist der passende Mittelweg: automatisch geprüft, aber mit bewusster Freigabe vor dem Echtbetrieb.

So funktioniert eine CI/CD-Pipeline

Eine Pipeline ist die feste Abfolge von Schritten, die jede Änderung durchläuft. Scheitert ein Schritt, stoppt die Pipeline, und die Änderung kommt nicht weiter.

1. Commit: Eine Entwicklerin speichert ihre Änderung im gemeinsamen Code-Verzeichnis. Das löst die Pipeline aus.
2. Tests: Automatische Tests prüfen einzelne Funktionen und das Zusammenspiel. Zusätzlich laufen Prüfungen auf Code-Stil und bekannte Sicherheitslücken in verwendeten Bibliotheken.
3. Build: Die Anwendung wird zu einem lauffähigen Paket gebaut. Dasselbe Paket wird später auch live eingesetzt – nicht ein neu gebautes.
4. Staging: Das Paket läuft auf einer Testumgebung, die dem Echtbetrieb gleicht. Hier prüfen Menschen, ob die Änderung fachlich das tut, was bestellt war.
5. Produktion: Nach Freigabe geht das Paket live. Die Überwachung beobachtet, ob Fehlerrate und Antwortzeiten normal bleiben. Wenn nicht, wird die vorherige Version wiederhergestellt.

Warum Tests und Freigabe-Gates entscheidend sind

Eine Pipeline ist nur so gut wie ihre Prüfungen. Ohne Tests liefert sie Fehler einfach schneller aus. Deshalb gehören zu jeder sinnvollen CI/CD-Strecke sogenannte Gates, also Schranken, an denen eine Änderung stoppt, wenn eine Bedingung nicht erfüllt ist:

• Alle automatischen Tests sind grün.
• Eine zweite Person hat den Code gelesen und freigegeben.
• Es gibt keine bekannte kritische Sicherheitslücke in den verwendeten Paketen.
• Auf der Testumgebung wurde die Änderung fachlich abgenommen.

Die Gates sind der Grund, warum CI/CD Updates sicherer macht und nicht nur schneller.

Beispiele aus dem Mittelstand

Kundenportal: Ein Dienstleister erweitert sein Portal um eine Upload-Funktion. Die Pipeline stellt fest, dass nach der Änderung der Login auf älteren Browsern hakt. Der Fehler wird behoben, bevor ein Kunde ihn bemerkt.

Schnittstelle zur Buchhaltung: Eine Anpassung am Rechnungsexport wird automatisch mit Beispielrechnungen getestet. Stimmt ein Betrag oder ein Pflichtfeld nicht, stoppt die Pipeline – falsche Rechnungen erreichen die Buchhaltung gar nicht erst. Gerade bei Formaten wie XRechnung ist das wertvoll.

Firmenwebsite: Neue Texte und Seiten gehen über dieselbe Strecke live. Kaputte Links oder fehlende Metadaten werden vor der Veröffentlichung gemeldet.

Was CI/CD Ihrem Unternehmen bringt

• Weniger Störungen nach Updates: Fehler fallen in der Pipeline auf, nicht bei Ihren Kunden.
• Schnellere Umsetzung von Wünschen: Kleine Änderungen müssen nicht auf das nächste große Release warten.
• Nachvollziehbarkeit: Jede Änderung ist dokumentiert – wer, was, wann. Das hilft bei Fehlersuche und Prüfungen.
• Weniger Abhängigkeit von Einzelpersonen: Die Auslieferung steckt in der Pipeline, nicht im Kopf eines Admins.

Die Grenze: Eine Pipeline aufzubauen und Tests zu schreiben, kostet am Anfang Aufwand. Bei einer Anwendung, die sich kaum ändert, lohnt sich das weniger als bei einem System, das laufend weiterentwickelt wird.

Typische Fehler bei der Einführung

• Pipeline ohne Tests: Die Auslieferung ist automatisiert, geprüft wird aber nichts. Fehler kommen dann schneller live als vorher.
• Testumgebung weicht ab: Wenn Staging mit anderen Versionen oder Daten läuft als der Echtbetrieb, bestehen Änderungen dort Prüfungen, die live scheitern.
• Kein Weg zurück: Jede Auslieferung braucht einen geübten Rückweg auf die vorherige Version. Wer ihn erst im Notfall sucht, verliert Stunden.
• Rote Tests werden übergangen: Wer eine gescheiterte Prüfung „nur dieses eine Mal“ ignoriert, hat bald eine Pipeline, der niemand mehr traut.

Ohne Pipeline sieht ein Update oft so aus: Dateien werden von Hand auf den Server kopiert, am besten abends, und am nächsten Morgen zeigt sich, ob alles läuft. Genau dieses Glücksspiel ersetzt CI/CD durch eine feste, wiederholbare Strecke.

In der Praxis: Updates ohne böse Überraschungen

Bei Anwendungen, die SEODACH entwickelt, planen wir automatische Prüfungen, Testumgebung und Freigabe von Anfang an mit ein. Das Ziel für unsere Kunden: Neue Funktionen kommen in kleinen Schritten, und nach einem Update läuft das System so wie vorher – nur mit dem, was neu bestellt war. Wie wir Anwendungen danach im Alltag betreuen, lesen Sie unter Betrieb und Wartung. Soll eine neue Software entstehen, beginnt der Weg bei der Individualsoftware.

Häufige Fragen

Was ist der Unterschied zwischen Continuous Delivery und Continuous Deployment?

Bei Continuous Delivery ist jede Änderung auslieferungsbereit, live geht sie aber erst nach einer menschlichen Freigabe. Bei Continuous Deployment geht jede geprüfte Änderung automatisch live.

Braucht auch eine kleine Anwendung CI/CD?

Eine einfache Pipeline mit Tests und Testumgebung lohnt sich fast immer, sobald eine Anwendung geschäftskritisch ist oder regelmäßig geändert wird. Für eine Website, die sich jahrelang nicht ändert, ist der Aufwand meist nicht nötig.

Macht CI/CD Tests durch Menschen überflüssig?

Nein. Automatische Tests prüfen, ob etwas technisch funktioniert. Ob eine Funktion fachlich richtig ist, prüft weiterhin ein Mensch auf der Testumgebung.