Was ist CI/CD und warum brauche ich das beim Vibe Coding?

Was heißt CI/CD?

Die Abkürzung steht für zwei Dinge, die zusammengehören:

• Continuous Integration (CI): Jede Änderung wird automatisch zusammengeführt, gebaut und getestet – nicht erst kurz vor dem Release.
• Continuous Delivery oder Deployment (CD): Was alle Prüfungen besteht, liegt zur Freigabe bereit (Delivery) oder wird automatisch ausgeliefert (Deployment).

Ein Bild dafür ist ein Fließband mit Qualitätskontrolle: Kein Teil verlässt die Halle, ohne die Prüfstationen zu durchlaufen. Fällt eine Station durch, hält das Band an – bevor das fehlerhafte Teil beim Kunden ist.

Warum gerade beim Vibe Coding?

Wer mit Cursor, Lovable oder Claude Code baut, ist schnell. Genau das ist das Risiko:

• KI erzeugt mehr Code, als Menschen lesen. Eine Änderung an der Anmeldung kann nebenbei die Rechnungsstellung brechen – und niemand merkt es.
• Es kommt vor, dass Schlüssel direkt im Code landen oder veraltete Bibliotheken mit bekannten Sicherheitslücken eingebaut werden.
• Ohne Prüfstrecke fällt all das erst auf, wenn sich Nutzer beschweren.

Mit Prüfstrecke fällt es beim nächsten Push auf. Das Team bleibt so schnell wie vorher – nur mit Leitplanken.

Die Stationen einer Prüfstrecke

1. Bauen: Lässt sich die App überhaupt bauen?
2. Testen: Laufen die wichtigsten Abläufe noch – Anmeldung, Speichern, Bezahlen?
3. Code prüfen: Linter und Typprüfung finden typische Fehler, bevor sie laufen.
4. Sicherheit prüfen: Ein Secret-Scan sucht nach Passwörtern und Schlüsseln, eine Abhängigkeitsprüfung nach bekannten Lücken in verwendeten Bibliotheken.
5. Ausprobieren: Die Änderung läuft auf einer Testumgebung, bevor echte Nutzer sie sehen.
6. Freigeben: Ein Mensch gibt frei.
7. Ausliefern und kontrollieren: Nach dem Release prüft ein kurzer Smoke-Test, ob alles erreichbar ist.
8. Zurückrollen: Geht doch etwas schief, ist die Vorversion in Minuten wieder da.

Wie sieht das konkret aus?

Bei GitHub heißt das Werkzeug GitHub Actions, bei GitLab GitLab CI. Eine erste, einfache Prüfstrecke für ein Node-Projekt kann so aussehen – als Datei .github/workflows/pruefstrecke.yml:

name: Pruefstrecke
on:
  pull_request:
  push:
    branches: [main]

jobs:
  pruefen:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm audit --audit-level=high

Die Befehle npm run lint und npm test setzen voraus, dass euer Projekt diese Skripte definiert. Ein Secret-Scan, etwa mit gitleaks, kommt als weiterer Schritt dazu. Testumgebung, Freigabe und Auslieferung hängen davon ab, wo eure App läuft – viele Hoster bieten Vorschau-Umgebungen pro Änderung an.

Was CI/CD nicht kann

• Tests finden nur, was sie prüfen. Ohne Tests für die wichtigen Abläufe ist die Prüfstrecke ein Fließband ohne Kontrolleure.
• Sie ersetzt kein Verständnis. Aber sie verhindert, dass Unverstandenes ungeprüft live geht.
• Sie muss gepflegt werden. Sind Läufe dauerhaft rot und alle ignorieren sie, schützt die Strecke nichts mehr.

So fangt ihr klein an

1. Schützt den Hauptzweig: Änderungen nur noch per Pull Request oder Merge Request.
2. Richtet einen Workflow ein, der die App baut und einen Test für den wichtigsten Ablauf ausführt.
3. Ergänzt Secret-Scan und Abhängigkeitsprüfung.
4. Gebt jeder Änderung eine Testumgebung.
5. Legt fest, wer freigibt und wie ihr zurückrollt.

Ein Tipp für KI-Assistenten: Haltet in den Projektregeln fest – etwa in einer CLAUDE.md oder in den Cursor Rules –, dass jede Änderung die Prüfstrecke bestehen muss. Dann weiß auch die KI, woran sie sich halten soll.