Was ist eine Jenkins Shared Library?
Eine Jenkins Shared Library ist ein versioniertes Git-Repository mit wiederverwendbarem Pipeline-Code (vars/, src/, resources/), das von beliebig vielen Jenkinsfiles per @Library-Direktive eingebunden werden kann. Sie ist der zentrale Hebel, um Copy-Paste in Pipelines zu eliminieren und Pipeline-Logik DRY zu halten. Mit Claude Code lassen sich gewachsene Libraries reverse-engineeren, dokumentieren und mit Unit-Tests absichern.
Shared Libraries im WorkshopEine Shared Library ist die Antwort auf das größte Skalierungsproblem von Pipeline as Code: Sobald mehrere Repositories ähnliche Build-, Test- und Deploy-Schritte brauchen, droht Copy-Paste über Dutzende Jenkinsfiles. Die Library kapselt diese Logik in einem eigenen Git-Repository mit fester Struktur — vars/ für global aufrufbare Custom-Steps, src/ für Groovy-Klassen, resources/ für Templates und Skripte. Per @Library-Direktive binden Pipelines eine bestimmte Version ein.
Die Versionierung über Git-Refs ist im Industrial-Kontext entscheidend. Ein Team kann eine Pipeline an einen geprüften Tag pinnen, während ein anderes auf der main-Branch mitentwickelt — wichtig, wenn dieselbe Library sowohl Embedded- als auch IT-Pipelines bedient und Änderungen nicht unkontrolliert in sicherheitsrelevante Builds durchschlagen dürfen. So entsteht ein zentral gepflegter, aber kontrolliert ausgerollter Standard.
Stolpersteine: Library-Code unterliegt der CPS-Transformation, weshalb nicht jedes Groovy-Idiom funktioniert und @NonCPS-Annotationen nötig sein können. Gewachsene Libraries werden ohne Tests schnell zur Blackbox, deren Änderung niemand mehr riskiert. Hier hilft KI doppelt: Claude Code kann eine undokumentierte Library analysieren, ihre Funktionen beschreiben und mit JenkinsPipelineUnit-Tests absichern, bevor refactored wird.
Standardisierter Deploy-Step für alle Teams
Eine zentrale Plattform-Gruppe stellt einen deployToOt-Step in der Shared Library bereit, der Wartungsfenster-Prüfung, OPC-UA-Statuscheck und Audit-Logging kapselt — jede Produkt-Pipeline ruft ihn mit einer Zeile auf, statt die Logik selbst zu pflegen.
Versions-Pinning für sicherheitskritische Pipeline
Eine ISO-26262-relevante Firmware-Pipeline bindet die Library an einen freigegebenen Tag, während Web-Projekte die laufende Entwicklungsversion nutzen — Änderungen durchlaufen erst einen Freigabeprozess, bevor sie die Safety-Pipeline erreichen.
Test-Absicherung einer Legacy-Library
Vor einem Refactoring lässt das Team Claude Code für jede vars-Funktion ein JenkinsPipelineUnit-Test-Skeleton mit passenden Mocks generieren, sodass das Verhalten vor und nach dem Umbau vergleichbar bleibt.
- Wie referenziert eine Pipeline eine bestimmte Version der Shared Library?
- Über die @Library-Annotation mit Angabe von Branch, Tag oder Commit, etwa @Library("meine-lib@v2.3.0"). Ohne explizite Angabe wird die in der Jenkins-Systemkonfiguration hinterlegte Default-Version geladen. Für reproduzierbare Builds ist explizites Pinning empfehlenswert.
- Was gehört in vars/ und was in src/?
- vars/ enthält global aufrufbare Custom-Steps, deren Dateiname zum Step-Namen wird (z. B. deploy.groovy für deploy()). src/ enthält klassische Groovy-Klassen mit Paketstruktur für komplexere, objektorientierte Logik, die aus den vars-Steps heraus genutzt wird.
- Kann man mehrere Shared Libraries gleichzeitig in einer Pipeline nutzen?
- Ja, eine Pipeline kann mehrere Libraries einbinden — etwa eine unternehmensweite Standard-Library und eine projektspezifische Erweiterung. Bei Namenskonflikten zwischen gleichnamigen Steps entscheidet die Ladereihenfolge, weshalb klare Namenskonventionen wichtig sind.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance