Jenkins

Ein Build in Jenkins beginnt mit einem Auslöser: einem Webhook aus dem Git-Server, einem Zeitplan oder einem Klick. Der Controller liest daraufhin das Jenkinsfile aus dem Repository und verteilt die einzelnen Stages an Agents, also Build-Maschinen, die er über Labels auswählt. Agents stehen entweder fest bereit oder entstehen bei Bedarf als Container über die Kubernetes- und Docker-Cloud-Plugins. Konfiguration und Build-Historie legt der Controller im Dateisystem ab, im Verzeichnis JENKINS_HOME. Seit der Abspaltung von Hudson im Jahr 2011 hat sich an diesem Grundprinzip wenig geändert.

Gegenüber Diensten wie GitHub Actions oder GitLab CI liegt der Unterschied im Betriebsmodell. Jenkins ist ein eigenständiger Server, den Sie selbst betreiben, und hängt an keiner Code-Plattform. Das kostet Wartung, bringt aber Freiheit bei den Agents. In der Industrie zählt genau das: Ein Agent kann Firmware für Embedded-Targets cross-compilieren, einen Hardware-in-the-Loop-Prüfstand (HiL, Test gegen echte Steuergeräte-Hardware) ansteuern oder das Siemens TIA Portal auf einem Windows-Rechner bedienen. Weil Jenkins keinen Internetzugang braucht, läuft das alles auch im segmentierten Produktionsnetz.

Die Stolpersteine sind seit Jahren dieselben. Plugins wachsen wild und geraten in Versionskonflikte, Konfiguration entsteht durch Klicken in der Oberfläche und lässt sich nicht reproduzieren, und ein einzelner Controller wird zum Single Point of Failure. Typisch ist ein Controller, dessen Einstellungen über zehn Jahre gewachsen sind und außer im Dateisystem nirgends stehen. Wer ihn verliert, rekonstruiert Tage lang. Hier setzt KI-Assistenz an: Ein Terminal-Assistent wie Claude Code liest Build-Logs, schlägt vor, welche Plugins sich zusammenlegen lassen, und überführt die geklickte Konfiguration in versionierbares JCasC. Das Ergebnis liegt als Git-Commit vor und lässt sich prüfen.