CI/CD verstehen: Continuous Integration erklärt

Du hast Code geschrieben, ihn getestet, vielleicht von Hand auf einen Server kopiert – und dabei einen Schritt vergessen. Genau solche Fehler verhindert CI/CD. Hinter dem Kürzel verbergen sich Praktiken, die das Testen und Ausliefern von Software automatisieren. In diesem Beitrag erkläre ich dir die Grundbegriffe und zeige, wie eine Pipeline aufgebaut ist.

Was bedeutet CI/CD?

Das Kürzel setzt sich aus mehreren Begriffen zusammen:

• CI – Continuous Integration: Jede Code-Änderung wird automatisch gebaut und getestet, sobald sie ins Repository kommt.
• CD – Continuous Delivery: Die getestete Software wird automatisch bereitgestellt, sodass sie jederzeit per Knopfdruck ausgeliefert werden kann.
• CD – Continuous Deployment: Geht noch einen Schritt weiter und veröffentlicht jede erfolgreiche Änderung automatisch in der Produktion.

Das gemeinsame Ziel: weniger Handarbeit, weniger Fehler, schnelleres Feedback.

Warum Continuous Integration?

Stell dir vor, fünf Leute arbeiten an einem Projekt und integrieren ihren Code erst nach Wochen. Das Zusammenführen wird zum Albtraum. Bei Continuous Integration integriert jeder seine Änderungen mehrmals täglich. Nach jedem Push laufen automatisch Tests. Bricht etwas, erfährst du es sofort – nicht erst Wochen später. So bleiben Probleme klein und überschaubar.

Der Ablauf einer Pipeline

Eine CI/CD-Pipeline ist eine Abfolge automatisierter Schritte. Typischerweise sieht sie so aus:

• Checkout: Der aktuelle Code wird geholt.
• Build: Die Anwendung wird gebaut oder kompiliert.
• Test: Automatische Tests laufen durch.
• Deploy: Bei Erfolg wird die Anwendung ausgeliefert.

Jeder Schritt muss erfolgreich sein, bevor der nächste startet. Schlägt ein Test fehl, stoppt die Pipeline und meldet den Fehler.

Ein einfaches Beispiel

Damit du ein Gefühl bekommst, hier eine minimale Pipeline als YAML, wie sie viele CI-Systeme verstehen. Sie installiert Abhängigkeiten, baut und testet:

stages:
  - build
  - test

build-job:
  stage: build
  script:
    - npm install
    - npm run build

test-job:
  stage: test
  script:
    - npm test

Die Befehle unter script sind genau die, die du auch lokal im Terminal eingeben würdest. Die Pipeline führt sie nur automatisch und in einer sauberen Umgebung aus.

Tests als Herzstück

CI funktioniert nur so gut wie deine Tests. Ohne automatische Tests prüft die Pipeline nichts Sinnvolles. Deshalb gehört zu jedem Projekt eine Testsuite, die du lokal genauso ausführen kannst:

# Tests lokal ausführen
npm test

# In Python-Projekten häufig
pytest

# Mit Abdeckungsbericht (Coverage)
pytest --cov=mein_modul

Ein guter Grundsatz: Schreibe Tests so, dass sie schnell laufen. Eine Pipeline, die zehn Minuten braucht, nervt; eine, die in dreißig Sekunden Feedback gibt, motiviert.

Worauf du achten solltest

Ein paar Prinzipien helfen, deine Pipeline gesund zu halten:

• Schnell halten: Lange Pipelines bremsen den Arbeitsfluss.
• Grün als Standard: Ein roter Build sollte sofort behoben werden.
• Geheimnisse schützen: Passwörter und Tokens niemals im Code, sondern als geschützte Variablen ablegen.
• Reproduzierbar bauen: Feste Versionen statt "neueste" verwenden.

Fazit

CI/CD nimmt dir die mühsame, fehleranfällige Handarbeit beim Testen und Ausliefern ab. Continuous Integration sorgt dafür, dass jede Änderung sofort gebaut und getestet wird, sodass du Probleme früh entdeckst. Eine Pipeline ist im Kern nur eine Abfolge von Befehlen, die du auch lokal ausführen könntest – nur eben automatisiert. Im nächsten Beitrag baust du deine erste echte Pipeline mit GitHub Actions und siehst, wie einfach der Einstieg ist.