Agentische CI/CD: Wie unsere Software Factory vom Issue bis zum Deployment läuft

Warum eine Fabrik

Wir betreiben viele kleine und mittlere Projekte gleichzeitig: Integrationsdienste, interne Werkzeuge, Produkte. Jedes davon brauchte ein Repository, eine Pipeline, ein Deployment, ein Monitoring. Irgendwann haben wir festgestellt, dass wir dieselben Dinge zum fünften Mal von Hand aufsetzen – und jedes Mal ein bisschen anders.

Die Antwort war eine versionierte «Fabrik»: ein Repository mit Workflow-Templates, Runbooks für die VM-Provisionierung und einer Design-Spezifikation, die festlegt, wie ein Projekt vom Issue bis zum laufenden Dienst kommt. Neu ist daran vor allem, dass ein KI-Agent den ersten Schritt macht.

Der Ablauf

1. Prompt oder Issue. Ein Issue beschreibt, was gebaut werden soll. Gut geschrieben, mit Akzeptanzkriterien.
2. KI-Agent. Claude Code oder Codex nimmt das Issue, arbeitet im Repository und öffnet einen Pull Request. Der Agent hält sich an die Konventionen, die in AGENTS.md beziehungsweise CLAUDE.md festgelegt sind.
3. CI. Tests, Lint, Security-Scan, Build eines Container-Images und Push in die GitHub Container Registry.
4. KI-Review plus Human Gate. Ein zweiter Agent reviewt den PR. Dann entscheidet ein Mensch.
5. CD. Nach dem Merge deployt ein self-hosted Runner in einer Linux-VM das neue Image.
6. Monitoring. Grafana, Prometheus und Loki, mit Alloy als Collector. Jeder Dienst liefert Metriken und Logs, sonst gilt er als nicht fertig.

AGENTS.md und CLAUDE.md: Die Konventionen sind das Produkt

Der Agent ist nur so gut wie der Kontext, den er bekommt. Deshalb steckt die meiste Arbeit nicht in der Pipeline, sondern in den Konventionsdateien. Sie beschreiben pro Projekt:

• Wie das Repository aufgebaut ist und wo was hingehört
• Welche Befehle für Tests, Lint und Build gelten
• Welche Bibliotheken bevorzugt und welche vermieden werden
• Wie Commits und PR-Beschreibungen aussehen sollen
• Was der Agent nicht tun darf – etwa Secrets anfassen oder Migrationen ohne Rücksprache erzeugen

Diese Dateien sind lebende Dokumente. Jedes Mal, wenn ein Agent etwas Dummes tut, prüfen wir zuerst, ob die Konvention fehlte, bevor wir dem Modell die Schuld geben. Meistens fehlte die Konvention.

Dazu kommen Planning-Dokumente: Bei grösseren Aufgaben schreibt der Agent zuerst einen Plan, den wir lesen, bevor Code entsteht. Das kostet Minuten und spart Stunden.

Die CI ist nicht verhandelbar

Alles, was der Agent produziert, geht durch dieselbe CI wie menschlicher Code – und die ist bewusst streng:

• Tests müssen bestehen, und der Agent darf sie nicht abschalten
• Lint und Formatierung sind Pflicht, keine Empfehlung
• Der Security-Scan blockiert bekannte Schwachstellen in Abhängigkeiten
• Das Image wird gebaut und mit Commit-Hash getaggt, damit jeder Stand reproduzierbar ist

Der Punkt ist: Der Agent produziert schneller als ein Mensch, also müssen die automatischen Prüfungen härter sein, nicht weicher.

Wofür das Human Gate da ist

Die naheliegende Frage lautet: Wenn ein Agent den Code schreibt und ein zweiter Agent ihn reviewt, wozu noch ein Mensch? Unsere Antwort nach einigen Monaten Betrieb:

Das Human Gate ist nicht dafür da, Syntax zu prüfen. Das machen die Werkzeuge besser. Es ist dafür da, drei Fragen zu beantworten, die kein Agent zuverlässig beantwortet:

• Ist das, was gebaut wurde, das, was gemeint war? Der Agent löst das Issue, wie es geschrieben steht. Ob das Issue richtig war, weiss nur der Mensch.
• Passt die Änderung in den grösseren Zusammenhang? Ein Agent sieht das Repository. Er sieht nicht, dass nächste Woche eine andere Abteilung dieselbe Schnittstelle braucht.
• Wollen wir das überhaupt betreiben? Jede Änderung ist auch ein Betriebsversprechen. Diese Verantwortung lässt sich nicht delegieren.

Das KI-Review davor sorgt dafür, dass der Mensch nicht seine Zeit mit Dingen verschwendet, die eine Maschine finden kann. Der Mensch bekommt einen PR, der technisch sauber ist, und konzentriert sich auf die Absicht.

CD in einer Linux-VM

Das Deployment läuft über einen self-hosted Runner in einer eigenen Linux-VM. Wir haben uns gegen gehostete Runner entschieden, weil die Zielumgebung – interne Netze, eigene Dienste – ohnehin nur von innen erreichbar ist. Die VM-Provisionierung ist als Runbook dokumentiert, damit sie sich in einer Stunde neu aufsetzen lässt.

Monitoring ist Teil der Definition von «fertig». Ein Dienst, der keine Metriken nach Prometheus und keine Logs nach Loki liefert, wird nicht als abgeschlossen betrachtet. Das klingt streng, hat uns aber vor genau den stillen Ausfällen bewahrt, die man sonst erst vom Anwender erfährt.

Fazit

Agentische CI/CD ist kein Ersatz für Ingenieure, sondern eine Verschiebung ihrer Arbeit: weg vom Tippen, hin zum Formulieren von Absicht und Konventionen und zum Entscheiden am Gate. Der Agent macht die Fabrik schnell. Die Konventionen und die CI machen sie sicher. Der Mensch am Gate macht sie sinnvoll.