Aus Jenkinsfile-Pflege wird Pipeline-Engineering. In 2 Tagen entwickeln Sie Jenkins-Pipelines systematisch: Declarative und Scripted, Shared Libraries, Pipeline-Testing, Parallelisierung. Claude Code sitzt dabei als Pair-Programmer im Terminal.
2 TAGE HANDS-ON · MAX. 12 TEILNEHMER · AB 1.690 € · VOR ORT ODER REMOTE
Comquent Consulting Team
Jenkins- & CI/CD-Experten
Declarative und Scripted Pipelines, Shared Libraries, Pipeline-Testing und Performance-Optimierung, mit KI-Unterstützung durch Claude Code. Praxiserfahrung aus 47+ Kundenprojekten seit 2006.
Der Jenkins Pipeline Workshop mit KI ist eine 2-tägige Intensiv-Schulung (16 Stunden, max. 12 Teilnehmer, ca. 80 % Hands-on) für DevOps-Engineers und Pipeline-Entwickler. Sie entwickeln Declarative- und Scripted-Pipelines, Shared Libraries und JenkinsPipelineUnit-Tests mit Claude Code, dem KI-Assistenten von Anthropic im Terminal, und nehmen eine produktionsreife Shared Library inklusive CLAUDE.md-Template mit. Der Zuschnitt kommt aus der Industrial-DevOps-Praxis: Pipelines, die Firmware bauen, Hardware ansteuern und Freigaben belegen müssen. Ab 1.690 € netto pro Teilnehmer.
Pipelines wachsen, Shared Libraries werden unübersichtlich, Debugging kostet Stunden. Irgendwann traut sich niemand mehr, die zentrale Jenkinsfile anzufassen. In Industrieprojekten kommt dazu, was eine Web-Pipeline nie leisten muss: Cross-Compiler, Hardware im Test, Nachweise, die ein Auditor sehen will.
Zwei Tage Intensiv-Workshop mit Claude Code direkt im Terminal. Jemand, der Jenkins-Groovy im Schlaf spricht, sitzt dabei praktisch neben Ihnen. Bei den meisten Teilnehmern klickt es am ersten Nachmittag: Die eigene, über Jahre gewachsene Jenkinsfile ist refactored, und der Build läuft nach vierzig Minuten zum ersten Mal wieder sauber durch.
AIIst die Pipeline-Entwicklung 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.
Acht Module, alle im Terminal.
Tag 1 baut auf. Sie schreiben die erste Jenkinsfile mit Claude Code, legen eine Shared Library mit vars/, src/ und resources/ an und haben abends ein Beispielprojekt, das baut, testet und deployt. Tag 2 macht dieses Projekt schnell und testbar: parallele Stages, Multi-Branch- und Monorepo-Trigger, JenkinsPipelineUnit. Am Nachmittag arbeiten Sie an Ihrer eigenen Pipeline weiter, falls Sie eine mitbringen.
Declarative vs. Scripted, wann was? Claude Code als Entwicklungspartner einrichten. Erste Pipeline live generieren und deployen.
Eigene Skills für wiederkehrende Aufgaben: Jenkinsfile-Linting, Stage-Generierung, Library-Scaffolding. Wiederverwendbare KI-Workflows.
vars/, src/, resources/ und wie Jenkins Libraries lädt. Bestehende Libraries analysieren, neue Funktionen entwickeln, Unit-Tests schreiben.
Komplettes Beispielprojekt von Grund auf: Multi-Stage-Pipeline mit Build, Test, Deploy. Iterative Entwicklung mit Claude Code.
Agent-Zuweisung, Workspace-Management, Parallelisierung von Stages, Caching-Strategien. Performance-Analyse mit Claude Code.
when-Direktiven, dynamische Pipeline-Generierung, Multi-Branch und Monorepo-Strategien, Matrix-Builds und Conditional Execution.
JenkinsPipelineUnit verstehen, Test-Driven Pipeline Development mit KI, Mocking externer Systeme. CI für die CI.
Eigene Pipelines mitbringen oder auf dem Beispielprojekt aufbauen. Claude Code als Pair-Programming-Partner für Refactoring und Optimierung.
Der Workshop richtet sich an DevOps- und Build-Engineers, Pipeline-Entwickler und Team Leads mit Jenkins-Praxiserfahrung und Groovy- oder Java-Grundkenntnissen, die ihre Pipeline-Entwicklung mit KI-Unterstützung systematisieren wollen.
Eine Web-Pipeline baut ein Container-Image und ist fertig. Eine Pipeline im Industrial-DevOps-Umfeld muss mehr können, und genau daran scheitern Standard-Schulungen. Vier Unterschiede, die wir im Workshop bewusst mitnehmen:
Wie das in konkreten Branchen aussieht, steht bei Automotive & Embedded und Maschinenbau & SPS.
Regulierte BranchenGeeignet für Pipelines in regulierten Industrien. Im Inhouse-Format adressieren wir ASPICE-Praktiken (SWE.4 Unit Verification, SWE.5 Integration), IEC 62304 (Medical Device Software-SDLC), ISO 26262 (Functional Safety) und MISRA-C/C++-Checks: Traceability-Patterns, signierte Artefakte, SBOM-Generierung und Toolchain-Validation in der Pipeline. Im Assessment läuft das am Ende auf eine Frage hinaus: Zu welchem Requirement gehört dieses Testergebnis? Wenn die Pipeline-Historie beim letzten Build endet, wird die Antwort zur Handarbeit. Genau diese Kette bauen wir an Ihrem eigenen Projekt auf, tiefer geht unsere Leistung DevSecOps & Compliance.
Grundkenntnisse in Jenkins und Basiskenntnisse in Groovy oder Java. Ein eigener Laptop mit Terminal-Zugang. Eigene Jenkins-Pipelines zum Mitbringen sind willkommen, KI-Vorkenntnisse brauchen Sie nicht.
AIKI verschiebt die Pipeline-Entwicklung von manuellem Groovy-Schreiben zu deklarativem Anfordern. Mit Claude Code im Terminal beschreiben Entwickler in natürlicher Sprache, was eine Pipeline tun soll. Die Generierung CPS-kompatibler Jenkinsfiles, das Refactoring von Shared Libraries und das Scaffolding von JenkinsPipelineUnit-Tests übernimmt die KI. Refactorings, die früher 4 bis 6 Stunden brauchten, gelingen in 30 bis 45 Minuten. Aus Routinearbeit wird Review-Arbeit: Sie entscheiden, die KI tippt.
Syntax recherchieren, Plugin-Optionen prüfen, 4 bis 6 h bis zum ersten grünen Build
Aus natürlicher Sprache eine CPS-kompatible Jenkinsfile generieren, in Minuten
Black-Box-Groovy, niemand traut sich an vars/ und src/
KI analysiert, dokumentiert und refactored, ohne Breaking Changes
JenkinsPipelineUnit ist sperrig, Mocking kostet einen Tag pro Funktion
Test-Skeletons mit Mocks für sh/docker/withCredentials per Prompt
So weit die Kurzfassung. Im Alltag sieht das weniger ordentlich aus: ein Serialisierungsfehler, dessen Stack-Trace über drei Bildschirme läuft, eine Library-Funktion, deren Umbenennung dreißig Jenkinsfiles bricht, ein Test, der mal grün und mal rot ist. Der nächste Abschnitt geht zehn solcher Fälle einzeln durch, jeweils mit Ursache und dem Fix, den Sie im Workshop üben.
Zehn Symptome aus dem Pipeline-Alltag, nach Häufigkeit aus unseren Kundenprojekten geordnet. Jede Zeile zeigt die Ursache und den Fix mit Claude Code, den wir im Workshop einüben. Wenn Sie eine dieser Zeilen kennen, ist der Workshop für Sie gebaut.
Pipeline-Groovy läuft durch den CPS-Transformer; Stream-Operationen, Closures auf nicht-serialisierbaren Objekten und Jenkins-API-Calls brechen den Resume-Mechanismus.
Claude Code identifiziert die kritischen Methoden, setzt @NonCPS gezielt, schlägt CPS-kompatible Alternativen vor und prüft Serialisierbarkeit gegen die Jenkins-Whitelist.
Sequenzielle Stages für Lint, Unit-Test, Integration-Test und Build kosten 40+ Minuten, obwohl sich rund 60 % davon parallelisieren lassen, ohne Race-Conditions zu produzieren.
Claude Code analysiert Stage-Abhängigkeiten, schlägt parallel-Blöcke vor, verteilt sie korrekt auf Agent-Labels und schreibt die optimierte Jenkinsfile mit unveränderter Funktionalität.
Library-Funktion umbenennen oder Signatur ändern bricht 30 Jenkinsfiles in Produktion; niemand weiß, welche Repos die Funktion in welcher Version nutzen.
Claude Code analysiert Call-Sites über Repos hinweg, generiert Deprecation-Stubs, schlägt eine semver-konforme Migrationsstrategie vor und versioniert die Library mit Git-Tags.
Ein neues Projekt braucht eine Jenkinsfile. Die Recherche zu Syntax, Plugin-Optionen und Best Practices kostet 4 bis 6 Stunden, bevor der erste Build läuft.
Claude Code generiert eine vollständige, CPS-kompatible Jenkinsfile aus natürlichsprachiger Beschreibung, inklusive timeouts, retries, parallel branches und Agent-Label-Mapping.
Tests fallen mal grün, mal rot. Niemand weiß, ob es am Test, am Test-Daten-Setup oder an der Pipeline liegt, und jedes manuelle Re-Run kostet Vertrauen in die CI.
Claude Code analysiert Build-Historie, identifiziert Tests mit unterschiedlichen Outcomes bei identischem Commit und schlägt Stabilisierungs-Patterns (retries, deterministic seeds, Mocks) vor.
Stages sollen nur auf main, nur bei changeset oder nur für tag-builds laufen. Falsche Trigger-Logik produziert ungewollte Deployments oder verpasste Releases.
Claude Code generiert when-Direktiven mit changeset/branch/buildingTag/anyOf-Kombinationen, prüft die Logik gegen typische Branch-Strategien und dokumentiert Trigger-Pfade.
Ein Monorepo mit 12 Microservices triggert bei jedem Commit alle Pipelines. Die Build-Queue ist permanent voll, Feedback-Zyklen werden träge.
Claude Code generiert eine Master-Jenkinsfile mit changeset-basierten when-Conditions pro Service-Pfad, baut Matrix-Strategien und parallelisiert nur die wirklich betroffenen Services.
Pipeline-Tests scheitern, weil sh, docker und withCredentials externe Effekte haben. Mocking ist sperrig, das Test-Setup kostet einen Tag pro Library-Funktion.
Claude Code generiert Test-Skeletons mit vollständigen Mocks für sh/docker/withCredentials, schlägt Edge-Cases vor und macht Pipelines genauso testbar wie Anwendungscode.
Eine gewachsene Scripted-Pipeline mit dynamischen Stages soll auf Declarative migriert werden. Die manuelle Konversion ist riskant, Linting fehlt, die Funktionsäquivalenz bleibt unklar.
Claude Code mappt Scripted-Konstrukte auf Declarative-Äquivalente, identifiziert die Stellen, die Scripted brauchen, und generiert eine Hybrid-Pipeline mit script-Block-Kapseln nur dort, wo nötig.
Pipeline-Fehler werden erst beim Run gefunden. Commit, Push, fünf Minuten warten, Syntax-Fehler. Pre-Commit-Lint fehlt, der jenkins-cli declarative-linter ist nicht eingebunden.
Claude Code richtet einen Lint-Job mit jenkins-cli ein, generiert Pre-Commit-Hook für lokale Checks und ergänzt eine GitHub-/GitLab-Action, die Jenkinsfile-Lints vor dem Merge erzwingt.
Quelle der Auswahl: Comquent-Pipeline-Refactorings 2024–2026, gewichtet nach Häufigkeit und Schwere des Eskalations-Risikos. Jede Zeile entspricht einem konkreten Workshop-Hands-on.
Claude Code spricht Jenkins-Groovy fließend. Anforderungen in natürlicher Sprache, heraus kommen CPS-kompatible Pipelines, Shared Libraries mit Dokumentation und passende Unit-Tests.
AIDirekt kopierbar. Jeder Prompt ist im Workshop erprobt und liefert ein versionierbares Artefakt im Repo: Jenkinsfile, Library-Funktion, Test-Skeleton, Patch-Diff. Diese zehn sind der Auszug aus dem Pipeline-Audit-Kit, das Sie unten kostenlos anfordern können.
claude "Generiere Jenkinsfile aus README.md: parallele Lint-/Unit-/Integration-Test-Stages, Docker-Build mit Layer-Caching, Deploy nur auf main mit Approval-Gate."
claude "Refactore diese Pipeline: identifiziere parallelisierbare Stages, schlage Caching-Strategie vor, behalte Funktionsäquivalenz."
claude "Scaffold Shared-Library-Funktion dockerBuild mit vars/dockerBuild.groovy, vars/dockerBuild.txt, src-Helper, JenkinsPipelineUnit-Test mit Mocks."
claude "Analysiere build.log und finde den ersten echten Fehler vor der CPS-Stack-Trace-Kaskade. Schlage einen Fix für den Pipeline-Step vor."
claude "Migriere diese Scripted Pipeline auf Declarative. Behalte alle dynamischen Stages, kapsele wo nötig in einen script-Block und erkläre die Trade-offs."
claude "Generiere CLAUDE.md aus diesem Repo: Tech-Stack, Build-Tool, Agent-Labels, Shared-Library-API, Naming-Konventionen, CPS-Regeln."
claude "Schreibe JenkinsPipelineUnit-Tests für vars/standardPipeline.groovy mit Mocks für sh, docker, withCredentials, slackSend, inklusive Edge-Cases."
claude "Ergänze when-Conditions: Stage Deploy nur bei branch=main, Stage IntegrationTest nur bei changeset auf src/, Stage Release nur bei buildingTag."
claude "Finde alle @NonCPS-Kandidaten in dieser Library: Stream-Operationen, Jenkins-API-Calls, nicht-serialisierbare Closures."
claude "Lint diese Jenkinsfile gegen Best Practices: timeouts, retries, agent-labels, parallel branches, options-Block, Notification-Strategie."
Die zehn Prompts oben sind der Auszug. Das vollständige Kit nimmt Ihre gewachsene Jenkinsfile auseinander, bevor Sie einen Workshop buchen. Sie brauchen dafür nichts als ein Terminal und Ihr Repository.
PDF · kostenlos · keine Anmeldung zum Workshop nötig
Die Reihenfolge, in der wir Claude Code in einem Jenkins-Repository einführen, vom ersten claude-Befehl bis zum wiederkehrenden Refactoring. Für ein Repository brauchen Sie etwa zwei Stunden. Schritt 1 ist der wichtigste, weil alle weiteren auf der CLAUDE.md aufsetzen.
Eine CLAUDE.md im Repo-Root: Tech-Stack, Build-Tool, Agent-Labels, Shared-Library-API, Naming-Konventionen, CPS-Regeln. Claude Code lädt diese Datei automatisch und erzeugt Pipelines, die zu Ihren Konventionen passen statt generischer Snippets.
Anforderung im Klartext: „Multi-Stage-Pipeline mit parallelem Lint- und Unit-Test, Docker-Build, Deploy nur auf main." Claude Code erzeugt eine CPS-kompatible Jenkinsfile, validiert die Syntax und schlägt fehlende Stages vor.
Claude Code analysiert vars/, src/, resources/, erzeugt Inline-Docs (vars/*.txt), identifiziert ungetestete Funktionen und schlägt Refactoring-Schritte vor, ohne Breaking Changes für laufende Jenkinsfiles.
Für jede Library-Funktion generiert Claude Code Test-Skeletons mit Mocks für sh, docker, withCredentials. Edge-Cases werden vorgeschlagen, Tests laufen ohne Jenkins-Instanz. Pipelines werden damit so testbar wie Anwendungscode.
claude "Analysiere Pipeline auf Parallelisierungspotenzial und Caching-Lücken". Claude Code findet diese Stellen, schlägt parallel-Blöcke und Caching-Strategien vor und prüft die Funktionsäquivalenz. Typische Build-Zeit-Reduktion: 20 bis 40 %.
Kurzform: Für reine Cloud-Native-Projekte ohne On-Prem-Anforderungen sind GitHub Actions Workflows oft schlanker. Sobald On-Prem, Industrial-Toolchains oder polyglotte Legacy-Builds dazu kommen, bleibt die Jenkinsfile 2026 die robusteste Wahl, vor allem wegen der Shared Libraries für DRY-Logik. gitlab-ci.yml ist die solide Mitte für Self-Managed-Teams mit GitLab als zentralem Hub.
| Kriterium | Jenkinsfile | GitHub Actions | gitlab-ci.yml |
|---|---|---|---|
| Reusable Logic / DRY | Shared Libraries (Groovy) | Reusable Workflows + Composite Actions | include: + extends: (YAML) |
| Multi-File-Strukturen | vars/, src/, resources/ | Marketplace-Action-Repo | .gitlab/ci/ + Templates |
| Pipeline-Testing | JenkinsPipelineUnit | act (lokal), keine Library-Tests | gitlab-runner exec |
| Polyglot / Legacy-Builds | Sehr stark | Container-fokussiert | Container-fokussiert |
| Industrial-Toolchains (SPS) | Beste Integration | Eingeschränkt | Eingeschränkt |
| Compliance (ASPICE, IEC 62304) | Audit-fähig (On-Prem) | Cloud-Compliance möglich | Audit-fähig (Self-Managed) |
| Parallelisierung | parallel { }-Blöcke | matrix:-Strategy | parallel:-Keyword |
| KI-Integration | Claude Code + MCP-Plugin | Copilot Workspaces | GitLab Duo |
| Refactoring-Aufwand klassisch | Hoch (Groovy + CPS) | Mittel | Niedrig (YAML) |
| Refactoring-Aufwand mit KI | Niedrig (Claude Code) | Niedrig | Niedrig |
On-Prem-Pflicht, Industrial-Toolchains (SPS, Embedded, Firmware), Multi-VCS, regulierte Releases (ASPICE, IEC 62304) und Sie Shared Libraries für DRY-Logik über dutzende Repos brauchen.
GitHub als zentrales VCS, Cloud-Native-Stack, kleine bis mittlere Teams, geringe Compliance-Anforderungen und der Marketplace-Workflow Ihre primäre Quelle der Wahrheit ist.
GitLab als zentrale DevOps-Plattform, Self-Managed mit Compliance-Bedarf, integrierte SAST/DAST-Pipelines und ein Single-Tool-Ansatz erwünscht ist.
Stand: September 2026 · Bewertung aus Beratungssicht für Industrial-DevOps-Umgebungen · Wir beraten herstellerunabhängig im Erstgespräch. Falls die Jenkinsfile nicht das richtige Werkzeug für Sie ist, sagen wir das.
Was soll Ihre Pipeline zuerst können?
Eine Pipeline für Embedded-Builds sieht anders aus als eine für Container, und wieder anders, wenn am Ende ein Auditor auf die Nachweise schaut. Zwei Klicks zeigen, wo bei Ihnen der Einstieg liegt und was Sie aus dem Workshop mitnehmen.
Was soll die Pipeline zuerst können?
Ein vollständiges Pipeline-Projekt mit Shared Library, Tests, Templates und einer CLAUDE.md, die Claude Code den vollen Projektkontext gibt.
Das Herzstück: die CLAUDE.md dokumentiert Konventionen, Tech-Stack und häufige Aufgaben. Die KI generiert Code, der sofort zum Projekt passt.
jenkins-pipeline-workshop/ ├── Jenkinsfile ├── Jenkinsfile.scripted ├── jenkins/ │ ├── stages/ │ │ ├── build.groovy │ │ ├── test.groovy │ │ ├── deploy.groovy │ │ └── notify.groovy │ ├── config/ │ │ ├── environments.yaml │ │ └── agents.yaml │ └── scripts/ │ ├── docker-build.sh │ └── run-tests.sh ├── shared-library/ │ ├── vars/ │ │ ├── standardPipeline.groovy │ │ ├── dockerBuild.groovy │ │ └── notifyTeams.groovy │ ├── src/de/comquent/pipeline/ │ │ ├── Config.groovy │ │ ├── Docker.groovy │ │ └── Utils.groovy │ ├── resources/templates/ │ └── test/groovy/ │ ├── StandardPipelineTest.groovy │ ├── DockerBuildTest.groovy │ └── NotifyTeamsTest.groovy ├── CLAUDE.md └── docker-compose.yml
Drei davon liegen als Code im Repository, das Sie am Ende des zweiten Tages klonen. Das vierte ist Routine: Sie wissen, welche Aufgabe Sie Claude Code geben und welche Antwort Sie besser prüfen, bevor sie in die Jenkinsfile geht.
Bewährte Patterns für reale Projekte: Parallelisierung, Conditional Stages, Matrix-Builds.
Eine dokumentierte, getestete Shared Library als Startvorlage für Ihre Projekte.
Getestete Strategien für schnellere Builds, besseres Caching und effiziente Ressourcen.
Die Fähigkeit, Claude Code als Entwicklungspartner für Jenkins im Alltag einzusetzen.
Wir schreiben Jenkinsfiles nicht für Workshop-Demos. Wir entwickeln, refactoren und testen Pipelines seit 2006 in echten Kundenprojekten von Automotive bis Maschinenbau.
Keine Marketing-Demos. Keine Folienparaden. Sondern Trainer, die am Montag wieder als Consultants im Kundenprojekt sitzen.
Gegründet 2006 in Puchheim bei München. Spezialisiert auf die IT/OT-Brücke, von der Bürosoftware bis zum Steuerungsgerät auf der Werkbank. Jenkins ist seit der ersten Stunde unser Werkzeug.
Jede Übung stammt aus einer realen Kundensituation: CPS-Fallstricke in gewachsenen Libraries, Multi-Branch-Strategien für Monorepos, Pipeline-Performance für Firmware-Builds. Sie lernen Patterns, die in Industrieprojekten wirklich tragen.
Wir nutzen Claude Code nicht erst seit gestern für Workshop-Demos. Die Prompts, CLAUDE.md-Strukturen und Skills, die Sie üben, sind dieselben, die in unseren laufenden Beratungsmandaten entstehen.
Unabhängig von Plugin-Anbietern, Cloud-Plattformen oder Vendor-Lock-in. Schulungssprache Deutsch, Unterlagen auf Deutsch, Rechnung aus Deutschland, geeignet auch für regulierte Branchen und öffentliche Auftraggeber.
Wenn die Pipeline am Ende ein Container-Image nach Kubernetes bringen soll, hört die Arbeit nicht beim Push ins Registry auf. Der ArgoCD & GitOps-Workshop mit Claude Code setzt genau dort an: Aus dem Build-Artefakt wird ein Commit im Deployment-Repo, den ArgoCD ausrollt. Ein Hot-Fix am Repository vorbei fällt dann als Drift sofort auf.
Installation, Security und Monitoring als Ergänzung. Vier Tage zusammen mit Preisvorteil.
Pipeline-Artefakte per ArgoCD ausrollen. Der nächste Schritt, wenn das Image nach Kubernetes soll.
Auf Ihre Pipelines und Shared Libraries zugeschnitten, ab 4 Teilnehmern.
Platz sichern.
12 Plätze pro Termin.
Diese Fragen stellen uns Pipeline-Verantwortliche vor der Anmeldung am häufigsten. Die ersten drei klären die Jenkins-Grundlagen, auf denen der Workshop aufbaut. Danach geht es um die Arbeit mit Claude Code, am Ende um Pipelines in regulierten Branchen. Wer nur einen Block braucht, springt direkt dorthin.
// A · Jenkins-Grundlagen
Eine Jenkins Shared Library ist ein versioniertes Git-Repository mit wiederverwendbarem Pipeline-Code, das beliebig viele Jenkinsfiles per @Library-Direktive einbinden. Die Struktur: vars/ für globale Pipeline-Steps, src/ für Groovy-Klassen, resources/ für statische Dateien. Mit ihr verschwindet Copy-Paste aus den Pipelines, und die Logik bleibt DRY.
Mit Claude Code wird aus der Library-Arbeit Review-Arbeit: bestehende Libraries reverse-engineeren und dokumentieren (vars/*.txt), neue Funktionen samt JenkinsPipelineUnit-Tests scaffolden, Signaturänderungen über alle Call-Sites hinweg versionieren, ohne Breaking Changes für laufende Jenkinsfiles. Im Workshop nehmen Sie eine vollständige, getestete und dokumentierte Shared Library als Startvorlage mit.
Docker hat in einer Jenkins-Pipeline zwei Rollen: als Build-Umgebung über agent { docker { image '...' } } in der Jenkinsfile und als Build-Artefakt, wenn eine Stage das Image baut, taggt und ins Registry pusht. Der Docker-Agent beendet das klassische „läuft nur auf Agent 3“-Problem: Jeder Build startet im selben Container, die Toolchain ist versioniert statt von Hand auf dem Agent installiert. In Industrial-DevOps-Umgebungen ist das der übliche erste Schritt zu reproduzierbaren Builds, gerade wenn Embedded-Compiler oder SPS-Toolchains im Spiel sind.
Im Workshop arbeiten Sie mit der Shared-Library-Funktion dockerBuild aus dem Praxisprojekt: Multi-Stage-Build mit Layer-Caching, JenkinsPipelineUnit-Tests mit Docker-Mocks, generiert und refactored mit Claude Code. Soll das Image danach deklarativ nach Kubernetes, ist der ArgoCD- & GitOps-Workshop der passende nächste Schritt; wie Software-Teams diese Kette produktiv betreiben, zeigt der Anwendungsfall IT-Unternehmen.
Jenkins ist 2026 weiter eine der meistgenutzten CI/CD-Plattformen, und KI verschiebt genau das, was lange als Schwäche galt. Der häufigste Kritikpunkt ist die Komplexität von Groovy, CPS und gewachsenen Shared Libraries. Mit Claude Code wird daraus beherrschbares Pair-Programming: CPS-kompatible Generierung, Refactoring und Testing übernimmt die KI. Was Jenkins von Cloud-nativen YAML-Tools abhebt, bleibt sein Vorteil: maximale Flexibilität, On-Prem-Betrieb, Audit-Fähigkeit und die Integration polyglotter wie industrieller Toolchains (SPS, Embedded).
Hinzu kommt das offizielle MCP-Server-Plugin, mit dem Jenkins Build-Status und Logs direkt an KI-Assistenten gibt. Für regulierte Industrien mit On-Prem-Anforderungen ist Jenkins damit 2026 die robustere Wahl. Wir beraten im Erstgespräch herstellerunabhängig. Den direkten Vergleich zu GitHub Actions und GitLab CI finden Sie in der Tabelle in Abschnitt 09 und ausführlicher im Admin-Workshop.
// B · KI in der Pipeline-Arbeit
Drei Schritte: Projekt-Kontext in einer CLAUDE.md ablegen (Tech-Stack, Build-Tool, Agent-Labels, Shared-Library-API), Anforderung in natürlicher Sprache beschreiben („Multi-Stage-Pipeline mit parallelem Test- und Lint-Stage, Docker-Build, deploy nur auf main“), Output prüfen und committen. Claude Code generiert dabei CPS-kompatiblen Groovy-Code, der zu Ihren Konventionen passt, statt generischer Snippets aus dem Internet.
Im Workshop bauen Sie eine eigene CLAUDE.md auf und üben das Pattern an einem realen Pipeline-Refactoring.
Eine CLAUDE.md ist eine Markdown-Datei im Projekt-Root, die Claude Code beim Start automatisch einliest. Für Jenkins-Projekte dokumentiert sie den Tech-Stack, Build-Tools, Agent-Label-Konventionen, Shared-Library-API, Naming-Patterns und typische Aufgaben, also das, was sonst implizit im Kopf eines Senior-Engineers steckt.
Effekt: Generierter Code passt sofort. Statt einer generischen Pipeline bekommen Sie eine, die Ihre @Library('company-shared@v2') korrekt einbindet, Ihre Agent-Labels nutzt und CPS-kompatibel ist. Das Praxisprojekt enthält eine vollständige CLAUDE.md als Template zum Mitnehmen.
JenkinsPipelineUnit simuliert den Pipeline-Runner ohne laufende Jenkins-Instanz und erlaubt Mocks für sh, docker, withCredentials und Library-Funktionen. Claude Code übernimmt das Aufwendige: Test-Skeletons aus existierender Library-Funktion ableiten, Mocks für externe Aufrufe generieren, Edge-Cases vorschlagen.
Ergebnis: Pipelines werden so testbar wie Anwendungscode. Im Workshop bauen Sie eine vollständige Teststrategie für eine Shared Library mit vars/, src/, resources/ sowie CI für die CI.
Drei Ansatzpunkte: Parallelisierung sequentieller Stages, Caching-Strategien (Docker-Layer, Maven/Gradle, npm) und das Erkennen redundanter Checks (z. B. Lint & Format zweimal). Claude Code analysiert eine bestehende Jenkinsfile, findet diese Stellen und erzeugt die optimierte Version mit unveränderter Funktionalität, inklusive der nötigen parallel-Blöcke und Agent-Label-Anpassungen.
Quelle: Comquent-Workshop-Telemetrie 2024–2026 · n = 47+ Pipeline-Refactorings · Vergleich vor/nach Claude-Code-Einsatz · individuelle Einsparung variiert nach Pipeline-Komplexität, Caching-Setup und Build-Tool
Annahme: ein DevOps/Build-Engineer mit 100 €/h voll belastetem Stundensatz, ~3 Pipeline-Refactorings pro Woche (je 4 bis 6 h ohne KI, 30 bis 45 min mit Claude Code). Konservativ gerechnet, viele Teams liegen höher, vor allem bei gewachsenen Shared Libraries.
3 × 4,4 h × 100 € × 52 Wochen pro Engineer und Jahr.
Bei ~70 % Zeitersparnis aus den Stat-Strip-Werten oben, ≈ 16.016 € Einsparung pro Engineer und Jahr.
Quellenlage: Eigene Workshop-Telemetrie (n = 47+ Pipeline-Refactorings). Externer Sekundärbeleg: Stack Overflow Developer Survey 2024 (81 % der Befragten nennen höhere Produktivität als größten Nutzen von KI-Tools) sowie GitHub-Copilot-Studie 2022 (55 % schnellere Aufgaben-Completion). Konservative Annahme im Modell: 70 %.
Fünf typische Pipeline-Aufgaben: (1) eine bestehende Pipeline auf Parallelisierungspotenzial analysieren und refaktorieren, (2) eine neue Shared-Library-Funktion mit Inline-Doku und Unit-Test scaffolden, (3) Multi-Branch-Trigger mit when-Conditions ergänzen, (4) ein Build-Log nach einem fehlerhaften Run analysieren und Root Cause finden, (5) eine Jenkinsfile gegen ein Set Best-Practice-Regeln prüfen.
Genau dieser Stundenausschnitt steht im Workshop als Live-Demo am Tag 2, anschließend wenden Sie das Pattern auf Ihre eigene Pipeline an.
Vibe Coding, also KI-Code aus Prompt-Improvisation, funktioniert für Prototypen, scheitert aber für Production-Pipelines, sobald Audit-Trail, CPS-Regeln und Shared-Library-API mitspielen. Spec-Driven Development dreht den Spieß um: erst die Spec (Was, Warum, Constraints), dann der Code. Genau diese Rolle übernimmt die CLAUDE.md im Workshop: Sie ist die ausführbare Spec für Ihren Pipeline-Code.
Effekt: Die KI generiert nicht mehr generische Snippets, sondern Pipelines, die zu Ihrer Library-API, Ihren Agent-Labels und Ihren CPS-Regeln passen. Claude Skills, wiederverwendbare Workflow-Specs, automatisieren wiederkehrende Aufgaben (Linting, Library-Scaffolding, Test-Generierung). Beides ist im Workshop direkt am Praxisprojekt.
Das Model Context Protocol (MCP) ist ein 2024 von Anthropic eingeführter offener Standard, mit dem KI-Modelle sicher und einheitlich auf externe Tools zugreifen. Das offizielle MCP-Server-Plugin für Jenkins (Version 0.209, veröffentlicht am 24.09.2026, Jenkins-Core ab 2.541.3) macht Jenkins zum MCP-Endpunkt: Build-Status, Logs, Job-Konfigurationen und Pipeline-Stages werden Claude Code als Tools angeboten, ohne dass Sie selbst REST-Aufrufe schreiben.
Für die Pipeline-Entwicklung heißt das: Während Sie an einer Jenkinsfile arbeiten, kann Claude Code live prüfen, ob der zuletzt gepushte Branch grün ist, welche Stages länger gebraucht haben oder welche Tests intermittierend rot sind, und das direkt in den Refactoring-Vorschlag einarbeiten. Im Workshop richten wir den MCP-Server gegen eine Übungs-Jenkins-Instanz ein.
Zwei Richtungen, zwei offizielle Plugins. Das AI-Agent-Plugin (Version 162, Jenkins-Core ab 2.528.3) führt Claude Code als Build-Step innerhalb eines Jenkins-Jobs aus, in der Jenkinsfile als claudeCode()-Step, mit Konversations-Log und Freigabe-Gates je Lauf. Das MCP-Server-Plugin (Version 0.209) dreht die Richtung um: Claude Code auf Ihrem Rechner liest Build-Status, Logs und Stage-Zeiten aus Jenkins, während Sie an der Pipeline arbeiten.
In der Praxis ergänzen sich beide: MCP beim Entwickeln und Debuggen, der Agent-Step für wiederkehrende Aufgaben im Build, etwa Changelog-Entwürfe oder die Erstdiagnose eines roten Stages, bevor ein Mensch freigibt. Wer den Agent-Step einsetzt, braucht eine Antwort auf die Freigabefrage: Welche Aktionen darf Claude Code ohne Gate ausführen, welche nicht? Im Workshop richten Sie beides gegen die Übungs-Instanz ein und legen die Gates an Ihren Freigabeprozessen fest.
// C · Regulierte Industrie
ASPICE SWE.4 verlangt nachvollziehbare Unit-Verification samt Coverage-Nachweis und vollständiger Traceability vom Requirement zum Test. Im Workshop bauen wir das in der Jenkinsfile auf: Coverage-Stages mit gcovr/JaCoCo, automatisierte Trace-Reports aus Test-IDs und Stage-Logs, signierte Build-Artefakte und Toolchain-Validation als versionierter Pipeline-Code. Claude Code generiert die Stage-Templates samt Audit-Anhang.
Inhouse-Format empfohlen: Wir mappen die Pipeline-Stages direkt auf ASPICE-Base-Practices (SWE.4 BP1–BP6) und liefern eine Audit-Checkliste, die Sie mit Ihrem ASPICE-Assessor durchgehen können.
IEC 62304 verlangt für Software-Lifecycle-Prozesse in Medizinprodukten dokumentierte Tool-Validation, Konfigurations-Management und Risk-Management, auch für KI-Assistenten, die Pipeline-Code erzeugen. Im Workshop adressieren wir das so: Jeder Claude-Code-Prompt erzeugt einen Git-Commit, jede generierte Jenkinsfile durchläuft Code-Review und JenkinsPipelineUnit-Tests, der KI-Output ist damit vollständig prüfbar, anders als eine Antwort im Chatfenster.
Claude Code generiert zusätzlich die Validation-Dokumente: Tool-Validation-Plan, Test-Reports, Hazard-Analysis-Mapping, direkt aus dem Repo, versioniert und reproduzierbar.
MISRA-C/C++ und ISO 26262 (Functional Safety im Automotive) fordern Static-Analysis-Gates, dokumentierte Tool-Confidence-Levels (TCL) und Audit-Trails für sicherheitsrelevante Build-Schritte. Im Workshop bauen wir Stages für PC-lint Plus, Polyspace, Coverity oder cppcheck. Claude Code generiert die Stage-Templates, die Findings-Aggregation und die Quality-Gates passend zum geforderten ASIL-Level. Jede Pipeline-Änderung ist ein versionierter Git-Commit mit Code-Review.
Diese Patterns sind übertragbar auf DevSecOps und Automotive & Embedded. Wir vermitteln sie im Inhouse-Format passend zu Ihrer Toolchain. Wie KI Jenkins darüber hinaus per MCP steuert und Build-Logs analysiert, zeigt unser Beitrag Vibe Coding & MCP für Jenkins.
Kurzform: Für Pipeline- und Shared-Library-Arbeit mit Multi-File-Refactoring führt Claude Code (oder Cursor mit Anthropic-Modell). ChatGPT eignet sich für Snippet-Erklärungen und Konzeptfragen. Copilot glänzt im IDE-Inline-Autocomplete, ist aber für ganze Pipeline-Refactorings zu schmalbandig.
| Kriterium | Claude Code | ChatGPT | GitHub Copilot | Cursor |
|---|---|---|---|---|
| Einsatzort | Terminal | Browser/Chat | IDE-Inline | Eigene IDE |
| Multi-File-Refactoring | Sehr gut | Manuell paste | Begrenzt | Sehr gut |
| Jenkinsfile aus Beschreibung | Direkt im Repo | Snippet-Output | Inline-Vorschlag | Direkt im Repo |
| Shared-Library scaffolden | vars/, src/, test/ in einem Schritt | Manuell | Datei-für-Datei | Mehrere Dateien |
| CPS-Kompatibilität (Groovy) | Sehr gut | Gut | Mittel | Gut |
| JenkinsPipelineUnit-Tests | Tests + Mocks generiert | Snippets | Wenig spezialisiert | Tests + Mocks |
| Projekt-Kontext aus dem Repo | CLAUDE.md, automatisch | Nein | copilot-instructions.md | .cursor/rules, AGENTS.md |
| Audit-Trail via Git | Sehr gut | Schlecht | Mittel | Gut |
| Datenresidenz (DACH) | Anthropic-Enterprise möglich | OpenAI-Enterprise | Microsoft-Cloud | Mehrere Modelle |
Stand: September 2026 · Vergleich aus Sicht der Pipeline-Entwicklung · Tools entwickeln sich schnell weiter, daher fokussieren wir im Workshop auf Patterns, nicht auf einzelne Vendor-Features.
Grundkenntnisse in Jenkins und Basiskenntnisse in Groovy oder Java. Sie sollten bereits Jenkinsfiles gesehen und einfache Pipelines ausgeführt haben. Geeignet auch für erfahrene Pipeline-Entwickler, die mit KI noch produktiver werden wollen. KI-Vorkenntnisse sind nicht erforderlich.
Mit Jenkins-Grundkenntnissen und Basiswissen in Groovy oder Java: ja. Dieser Workshop ist genau darauf ausgelegt: 2 Tage Hands-on zu Declarative- und Scripted-Pipelines, Shared Libraries, Pipeline-Testing und Performance, verstärkt durch Claude Code als KI-Pair-Programming-Partner. Wer Jenkins-Grundlagen erst aufbauen will, startet idealerweise mit einer Grundlagen-Schulung der Comquent Academy und vertieft anschließend hier die Pipeline-Entwicklung mit KI.
Der offene Workshop kostet 1.690 € netto pro Teilnehmer (zzgl. 19 % USt.), inklusive Schulungsumgebung, vollständigem Praxisprojekt (Declarative- & Scripted-Pipeline, Shared Library mit vars/, src/, resources/, JenkinsPipelineUnit-Tests, CLAUDE.md-Template) und Teilnahmebestätigung. Inhouse-Workshops für Teams ab 4 Teilnehmern werden auf Ihre bestehenden Pipelines und Shared Libraries zugeschnitten, Tagessatz auf Anfrage. Der Preis liegt 35 bis 55 % über generischen Jenkins-Kursen, weil Claude Code durchgehend im Pair-Programming mitläuft, nicht als Demo am Rand.
Ja, sowohl vor Ort in Puchheim bei München als auch remote per Videokonferenz. Bei Remote-Workshops stellen wir vorbereitete Cloud-Umgebungen bereit.
Ja, Inhouse-Workshops werden auf Ihre bestehenden Pipelines, Shared Libraries und konkreten Herausforderungen zugeschnitten. Ideal ab 4 Teilnehmern.
Ja, ausdrücklich erwünscht. Am Nachmittag des zweiten Tages arbeiten Sie wahlweise an Ihrer eigenen Pipeline oder am Beispielprojekt weiter. Gerade gewachsene Libraries lohnen sich: Claude Code liest sie ein, dokumentiert die Funktionen und schlägt Refactorings vor, und Sie prüfen die Vorschläge mit einem Trainer daneben.
Sie nehmen das komplette Beispielprojekt inklusive aller Pipelines, Shared Libraries und Tests mit. Plus ein Best-Practices-Cheat-Sheet als Referenz für den Alltag.
Dieser Workshop fokussiert auf Pipeline-Entwicklung: Declarative und Scripted Pipelines, Shared Libraries, Testing und Performance-Optimierung. Der Admin-Workshop konzentriert sich auf Installation, Konfiguration, Security und Monitoring. Beide ergänzen sich ideal.
Ja, darauf ist er zugeschnitten. Industrie-Pipelines unterscheiden sich in vier Punkten von Web-Pipelines: Cross-Compiler und Lizenzserver binden Builds an bestimmte Agents, Prüfstände und HiL-Stages sind exklusive Ressourcen und begrenzen die Parallelisierung, Produktlebenszyklen von 15 Jahren verlangen reproduzierbare Builds alter Stände, und Freigaben müssen als Nachweis aus der Pipeline fallen statt von Hand zu entstehen. Diese Punkte üben wir am Praxisprojekt, im Inhouse-Format an Ihrer eigenen Toolchain.
Ja, das Pipeline-Audit-Kit. Es enthält 25 Claude-Code-Prompts in fünf Gruppen, eine ausfüllbare CLAUDE.md-Vorlage für Jenkins-Projekte, einen Audit-Bogen mit 12 Prüfpunkten und ein Bewertungsraster für den Aufwand. Damit nehmen Sie Ihre gewachsene Jenkinsfile in etwa einer Stunde selbst auseinander. Der Download ist kostenlos und an keine Anmeldung zum Workshop gebunden.
Claude Code läuft direkt im Terminal. Sie beschreiben Anforderungen in natürlicher Sprache, Claude Code generiert, analysiert oder refactored Code direkt in Ihrem Projekt.
Die ersten Refactorings gelingen am ersten Workshop-Tag nach zwei bis drei Stunden, sobald eine CLAUDE.md den Projektkontext liefert. In unseren Workshop-Refactorings sank der Aufwand für ein typisches Pipeline-Refactoring von 4 bis 6 Stunden auf 30 bis 45 Minuten, für die Dokumentation einer Shared Library von 2 bis 3 Stunden auf eine Viertelstunde. Der Zeitgewinn kommt weniger vom Tippen als davon, dass Claude Code CPS-kompatiblen Code nach Ihren Konventionen erzeugt und Sie ihn nur noch prüfen. Voraussetzung sind Grundkenntnisse in Jenkins und Groovy oder Java, KI-Vorkenntnisse brauchen Sie nicht.
Declarative Pipelines nutzen eine strukturierte, opinionated Syntax mit pipeline/stages/steps-Blöcken, ideal für 80 % der Anwendungsfälle, Linting-fähig und leicht lesbar. Scripted Pipelines sind vollwertiger Groovy-Code mit maximaler Flexibilität, nötig für dynamische Stage-Generierung, komplexe Schleifen oder bedingte Pipeline-Strukturen. Im Workshop schreiben Sie beide Varianten und stellen sie am selben Projekt gegenüber.
Jenkins führt Pipeline-Groovy durch den Continuation Passing Style (CPS) Transformer, damit Pipelines nach einem Controller-Neustart an der letzten Stage fortgesetzt werden können. Das erzwingt Serialisierbarkeit und verbietet bestimmte Groovy-Features in regulären Pipeline-Steps. Mit der @NonCPS-Annotation werden einzelne Methoden aus der CPS-Transformation ausgenommen, etwa für Stream-Operationen oder Jenkins-API-Aufrufe.
JenkinsPipelineUnit ist ein Open-Source-Framework zum Unit-Testing von Jenkins-Pipelines und Shared Libraries ohne laufende Jenkins-Instanz. Es simuliert den Pipeline-Runner, erlaubt Mocks für sh, docker, withCredentials und Shared-Library-Funktionen. Damit werden Pipelines genauso testbar wie Anwendungscode. Im Workshop bauen Sie eine komplette Teststrategie auf.
Ja, zentrales Modul. JenkinsPipelineUnit, Tests für Shared Libraries und Pipelines, Mocks für sh, docker und withCredentials, eine vollständige Teststrategie, alles KI-gestützt.
Beides. Jenkins startete als Continuous-Integration-Server, deckt mit Pipelines aber den kompletten Weg von Build und Test bis zum Deployment ab, also auch Continuous Delivery. In der Jenkinsfile stehen CI-Stages (Build, Test, Lint) und CD-Stages (Deploy, Freigabe-Gates) im selben versionierten Pipeline-Code. Genau diese Kette bauen Sie im Workshop am Praxisprojekt auf.
Jenkins-Pipelines sind über Shared Libraries (Groovy, vars/, src/) extrem wiederverwendbar. Pipeline-Logik wird einmal geschrieben und in dutzenden Repos versioniert eingebunden. GitHub Actions skaliert über Reusable Workflows und Composite Actions, ist aber an die GitHub-Plattform gekoppelt. Mit Claude Code lassen sich beide Welten KI-unterstützt entwickeln. Für regulierte Industrien mit On-Prem-Anforderungen, komplexen Agent-Topologien und Multi-Tool-Stacks bleibt Jenkins 2026 die robustere Wahl. Wir beraten im Erstgespräch herstellerunabhängig.
Welches Format passt bei der Pipeline-Entwicklung besser zu Ihrem Team?
Den Workshop gibt es als offenen Termin und als Inhouse-Format im eigenen Team. Sagen Sie uns mit einem Klick, was für Sie näher liegt — den passenden Weg zeigen wir direkt danach.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
