CI/CD für AI-gestützte Softwareentwicklung

Wenn ein Team plötzlich dreimal so viele Änderungen produziert, ist die erste spürbare Folge nicht schnellere Auslieferung, sondern eine überlastete Pipeline: längere Wartezeiten, mehr rote Builds, mehr Umgehungen. CI/CD entscheidet damit darüber, ob KI-Geschwindigkeit in Produktion ankommt oder im Merge-Stau endet.

1. Was sich durch KI ändert

Drei Effekte treten regelmäßig gemeinsam auf:

• Mehr Änderungen pro Zeit – die Pipeline wird häufiger ausgeführt.
• Größere Änderungssätze, wenn nicht bewusst gegengesteuert wird.
• Andere Fehlerverteilung – mehr Berechtigungs- und Randfallfehler, mehr neue Abhängigkeiten.

Die Antwort darauf ist nicht „mehr Prüfungen“, sondern die richtigen Prüfungen an der richtigen Stelle – schnell genug, dass niemand sie umgeht.

2. Reproduzierbare Builds

Die Grundlage für alles Weitere. Aus demselben Eingangsstand muss dasselbe Artefakt entstehen – sonst ist weder eine Prüfung noch ein Nachweis belastbar.

• Build aus einer versionierten Definition, nicht aus dem Zustand einer Maschine.
• Abhängigkeiten festgeschrieben – Lockfiles im Repository, keine gleitenden Versionsbereiche.
• Basis-Images mit festem Digest statt beweglicher Tags.
• Werkzeugversionen fixiert, inklusive Compiler und Build-Werkzeug.
• Keine Netzwerkabrufe zur Build-Zeit, die nicht nachvollziehbar sind.

3. Gates und ihre Reihenfolge

Die Reihenfolge entscheidet über die gefühlte Geschwindigkeit. Sinnvoll ist, billige und häufig scheiternde Prüfungen nach vorne zu ziehen:

Welche Prüfungen inhaltlich in den Minimalsatz gehören, behandelt der Deep Dive Quality Gates für AI-generierten Code.

4. Durchlaufzeit als Engpass

Eine Pipeline, die 40 Minuten braucht, wird umgangen – über Ausnahmen, über Direkt-Merges, über „das prüfen wir später“. Wirksame Maßnahmen:

• Zwischenstände zwischenspeichern – Abhängigkeiten, Build-Ausgaben, Container-Schichten.
• Parallelisieren, statt Stufen zu verketten.
• Betroffene Bereiche gezielt bauen statt immer alles.
• Langsame Prüfungen nach hinten – aber nicht abschaffen.
• Wartezeit messen. Die Zeit von Push bis Rückmeldung ist eine Kennzahl, keine Nebensache.

5. Artefakte und Integrität

Was gebaut wurde, muss identifizierbar und unverändert nachweisbar sein:

• eindeutige Version, verknüpft mit dem Commit-Stand,
• Prüfsumme, idealerweise Signatur des Artefakts,
• Ablage in einer verwalteten Registry statt auf einem Build-Server,
• Aufbewahrung entsprechend der Nachweispflicht, nicht nach Speicherplatz.

Für Teams mit erhöhten Anforderungen lohnt ein Blick auf Stufenmodelle zur Integrität der Lieferkette: Sie geben eine brauchbare Reihenfolge vor, in der sich Maßnahmen einführen lassen.

6. SBOM und Abhängigkeiten

Eine Software-Stückliste beantwortet die Frage, die bei jeder neuen Schwachstelle gestellt wird: „Sind wir betroffen?“ Sie sollte im Build entstehen, nicht nachträglich erhoben werden – und mit dem Artefakt aufbewahrt werden.

Bei AI-gestützter Entwicklung kommt ein zusätzlicher Grund hinzu: Vorgeschlagene Abhängigkeiten sind nicht immer die etablierten. Eine automatische Prüfung gegen eine kuratierte Quelle und eine Lizenz-Positivliste fangen das zuverlässiger ab als ein aufmerksamer Reviewer.

7. Deployment und Zielumgebung

Der letzte Schritt sollte so wenig Handarbeit wie möglich enthalten und trotzdem kontrolliert bleiben:

• Dasselbe Artefakt durch alle Stufen – kein erneuter Build je Umgebung.
• Konfiguration außerhalb des Artefakts, versioniert.
• Freigabe als expliziter Schritt für produktive Umgebungen.
• Zielumgebung im eigenen Einflussbereich – eigenes GitLab, Jenkins, On-Premise, Private Cloud oder Kubernetes.
• Rollback erprobt, nicht nur dokumentiert.

8. Nachweise als Nebenprodukt

Wenn die Pipeline ohnehin baut, prüft und ausliefert, kann sie die Belege gleich mitproduzieren: Testberichte, Prüfergebnisse, SBOM, Prüfsummen, Deployment- Protokoll. Das ist der günstigste Zeitpunkt und der einzige, an dem nichts vergessen wird – ausführlich im Deep Dive Evidence by Design.

Typische Fehler

• Gleitende Versionen und bewegliche Image-Tags – der Build ist nicht reproduzierbar.
• Alle Prüfungen in einer langen Stufe, dadurch lange Wartezeiten.
• Gates als Bericht statt als blockierende Bedingung.
• Erneuter Build je Umgebung – geprüft wurde dann etwas anderes als das, was läuft.
• Artefakt-Aufbewahrung nach Standardwert.
• Deployment über Agent-Zugänge statt über die Pipeline.

Checkliste: Pipeline für hohes Änderungstempo

Fazit

Die Pipeline ist der Ort, an dem aus schneller Arbeit verantwortbare Software wird. Sie muss dafür zwei Eigenschaften gleichzeitig haben, die sich zu widersprechen scheinen: streng genug, dass nichts Ungeprüftes durchgeht, und schnell genug, dass niemand sie umgeht.

Beides ist erreichbar – über Reihenfolge, Parallelisierung und den Verzicht auf Prüfungen, die niemand auswertet. Der Leitsatz bleibt: Ihre Pipeline, Ihre Infrastruktur, Ihr Deployment.