Jenkins
mit KI steuern:
MCP Server, Vibe Coding, Logs.
KI greift an drei Stellen in Jenkins ein. Über den Jenkins MCP Server fragt ein Assistent Builds und Logs in natürlicher Sprache ab. Per Vibe Coding entsteht ein Jenkinsfile aus einem Satz. Und bei einem roten Build nennt die KI aus dem Log die Ursache. Mit Einrichtung, Praxisbelegen und Grenzen.
AI
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
DevOps, CI/CD und Industrial Automation seit 2006.
Wie arbeiten
Jenkins und KI
zusammen?
Jenkins und KI arbeiten an drei Stellen zusammen. Ein KI-Assistent steuert Jenkins über das Model Context Protocol (MCP): Er fragt Job-Status ab, liest Konsolen-Logs und löst auf Wunsch Builds aus. Per Vibe Coding schreibt ein Sprachmodell ein Jenkinsfile aus einer Beschreibung in natürlicher Sprache. Und bei einem roten Build fasst die KI den Log zusammen und nennt die wahrscheinliche Ursache.
Den schnellsten Nutzen bringt meist die dritte Stelle. Die Log-Analyse funktioniert mit reinen Lese-Rechten, der Assistent kann also nichts auslösen, und sie spart genau die Stunden, in denen jemand einen Konsolen-Log von oben nach unten liest.
Laut DORA Report 2025 nutzen 90 % der Entwickler KI bei der Arbeit. Ob es in Ihrer Pipeline etwas bringt, zeigen die DORA-Metriken, vor allem die MTTR. Die strategische Einordnung liefert unser Industrial-DevOps-Angebot.
- § 02–03
Was der Jenkins MCP Server kann und wie Sie ihn in fünf Schritten einrichten
- § 04–05
Wie KI Build-Logs auswertet und was das in der Praxis bringt
- § 06–07
Jenkinsfiles per Vibe Coding und KI-Agenten in der Pipeline
- § 08
Sicher starten, und welcher Workshop zu Ihrem Team passt
Ist KI in der Jenkins-Pipeline bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Gibt es einen
MCP-Server
für Jenkins?
Ja, das Jenkins-Projekt pflegt ein offizielles Plugin dafür. Der Jenkins MCP Server (Version 0.211 vom 30.09.2026, MIT-Lizenz, Jenkins-Core ab 2.541.3) macht den Controller nach dem Model Context Protocol ansprechbar. Claude Code, GitHub Copilot oder Cursor verbinden sich damit und rufen 21 Werkzeuge auf, vom Build-Log bis zum Testergebnis.
Das Protokoll selbst hat Anthropic im November 2024 veröffentlicht und im Dezember 2025 an die Agentic AI Foundation der Linux Foundation übergeben. Es gehört damit keinem Hersteller mehr. Die allgemeine Definition steht im Glossar-Eintrag MCP-Server, hier geht es um das, was das Protokoll in Jenkins möglich macht.
Ist ein MCP-Server dasselbe wie eine API?
Nein, er sitzt eine Ebene darüber. Jenkins hat seit Jahren eine REST-API, aber ein Sprachmodell weiß nicht von selbst, welcher Aufruf welche Frage beantwortet. Der MCP-Server meldet seine Werkzeuge mit Namen, Beschreibung und Parametern an, und das Modell wählt selbst das passende aus. Für Sie heißt das: Statt ein Skript gegen die API zu schreiben, stellen Sie eine Frage.
Was kann der Jenkins MCP Server?
- /01
Builds in natürlicher Sprache auslösen
„Starte job-staging mit dem Profil release.“
triggerBuild · getQueueItemDer Assistent startet Builds, auch mit Parametern. Sie beschreiben das Ziel im Klartext, statt sich durch die Web-Oberfläche zu klicken. Dafür braucht der Service-Account das Recht Job/Build, das er am Anfang bewusst nicht hat.
- /02
Konsolen-Logs lesen und durchsuchen
Gezielt nach Mustern statt endlos scrollen.
getBuildLog · searchBuildLogDas Plugin liefert Build-Logs seitenweise und durchsucht sie nach Mustern wie ERROR oder Exception. Der Assistent holt sich damit nur die Abschnitte, die er für die Antwort braucht, und fasst die Ursache zusammen.
- /03
Job-Status und Queue abfragen
Eine Frage statt fünf offener Tabs.
getJobs · getBuild · getStatus„Welche Jobs hängen seit über einer Stunde in der Queue?“ Der Server beantwortet Fragen zu Status, Queue und Zustand des Controllers und findet Jobs auch über die URL des Git-Repositorys.
- /04
Pipeline-Skripte einsehen und erneut ausführen
Das Jenkinsfile als Kontext für die KI.
getReplayScripts · replayBuildDer Assistent liest das Pipeline-Skript eines Builds, schlägt Änderungen vor und startet den Build mit geänderten Parametern neu. Hier treffen sich Log-Analyse und Vibe Coding.
- /05
Testergebnisse und Changesets holen
Vom roten Test zur verursachenden Änderung.
getTestResults · getBuildChangeSetsTestergebnisse, Changesets und SCM-Konfiguration kommen über dieselbe Schnittstelle. So verbindet die KI einen fehlgeschlagenen Build mit dem Commit, der ihn ausgelöst hat, ohne dass jemand die Teile zusammensucht.
Welcher MCP-Server passt zu Ihrem Jenkins?
Es gibt vier ernsthafte Kandidaten von drei Anbietern. Für die meisten Teams ist das offizielle Plugin der richtige Start, weil es mit Jenkins zusammen gepflegt wird und die vorhandene Rechteverwaltung nutzt. Die Community-Server lohnen sich, wenn Sie mehr Diagnose wollen oder den Server getrennt vom Controller betreiben müssen.
Java · Jenkins-Core ≥ 2.541.3
Python · pip / Docker
TypeScript · Node 20+
CloudBees Unify
Derselbe Standard reicht über Jenkins hinaus. Ein GitLab-MCP-Server und der offizielle GitHub-MCP-Server machen Merge Requests, Issues und CI-Läufe ansprechbar, ein Git-MCP-Server das lokale Repository. Wer statt der Anbindung die Plattformfrage klären will, findet die Grundlage im Vergleich Jenkins vs. GitLab CI vs. Azure DevOps.
Wie richte ich
den Jenkins
MCP Server ein?
In fünf Schritten: Plugin installieren, einen eigenen Service-Account mit API-Token anlegen, den KI-Client mit der Adresse /mcp-server/mcp verbinden, die erste Frage stellen und die Log-Analyse an einem roten Build ausprobieren. Mit einem Jenkins-Admin am Tisch ist der erste Durchlauf nach unserer Erfahrung in rund einer Stunde erledigt.
Einen eigenen Read-only-Schalter hat das offizielle Plugin nicht. Was der Assistent darf, bestimmen die Rechte des Jenkins-Benutzers, dessen Token im Client steht. Ein Account mit Overall/Read und Job/Read kann lesen und nichts auslösen.
Jenkins MCP Server einrichten: fünf Schritte bis zum ersten Prompt
- /01Plugin installieren
Installieren Sie unter „Jenkins verwalten“ das offizielle Plugin „MCP Server“ (plugins.jenkins.io/mcp-server, Version 0.211 vom 30.09.2026). Es setzt einen Jenkins-Core ab 2.541.3 voraus. Nach dem Neustart antwortet der Controller unter /mcp-server/mcp.
- /02Service-Account anlegen
Legen Sie einen eigenen Jenkins-Benutzer für den Assistenten an und erzeugen Sie dafür ein API-Token. Für den Anfang bekommt er nur Lese-Rechte (Overall/Read und Job/Read, kein Job/Build). Damit lehnt Jenkins jeden Versuch ab, einen Build auszulösen, und der Assistent kann nur lesen.
- /03KI-Client verbinden
Tragen Sie die Adresse https://<jenkins>/mcp-server/mcp mit dem Header „Authorization: Basic …“ (Base64 aus Benutzer und Token) in Ihren Client ein. In Claude Code geht das mit „claude mcp add“, in VS Code, Cursor und JetBrains über die jeweilige MCP-Konfiguration. Der Client erkennt danach die Werkzeuge des Plugins.
- /04Erste Frage stellen
Fragen Sie im Klartext, etwa „Welche Jobs sind seit gestern fehlgeschlagen?“ oder „Zeig mir die Fehlerzeilen im letzten Build von plc-firmware-main“. Der Assistent ruft dafür Werkzeuge wie getJobs, getBuild und searchBuildLog auf.
- /05Log-Analyse ausprobieren
Lassen Sie den Assistenten einen roten Build untersuchen: Log holen, Ursache nennen, Korrektur vorschlagen. Die Korrektur geht als Pull-Request durch Ihr normales Review. Schreibrechte für den Service-Account kommen erst dazu, wenn das Team den Ablauf kennt.
# Claude Code: Server einmal registrieren
claude mcp add --transport http jenkins \
https://ci.example-fertigung.de/mcp-server/mcp \
--header "Authorization: Basic <base64 von svc-ki-lesen:API-Token>"
# Der Benutzer svc-ki-lesen hat nur Overall/Read und Job/Read.
# triggerBuild & Co. lehnt Jenkins für ihn ab.
# VS Code mit Copilot: .vscode/mcp.json
{
"servers": {
"jenkins": {
"type": "http",
"url": "https://ci.example-fertigung.de/mcp-server/mcp",
"headers": { "Authorization": "Basic <base64 von svc-ki-lesen:API-Token>" }
}
}
}
# Erste Frage an den Assistenten:
> Zeig mir die Fehlerzeilen im letzten roten Build
> von "plc-firmware-main" und nenne die Ursache.Welcher KI-Client, welcher Weg?
Ein Befehl: „claude mcp add --transport http jenkins …/mcp-server/mcp“ mit dem Authorization-Header (siehe Terminal). Danach stehen die Werkzeuge in jeder Sitzung im Projekt bereit.
Eintrag mit „type: http“, der Adresse /mcp-server/mcp und dem Header in der mcp.json des Editors. Das Jenkins-Projekt hat die Anbindung im Chat von VS Code getestet.
lanbaoshen/mcp-jenkins als Container starten und Jenkins-URL, Benutzer und Token per Umgebungsvariable übergeben. Sauber getrennt vom Arbeitsplatz, gut für abgeschottete OT-Netze.
Denselben Server ohne globale Installation über uvx oder per pip starten. Die schlankste Variante für einen ersten Test am eigenen Rechner.
Kann der MCP-Server lokal laufen?
Ja. Das offizielle Plugin läuft im Controller selbst, also dort, wo Ihr Jenkins steht, auch in einem Netz ohne Internetzugang. Nach außen muss dann nur der KI-Client: Mit einem Cloud-Modell verlassen Prompt und Log-Auszug das Netz, mit einem lokal betriebenen Modell nicht. Wie das im eigenen Rechenzentrum aussieht, zeigt der Beitrag Corporate LLMs in Industrial DevOps.
Service-Account, Matrix-Rechte, Credentials und Plugin-Kompatibilität sind Administrationsarbeit. Im Workshop Jenkins-Administration mit Claude Code richten Sie den MCP-Server gegen eine Übungsinstanz ein und legen fest, welche Werkzeuge der Assistent nutzen darf.
AIWie analysiert
KI Jenkins-
Build-Logs?
Der Assistent holt den Konsolen-Log über MCP, sucht die Fehlerzeilen heraus und ordnet sie einer Fehlerklasse zu. Daraus nennt er die wahrscheinliche Ursache, etwa eine fehlende Abhängigkeit, einen Toolchain-Konflikt, einen Testfehler oder einen Timeout, und schlägt eine Korrektur vor. Sehr lange Logs verdichtet er vorher, weil sie sonst nicht ins Kontextfenster des Modells passen.
Wer Jenkins betreut, kennt den Nachmittag, der im Scrollen durch einen Log mit 148.000 Zeilen verschwindet. Am Abend weiß man, was es nicht war. Diese Stunden holt die KI-Analyse zurück, denn sie liest den Log in Sekunden und zeigt die 200 Zeilen, auf die es ankommt.
AI> Warum ist Build #4471 von plc-firmware-main rot?
[KI] Werkzeug: getBuild plc-firmware-main #4471 → FAILURE
[KI] Werkzeug: searchBuildLog Muster "ERROR|FATAL|Exception"
[KI] 148.302 Log-Zeilen, davon 213 relevant.
Ursache: Toolchain-Konflikt.
Stage "Compile" bricht ab. Erwartet wird arm-none-eabi-gcc 12.2,
der Build-Agent stellt 10.3 bereit (Reihenfolge im PATH).
Kein Fehler im Code, kein flaky Test.
Vorschlag für das Jenkinsfile:
environment { PATH = "/opt/gcc-arm-12.2/bin:${env.PATH}" }
Als Pull-Request anlegen, Review durch das Team.- /01
Die Ursache aus dem Konsolen-Log
Vom Stacktrace zur Ursache in einem Satz.
Der Assistent holt den Log des fehlgeschlagenen Builds, ordnet den Fehler einer Klasse zu (fehlende Abhängigkeit, Toolchain-Konflikt, Testfehler, Timeout) und nennt die wahrscheinliche Ursache mit einem Vorschlag zur Korrektur.
- /02
Flaky Test oder echter Fehler
Erneut starten, aber nicht blind.
Ein Test, der mal rot und mal grün ist, kostet Vertrauen in die ganze Pipeline. Die KI vergleicht den aktuellen Lauf mit früheren Läufen desselben Tests und sagt, ob ein Neustart reicht oder ob der Fehler echt ist. Das spart die Retry-Schleife, die nur Zeit kostet.
- /03
Lange Logs vorher eindampfen
Aus 150.000 Zeilen werden die relevanten 200.
Lange Jenkins-Logs passen in kein Kontextfenster. Frameworks wie LogSage filtern und verdichten den Log, bevor das Modell ihn sieht. Laut LogSage-Paper braucht eine Analyse damit rund 17.800 Tokens statt 122.000 bis 152.000, bei höherer Trefferquote.
- /04
Build-Log trifft Maschinen-Log
Dieselbe Technik auf der OT-Seite.
Im Industrial DevOps endet der Fehler nicht im Build. Dieselbe Analyse lässt sich auf SPS-Fehlerprotokolle, SCADA-Alarme und Logs von Edge-Gateways anwenden und mit den CI-Logs zusammenführen. Dann zeigt sich, ob die Firmware schuld war oder die Anlage.
Beide Comquent-Workshops üben die Log-Analyse an echten Fehlern. In der Jenkins-Administration mit Claude Code geht es um Monitoring und Troubleshooting der Instanz, im Jenkins Pipeline Workshop mit KI um die Ursache roter Stages.
Was bringt
das in der
Praxis?
Drei dokumentierte Fälle reichen vom einzelnen Engineer bis zur CI mit über einer Million Builds. Ein Engineer steuert Jenkins per MCP aus Claude und Cursor. Die Community-Server haben einen festen Ablauf für die Fehlersuche etabliert. Und bei ByteDance analysiert das Framework LogSage Pipeline-Fehler mit 98 % Precision.
Gemeinsam ist allen drei, dass der Nutzen aus dem Lesen kommt. Das Auslösen von Builds per Sprache ist bequem, die Zeit sparen die Logs.
- /01Erfahrungsbericht (K. Józsa, Okt. 2025)
Claude und Cursor an Jenkins über MCP
Ein Engineer band Claude und Cursor über einen schlanken Python-MCP-Server an Jenkins an. Status-Abfragen zu Jobs und Builds im Gespräch funktionierten, ebenso parametrisierte Deployments im Klartext. Seine ehrliche Einordnung: Nicht jeder MCP-Server bietet Zugriff auf Logs, und ohne den bleibt die wichtigste Frage unbeantwortet. Der Log-Zugriff ist das, worauf es ankommt.
- /02Open-Source-Projekte (GitHub, 2025)
Ein fester Ablauf für die Fehlersuche
Die Community-Server lanbaoshen/mcp-jenkins und kud/mcp-jenkins haben ein wiederkehrendes Muster etabliert: Der Agent fragt den Build-Status ab, bestätigt den Fehlschlag, holt den Konsolen-Output und lässt das Modell die Ursache zusammenfassen. Aus dem Wühlen im Log wird eine schnelle Einordnung, und die MTTR sinkt.
- /03Produktionsstudie LogSage (arXiv 2506.03691, 2025)
1,07 Mio. Builds, 98 % Precision
In der CI von ByteDance läuft mit LogSage ein LLM-Framework für die Ursachenanalyse von CI/CD-Fehlern produktiv: über 1,07 Millionen Pipeline-Läufe, 36.845 Entwickler, mehr als 80 % Abdeckung. Ergebnis: 98 % Precision im Benchmark, über 80 % in der Produktion und 47,4 % erfolgreiche automatische Reparaturen, bei rund einem Zehntel des Token-Verbrauchs gängiger Vergleichsverfahren.
Was wir in eigenen Lab-Setups gelernt haben. Den größten Nutzen bringt sofort die Log-Analyse mit reinen Lese-Rechten, ohne jeden Eingriff in die Produktion. Aktionen, die etwas auslösen, also Builds und Deployments, kommen erst hinter klaren Freigaben dazu. Quellen: Jenkins MCP Server Plugin, lanbaoshen/mcp-jenkins, LogSage (arXiv 2025).
Kann KI ein
Jenkinsfile
schreiben?
Ja, und zwar schneller, als man die Syntax nachschlägt. Beim Vibe Coding beschreiben Sie die Pipeline in einem Satz, und ein Sprachmodell wie Claude oder GitHub Copilot schreibt daraus eine Declarative Pipeline mit Stages, parallelen Tests und Quality Gates. Über weitere Prompts schärfen Sie nach. Was herauskommt, ist ein Entwurf, der vor dem Merge durch Review, Linter und Secret-Scanning geht.
Den Begriff Vibe Coding prägte Andrej Karpathy im Februar 2025. Das Fraunhofer IESE beschreibt die Rolle des Menschen dabei als „konzeptuellen Impulsgeber“: Sie geben die Richtung vor, das Modell schreibt.
# Prompt:
> Erzeuge eine Declarative Pipeline: Maven-Build, parallele
> Unit- und Integrationstests, SonarQube-Quality-Gate,
> Deploy auf Staging nur auf main, mit Freigabe.
# Generiertes Jenkinsfile (Auszug, vor dem Review):
pipeline {
agent { label 'linux-docker' }
options { timestamps(); timeout(time: 30, unit: 'MINUTES') }
stages {
stage('Build') { steps { sh 'mvn -B clean package' } }
stage('Test') {
parallel {
stage('Unit') { steps { sh 'mvn test' } }
stage('Integration') { steps { sh 'mvn verify -Pit' } }
}
}
stage('Quality Gate') {
steps { withSonarQubeEnv('sonar') { sh 'mvn sonar:sonar' } }
}
stage('Deploy (Staging)') {
when { branch 'main' }
steps {
input message: 'Deploy auf Staging?', ok: 'Go'
sh "./deploy.sh staging ${env.BUILD_NUMBER}"
}
}
}
}Der Entwurf steht in Sekunden, und genau dort beginnt die Verantwortung. Ein einziger unbedachter sh-Step läuft mit denselben Credentials wie Ihr Produktions-Deployment. Die Frage, wer das generierte Jenkinsfile freigegeben hat, beantworten Sie besser vor einem Vorfall als danach.
AIWelche Risiken hat Vibe Coding in der CI/CD?
Die größten Risiken sind erfundene Plugins und Abhängigkeiten (Slopsquatting: laut USENIX Security 2025 existieren rund 20 % der von Sprachmodellen empfohlenen Pakete nicht), mehr Secrets im Code (GitGuardian misst 40 % mehr Leaks in Repositories mit Copilot), ungetesteter Groovy-Code und unsichere Shell-Steps. Weil ein Jenkinsfile mit den Rechten des Build-Systems läuft, gehören Review, Linting und Secret-Scanning vor jeden Merge.
- /01
Erfundene Plugins und Pakete (Slopsquatting)
RisikoSprachmodelle erfinden Abhängigkeiten, die es nicht gibt. Laut USENIX Security 2025 existieren rund 20 % der empfohlenen Pakete nicht, und 43 % dieser Erfindungen wiederholen sich vorhersagbar. Genau diese Namen registrieren Angreifer.
GegenmaßnahmePlugin- und Paketnamen gegen die offiziellen Register prüfen, Lockfiles erzwingen, in der Pipeline eine SBOM erzeugen.
- /02
Secrets im generierten Code
RisikoGitGuardian misst in Repositories mit Copilot 40 % mehr Secret-Leaks. KI schreibt Tokens und Passwörter gern direkt ins Jenkinsfile.
GegenmaßnahmeCredentials-Binding statt Klartext, Secret-Scanning als Quality Gate, Pre-Commit-Hooks.
- /03
Ungetesteter Groovy und unsichere sh-Steps
RisikoEin Jenkinsfile läuft mit den Rechten des Build-Systems. Ein erfundener Aufruf einer Shared Library oder ein unkontrollierter sh-Step wird so zum Einfallstor.
GegenmaßnahmePipeline-Linter, Sandbox für Scripted Pipelines, Review jeder generierten Stage vor dem Merge.
- /04
Code, der nur fast stimmt
RisikoIm Stack Overflow Survey 2025 nennen 45 % Code, der „fast richtig, aber nicht ganz“ ist, als größten Ärger mit KI. Nur 29 % vertrauen der Ausgabe.
GegenmaßnahmeVibe Coding als Entwurf behandeln. Die Prüfung durch jemanden, der Jenkins kennt, bleibt Pflicht (Fraunhofer IESE).
Sicher vibecoden lernt man am echten Jenkinsfile. Im Jenkins Pipeline Workshop mit KI & Claude Code erzeugen, reviewen und härten Sie Declarative Pipelines, mit Prompts, Quality Gates und einem prüfenden Blick auf jede generierte Stage. Zwei Tage, vor Ort in München oder remote.
Was ist ein
KI-Agent in der
Pipeline?
Ein KI-Agent ist ein Sprachmodell, das selbständig Werkzeuge aufruft. Er liest Build-Status, holt Logs, ändert Dateien und arbeitet eine Aufgabe in mehreren Schritten ab, bis das Ziel erreicht ist. Das unterscheidet ihn vom Chatfenster, das nur antwortet.
Für Jenkins gibt es zwei offizielle Wege, und sie zeigen in entgegengesetzte Richtungen. Der eine holt Jenkins zum Agenten, der andere holt den Agenten in den Build.
Der Agent sitzt am Arbeitsplatz (Claude Code, GitHub Copilot, Cursor) und spricht Jenkins über das Model Context Protocol an: Status lesen, Logs holen, Builds auslösen. Das ist der Weg aus §02 bis §04. Der mögliche Schaden bleibt klein, solange der Service-Account nur lesen darf.
Das AI-Agent-Plugin (seit März 2026, Version 167 vom 11.10.2026, Jenkins-Core ab 2.528.3) dreht die Richtung um. Es führt Claude Code als claudeCode()-Step direkt im Jenkins-Job aus, mit Konversations-Log und Freigabe-Gates je Lauf. Der Agent wird Teil des Builds und kann dort Jenkinsfiles umbauen, rote Stages reparieren oder Testdaten pflegen.
Im Industrial DevOps gilt für beide Richtungen dieselbe Leitplanke. Ein Agent, der eine Produktionslinie berühren kann, arbeitet hinter Freigabe-Gates und einem Audit-Trail über Git. Wie sich Agenten in Self-Healing Pipelines und AIOps einordnen, vertieft der Beitrag AIOps in der Industrie. Beide Plugin-Richtungen am eigenen Jenkinsfile ausprobieren können Sie im Jenkins Pipeline Workshop mit KI & Claude Code.
Wie starten Sie,
ohne die Produktion
zu riskieren?
Mit dem MCP-Server und einem Service-Account, der nur lesen darf. Darauf folgen die Log-Analyse für rote Builds und ein Pilotprojekt, in dem die KI Jenkinsfiles schreibt, die durch das normale Review gehen. Die Wirkung belegen Sie an der MTTR.
Am Anfang steht meist eine Jenkins-Instanz, die über Jahre gewachsen ist, mit Dutzenden Jobs, und niemand möchte der Erste sein, der dort mit KI experimentiert. Die Lese-Rechte nehmen genau diese Sorge, weil der Assistent nichts auslösen kann.
AI- /01
Zuerst nur lesen lassen
Aufwand: NiedrigStarten Sie mit einem Service-Account, der nur lesen darf. Die KI liest Logs und fasst Ursachen zusammen, kann aber keinen Build auslösen und nichts deployen. Der Nutzen ist ab dem ersten roten Build da, das Risiko für die Produktion ist null.
- /02
Eigener Account, minimale Rechte
Aufwand: NiedrigLegen Sie nie Ihr eigenes Admin-Token in den KI-Client. Ein eigener Benutzer mit API-Token und genau den Rechten, die er braucht, macht im Audit-Log sichtbar, was der Assistent getan hat. Tokens und Authorization-Header gehören weder in Prompts noch in Logs.
- /03
Jenkinsfiles generieren, aber im Pull-Request prüfen
Aufwand: MittelLassen Sie Stages per Prompt schreiben und behandeln Sie das Ergebnis als Entwurf. Pipeline-Linter, Secret-Scanning und ein menschliches Review vor dem Merge sind nicht verhandelbar.
- /04
Ein Mensch entscheidet über jedes Deployment
Aufwand: MittelIn OT-Umgebungen löst kein Agent selbständig ein Produktions-Deployment aus. Ein input-Step im Jenkinsfile, klar begrenzte Werkzeug-Rechte und ein Audit-Trail über Git halten den Menschen in der Entscheidung.
- /05
Die Wirkung an der MTTR messen
Aufwand: MittelMessen Sie über vier bis sechs Wochen, wie sich die Mean Time To Recovery durch die KI-Log-Analyse verändert. Mit der Zahl wird aus dem Pilot ein Argument für die nächste Budgetrunde.
Woran Sie merken, dass es wirkt: Beim nächsten roten Build öffnet das Team zuerst den Chat und erst danach die Konsole. Die KI erklärt den Fehler in drei Sätzen, während der Log im Browser noch lädt.
Welcher Workshop passt zu Ihrem Team?
Comquent bietet zu diesem Artikel zwei professionelle Workshops an, je zwei Tage, ab 1.690 € netto pro Person, vor Ort in München oder remote. Die Trennung folgt der Rolle: Wer die Instanz betreibt, braucht etwas anderes als jemand, der Pipelines schreibt.
Jenkins-Administration mit Claude Code
Für Admins und CI/CD-Verantwortliche, deren Jenkins über Jahre gewachsen ist.
Jenkins aufsetzen, Configuration as Code schreiben, Plugin-Konflikte lösen, Rechte und Credentials sauber einrichten. Dazu richten Sie den MCP-Server gegen eine Übungsinstanz ein, legen fest, welche Werkzeuge der Assistent nutzen darf, und werten Build-Logs mit Claude Code aus.
Agenda und TermineJenkins Pipeline Workshop mit KI & Claude Code
Für Entwickler, die Jenkinsfiles und Shared Libraries schreiben und pflegen.
Jenkinsfiles mit KI erzeugen, reviewen und härten, Shared Libraries testen, CPS-Fehler lösen. Auf dem Plan stehen auch die Build-Log-Analyse mit Ursache und beide Plugin-Richtungen: MCP am Arbeitsplatz und das AI-Agent-Plugin im Build.
Agenda und TermineDie Comquent GmbH aus Puchheim bei München berät seit 2006 Industrieunternehmen zu DevOps, CI/CD-Automatisierung und Industrial DevOps. Kurse zum Selbstlernen rund um Jenkins, KI-Pipelines und MCP gibt es in der Comquent Academy.
Was Engineers
wirklich fragen.
Gibt es einen MCP-Server für Jenkins?
Ja. Das Jenkins-Projekt pflegt ein offizielles Plugin namens „MCP Server“, das den Controller nach dem Model Context Protocol ansprechbar macht. Es stellt 21 Werkzeuge bereit, unter anderem zum Auslösen von Builds, zum Lesen und Durchsuchen von Build-Logs, für Testergebnisse, Changesets und das Replay von Pipelines. Die aktuelle Version 0.211 vom 30.09.2026 setzt einen Jenkins-Core ab 2.541.3 voraus. Daneben gibt es Community-Server wie lanbaoshen/mcp-jenkins (Python) und kud/mcp-jenkins (TypeScript).
Wie steuere ich Jenkins mit KI?
Über das Model Context Protocol (MCP). Sie installieren das offizielle MCP-Server-Plugin und tragen dessen Adresse /mcp-server/mcp mit einem API-Token in Ihren KI-Client ein, etwa Claude Code, GitHub Copilot in VS Code oder Cursor. Danach fragen Sie im Klartext nach Build-Status, Logs oder Testergebnissen, und der Assistent ruft die passenden Werkzeuge auf. Für den Anfang reicht ein eigener Service-Account mit reinen Lese-Rechten.
Was ist ein MCP-Server?
Im CI/CD-Kontext ist ein MCP-Server die Schicht, die einen Build-Server wie Jenkins für KI-Assistenten ansprechbar macht. Er meldet seine Werkzeuge nach einem offenen Standard an, also Build auslösen, Log lesen oder Job-Status abfragen, und das Sprachmodell ruft sie auf, wenn eine Frage es verlangt. Statt für jeden Assistenten eine eigene Jenkins-Integration zu bauen, genügt eine Schnittstelle. Die allgemeine Definition des Protokolls steht in unserem Glossar-Eintrag zum MCP-Server.
Was bringt ein MCP-Server?
Er ersetzt Klickwege und Hilfsskripte durch eine Frage im Klartext. Für Jenkins heißt das: Der Assistent holt den Konsolen-Log eines roten Builds selbst, gleicht ihn mit dem auslösenden Commit ab und nennt die Ursache, statt dass jemand Web-Oberfläche, Log und Git-Historie nacheinander öffnet. Der Nutzen kommt weniger aus dem Protokoll als daraus, dass Log, Job-Status, Testergebnis und Changeset zum ersten Mal in einem Kontext liegen.
Welche Beispiele gibt es für MCP-Server?
In der CI/CD sind es vor allem vier: das offizielle Jenkins-MCP-Server-Plugin, die Community-Server lanbaoshen/mcp-jenkins (Python, mit Read-only-Modus und Plugin-Diagnose) und kud/mcp-jenkins (TypeScript, 37 Werkzeuge) sowie der CloudBees MCP Server für Unify-Umgebungen. Außerhalb von Jenkins gibt es MCP-Server für GitLab, GitHub, Jira, Datenbanken und Dateisysteme. Das Muster ist immer dasselbe: Ein System meldet seine Werkzeuge standardisiert an den KI-Client.
Wer bietet MCP-Server für Jenkins an?
Das Jenkins-Projekt selbst mit dem offiziellen Plugin „MCP Server“ (MIT-Lizenz), die Open-Source-Community mit lanbaoshen/mcp-jenkins und kud/mcp-jenkins und CloudBees mit einem Kontext-Layer über Unify. Für die meisten Teams ist das offizielle Plugin der richtige Start. Es wird zusammen mit Jenkins gepflegt, spricht Streamable HTTP, SSE und einen zustandslosen Modus und nutzt die vorhandene Rechteverwaltung von Jenkins.
Sind MCP-Server sicher?
Die Sicherheit hängt an der Konfiguration, weniger am Protokoll. Ein Jenkins-MCP-Server arbeitet mit den Rechten des Benutzers, dessen API-Token im Client steht. Entscheidend sind deshalb ein eigener Service-Account mit minimalen Rechten, Lese-Rechte für den Anfang und ein Umgang mit Tokens, der sie nie in Prompts oder Logs geraten lässt. In regulierten OT-Umgebungen kommen eine menschliche Freigabe vor jedem Deployment, ein Audit-Trail über Git und Quality Gates nach IEC 62443 hinzu. Die bekannt gewordenen Vorfälle rund um MCP gingen auf zu weit gefasste Berechtigungen und offen erreichbare Endpunkte zurück.
Wann sollte man MCP nicht einsetzen?
Wenn eine Aktion ohne menschliche Prüfung eine Anlage oder ein Produktionssystem verändern würde. Ein Assistent, der über MCP Deployments auf Maschinen auslösen darf, braucht davor eine Freigabe im Jenkinsfile (input-Step) und einen Audit-Trail. Ebenfalls ungeeignet ist MCP für Aufgaben, die ein festes Skript zuverlässiger erledigt, etwa ein nächtlicher Build nach Zeitplan. MCP lohnt sich dort, wo jemand eine Frage hat, deren Antwort heute in mehreren Fenstern verteilt liegt.
Was ist ein KI-Agent in der CI/CD-Pipeline?
Ein KI-Agent in der CI/CD-Pipeline ist ein Sprachmodell, das selbständig Werkzeuge aufruft und Aufgaben in mehreren Schritten abarbeitet: Build-Status lesen, Logs holen, Dateien ändern, Ergebnis prüfen. Für Jenkins gibt es zwei offizielle Wege. Über das MCP-Server-Plugin steuert ein Agent am Arbeitsplatz (Claude Code, GitHub Copilot, Cursor) den Controller von außen. Das AI-Agent-Plugin (seit März 2026, aktuell Version 167, Jenkins-Core ab 2.528.3) führt Claude Code als claudeCode()-Step direkt im Jenkins-Job aus, mit Konversations-Log und Freigabe-Gates je Lauf.
Wie analysiert KI Jenkins-Build-Logs?
Ein KI-Assistent holt über MCP den Konsolen-Log eines fehlgeschlagenen Builds, durchsucht ihn nach Fehlermustern und fasst die Ursache zusammen, etwa eine fehlende Abhängigkeit, einen Toolchain-Konflikt, einen Testfehler oder einen Timeout. Dazu schlägt er eine Korrektur vor. Spezialisierte Frameworks gehen weiter: LogSage, im Einsatz in der CI von ByteDance, erreicht laut arXiv-Paper von 2025 eine Precision von 98 % bei der Ursachenanalyse und repariert 47 % der Fälle automatisch.
Kann man Jenkins-Pipelines mit KI generieren?
Ja. GitHub Copilot, Claude Code und ähnliche Werkzeuge erzeugen aus einer Beschreibung in natürlicher Sprache Declarative- oder Scripted-Pipelines mit Stages, paralleler Ausführung, Matrix-Builds und Security-Scans. Das spart beim Schreiben viel Zeit. Weil eine Pipeline mit den Rechten des Build-Systems läuft, geht jedes generierte Jenkinsfile vor dem Merge durch Review und Test und wird auf erfundene Plugins und unsichere sh-Steps geprüft.
Was ist Vibe Coding?
Auf die CI/CD übertragen heißt Vibe Coding: Sie beschreiben die gewünschte Pipeline in einem Satz, etwa „Maven-Build, parallele Tests, SonarQube-Quality-Gate, Deploy auf Staging nur auf main“, und das Sprachmodell schreibt das Jenkinsfile, das Sie über weitere Prompts nachschärfen. Statt Groovy-Syntax nachzuschlagen, prüfen Sie ein Ergebnis. Den Begriff prägte Andrej Karpathy im Februar 2025. Die allgemeine Definition steht in unserem Glossar-Eintrag zu Vibe Coding.
Welche Risiken hat Vibe Coding in der CI/CD?
Die größten Risiken sind erfundene Abhängigkeiten und Plugins (Slopsquatting: laut USENIX Security 2025 existieren rund 20 % der von Sprachmodellen empfohlenen Pakete nicht), mehr Secrets im Code (GitGuardian misst 40 % mehr Secret-Leaks in Repositories mit Copilot), ungetesteter Groovy-Code und unsichere Shell-Steps, die mit den Credentials der Pipeline laufen. Weil ein Jenkinsfile mit den Rechten des Build-Systems ausgeführt wird, prüft vor dem Merge immer ein Mensch.
Wie gut ist Vibe Coding?
Für Prototypen und Entwürfe ist Vibe Coding schnell und brauchbar, für Produktionsartefakte wie Jenkinsfiles bleibt es ein Entwurf. Im Stack Overflow Developer Survey 2025 nennen 45 % der Befragten Code, der „fast richtig, aber nicht ganz“ ist, als größten Ärger mit KI, und nur 29 % vertrauen der Ausgabe. In der CI/CD heißt das: generierten Code reviewen, linten und auf erfundene Plugins und unsichere sh-Steps prüfen.
Welche Beispiele gibt es für Vibe Coding in der CI/CD?
Typisch sind drei Fälle. Erstens ein vollständiges Declarative Jenkinsfile aus einem Prompt (Maven-Build, parallele Tests, SonarQube-Quality-Gate, Staging-Deploy). Zweitens eine bestehende Pipeline, die per Prompt Security-Scans oder Matrix-Builds bekommt. Drittens ein roter Build, dessen Log die KI auswertet und dessen Korrektur sie als Änderung am Jenkinsfile vorschlägt. In jedem Fall ist das Ergebnis ein Entwurf, der vor dem Merge reviewt wird.
Ist Jenkins 2026 noch relevant?
Ja. Jenkins gehört weiter zu den meistgenutzten CI/CD-Servern, gerade in Industrie und OT, wo selbst betriebene Pipelines ohne Cloud-Anbindung gefragt sind. Das MCP-Server-Plugin (Version 0.211 im September 2026) und das AI-Agent-Plugin (Version 167 im Oktober 2026) haben Jenkins an KI-Assistenten und Agenten angeschlossen. Für eine Plattform-Entscheidung lohnt der Vergleich mit GitLab CI und Azure DevOps.
Ist der Jenkins MCP Server kostenlos?
Ja. Jenkins und das MCP-Server-Plugin sind Open Source unter MIT-Lizenz und kostenlos, ebenso die Community-Server. Kosten entstehen für Betrieb, Hosting und Wartung und für Enterprise-Angebote wie CloudBees. KI-Assistenten wie GitHub Copilot oder Claude Code und die genutzten Modell-APIs rechnen ihre Anbieter separat ab.
Wie lernt ein Team, Jenkins mit KI zu betreiben?
Am schnellsten an der eigenen oder einer Übungsinstanz, mit jemandem, der die Stolperstellen kennt. Comquent bietet dafür zwei zweitägige Workshops an. „Jenkins-Administration mit Claude Code“ richtet sich an Admins: Installation, Configuration as Code, Plugins, Rechte und den MCP-Server mit festgelegten Werkzeug-Rechten. Der „Jenkins Pipeline Workshop mit KI & Claude Code“ richtet sich an Pipeline-Entwickler: Jenkinsfiles generieren und reviewen, Shared Libraries testen, Build-Logs auswerten und das AI-Agent-Plugin einsetzen.
Wie starte ich mit KI und Jenkins im Industrial DevOps?
Mit einem Schritt ohne Produktionsrisiko: den MCP-Server mit einem Service-Account, der nur lesen darf, und die KI-Log-Analyse für rote Builds. Parallel kann ein Pilotprojekt Jenkinsfiles per Copilot oder Claude Code erzeugen, die durch das normale Review gehen. Die Wirkung messen Sie über vier bis sechs Wochen an der MTTR. Für sicherheitskritische OT-Pipelines gelten Freigabe-Gates, menschliche Prüfung und Quality Gates nach IEC 62443.
Wie geht es bei Ihnen mit KI in der Jenkins-Pipeline weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
Corporate LLMs in Industrial DevOps
Lokales LLM mit RAG im eigenen Netz: Vorteile, Herausforderungen und vier Anwendungsbeispiele von der Jenkins-Log-Triage bis zur Wissensbasis.
AIOps in der Industrie: Praxisbeispiele und Kennzahlen
Wie AIOps die Daten aus IT und Anlage gemeinsam auswertet, mit vier Praxisbeispielen und den Kennzahlen MTTD, MTTR und MTBF.
Jenkins vs. GitLab CI vs. Azure DevOps
CI/CD-Plattform-Vergleich 2026: Stärken, Schwächen und Migrationspfade.
CI/CD für SPS: TIA-Portal mit Jenkins
Build, Test und Deployment von TIA-Portal-Projekten mit Jenkins automatisieren.
Claude Code im Industrial DevOps
Headless in der Pipeline, Legacy verstehen, die Grenze an der SPS und der DSGVO-konforme Deployment-Weg.
Erstgespräch.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance