Aus Jenkinsfile-Pflege wird Pipeline-Engineering. In 2 Tagen entwickeln Sie Jenkins-Pipelines systematisch — Declarative und Scripted, Shared Libraries, Pipeline-Testing, Parallelisierung — mit Claude Code 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. Ab 1.690 € netto pro Teilnehmer.
Pipelines wachsen, Shared Libraries werden unübersichtlich, Debugging kostet Stunden. Niemand traut sich mehr, die zentrale Jenkinsfile anzufassen.
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.
Ist 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.
Kein Folienschlacht. Kein
Buzzword-Bingo. Echter Code.
Tag 1 deckt Pipeline-Grundlagen, Claude-Skills für Jenkins, Shared-Library-Architektur (vars/, src/, resources/) und ein vollständiges Praxisprojekt ab. Tag 2 fokussiert auf Pipeline-Optimierung, komplexe Patterns (Multi-Branch, Monorepo, Matrix-Builds), Pipeline-Testing mit JenkinsPipelineUnit und ein eigenes Refactoring-Projekt — Claude Code als Pair-Programming-Partner durchgängig.
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. KI-Vorkenntnisse sind nicht erforderlich.
VoraussetzungenGrundkenntnisse in Jenkins und Basiskenntnisse in Groovy oder Java. Eigener Laptop mit Terminal-Zugang. Eigene Jenkins-Pipelines zum Mitbringen sind willkommen. KI-Vorkenntnisse sind nicht erforderlich.
Regulierte BranchenGeeignet für Pipelines in regulierten Industrien — wir adressieren ASPICE-Praktiken (SWE.4 Unit Verification, SWE.5 Integration), IEC 62304 (Medical Device Software-SDLC), ISO 26262 (Functional Safety) und MISRA-C/C++-Checks direkt im Inhouse-Format: 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 die Kette bauen wir im Workshop an Ihrem eigenen Projekt auf.
KI 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–6 Stunden brauchten, gelingen in 30–45 Minuten. Das ist der Gamechanger: aus Routinearbeit wird Review-Arbeit — Sie entscheiden, die KI tippt.
Syntax recherchieren, Plugin-Optionen prüfen, 4–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
Jenkins-Pipeline-Entwicklung scheitert in der Praxis an vier Stellen: CPS-Transformationen mit kryptischen Serialisierungsfehlern, gewachsenen Shared Libraries ohne Dokumentation, langsamen Feedback-Zyklen über Commit→Run→Fehler und fehlender Pipeline-Testbarkeit. Claude Code adressiert alle vier mit konkreten, CPS-kompatiblen Code-Generierungen.
CPS-Transformationen und Serialisierungsfehler
Kryptische Fehler, stundenlange Suche nach @NonCPS-Stellen
KI generiert CPS-kompatiblen Code und erklärt, warum @NonCPS nötig ist
Declarative vs. Scripted Pipeline
Falsche Syntax vermischt, Features am falschen Ort
KI wählt den richtigen Pipeline-Typ und generiert korrekte Syntax
Gewachsene Libraries sind Black Boxes
Undokumentierte Abhängigkeiten, niemand traut sich Änderungen zu
KI analysiert Library-Strukturen, dokumentiert Funktionen und schlägt Refactoring vor
Neue Library-Funktionen entwickeln
Stunden für vars/, src/, Dokumentation und Tests
KI generiert komplette Library-Funktionen mit Docs und Unit-Tests
Jede Änderung braucht Commit + Pipeline-Run
Feedback-Zyklen von 10–30 Minuten pro Iteration
KI generiert syntaktisch korrekte Pipelines und erkennt Fehler vorab
Builds dauern zu lange
Sequentielle Stages, kein Caching, verschwendete Ressourcen
KI identifiziert Parallelisierungspotenzial und optimiert Pipeline-Struktur
Pipelines werden nicht getestet
JenkinsPipelineUnit ist sperrig, Mocking aufwendig
KI generiert Tests, erstellt Mocks und baut eine Teststrategie auf
Multi-Branch, Monorepo, Conditional Stages
Komplexe when-Conditions, fehlerhafte Trigger-Logik
KI generiert when-Conditions, changeset-Trigger und Matrix-Builds
Zehn Symptome aus dem Pipeline-Alltag — direkt 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 60 % parallelisierbar sind, 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 — Recherche zu Syntax, Plugin-Optionen und Best Practices kostet 4–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; manuelles 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 — 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, 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 — manuelle Konversion ist riskant, Linting fehlt, Funktionsäquivalenz 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, 5 Minuten warten, Syntax-Fehler. Pre-Commit-Lint fehlt; 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 — CPS-kompatible Pipelines, Shared Libraries mit Dokumentation, passende Unit-Tests.
Direkt kopierbar. Jeder Prompt ist im Workshop erprobt und liefert ein versionierbares Artefakt im Repo — Jenkinsfile, Library-Funktion, Test-Skeleton, Patch-Diff. Diese 10 Prompts sind der Kern unseres Cheat-Sheets, das jeder Teilnehmer als Referenz mitnimmt.
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 Fix für den Pipeline-Step vor."
claude "Migriere diese Scripted Pipeline auf Declarative — behalte alle dynamischen Stages, kapsele wo nötig in script-Block, 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."
25 Claude-Code-Prompts für Pipeline-Entwicklung — als PDF mit Output-Beispielen, CPS-Hinweisen und Refactoring-Patterns. Kostenlos für Workshop-Teilnehmer, gegen Kontaktdaten als Lead-Magnet.
Eine reproduzierbare Routine — vom ersten claude-Befehl bis zum dauerhaften Refactoring-Loop. Dauer: ca. 2 Stunden, danach läuft die KI-gestützte Pipeline-Arbeit als Standard-Workflow.
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 — keine generischen 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 so testbar wie Anwendungscode.
claude "Analysiere Pipeline auf Parallelisierungspotenzial und Caching-Lücken". Claude Code identifiziert die Hebel, schlägt parallel-Blöcke und Caching-Strategien vor und prüft Funktionsäquivalenz — typische Build-Zeit-Reduktion 20–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 mit 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: Mai 2026 · Bewertung aus Beratungssicht für Industrial-DevOps-Umgebungen · Wir beraten herstellerunabhängig im Erstgespräch — falls 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
Sie verlassen den Workshop mit praxiserprobten Pipeline-Patterns für Parallelisierung und Conditional Stages, einer dokumentierten und getesteten Shared Library als Startvorlage, konkreten Optimierungsstrategien für Build-Performance — und der Routine, Claude Code als täglichen Pair-Programming-Partner für Jenkins-Aufgaben einzusetzen.
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 — und ein Hot-Fix am Repository vorbei fällt als Drift sofort auf.
Installation, Security & Monitoring — die ideale Ergänzung. Vier Tage zusammen mit Preisvorteil.
Pipeline-Artefakte via ArgoCD ausrollen — der natürliche nächste Schritt nach Pipeline-Mastery.
Auf Ihre Pipelines und Shared Libraries zugeschnitten — ab 4 Teilnehmern.
Die Fragen, die uns Pipeline-Verantwortliche vor der Anmeldung am häufigsten stellen — kompakt beantwortet, damit Sie wissen, wo der Workshop bei Ihnen wirkt: in der Jenkinsfile-Generierung, im Shared-Library-Refactoring, im Pipeline-Testing, in der Tool-Auswahl und bei der Frage, ob Jenkins 2026 noch die richtige Plattform ist.
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 — keine generischen Snippets aus dem Internet.
Im Workshop bauen Sie eine eigene CLAUDE.md auf und üben das Pattern an einem realen Pipeline-Refactoring.
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/ — inklusive CI für die CI.
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.
Drei Hebel: 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, identifiziert die Hebel 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–6 h ohne KI, 30–45 min mit Claude Code). Konservativ — 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 (KI-Tools beschleunigen Routineaufgaben um Median 25–55 %) 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 — 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.196, Jenkins-Core ab 2.541.3, Stand 14.08.2026) macht Jenkins zum MCP-Endpunkt: Build-Status, Logs, Job-Konfigurationen, 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 (seit 14.08.2026, 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 (0.196) 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.
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 inkl. 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 Chat-basierte Antworten.
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.
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. Sie ist der zentrale Hebel, um Copy-Paste in Pipelines zu eliminieren und Pipeline-Logik DRY zu halten.
Mit Claude Code wird die Library-Arbeit zum Gamechanger: 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 Integration polyglotter sowie industrieller Toolchains (SPS, Embedded).
Hinzu kommt das offizielle MCP-Server-Plugin (2026), das Jenkins zum nativen Endpunkt für KI-Assistenten macht. Für regulierte Industrien mit On-Prem-Anforderungen ist Jenkins damit 2026 die robustere Wahl — wir beraten im Erstgespräch herstellerunabhängig und zeigen den direkten Vergleich zu GitHub Actions und GitLab CI im Admin-Workshop sowie in der Tool-Tabelle unten.
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 |
| Eigener Projekt-Kontext (CLAUDE.md) | Ja, automatisch | Nein | Nein | Begrenzt |
| Audit-Trail via Git | Sehr gut | Schlecht | Mittel | Gut |
| Datenresidenz (DACH) | Anthropic-Enterprise möglich | OpenAI-Enterprise | Microsoft-Cloud | Mehrere Modelle |
Stand: April 2026 · Vergleich aus Sicht der Pipeline-Entwicklung · Tools entwickeln sich schnell weiter, daher fokussieren wir im Workshop auf Patterns, nicht auf einzelne Vendor-Features.
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.
