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.
Auch bekannt als: Shared Library · Jenkins Pipeline Library · Groovy Shared Library
Ist Jenkins Shared Library 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.
Eine Shared Library wird einmal in Jenkins registriert, entweder global in der Systemkonfiguration oder auf Ebene eines Ordners. Schreibt eine Pipeline @Library('meine-lib@v2.3.0') _ an den Anfang, checkt Jenkins das Library-Repository in genau diesem Stand aus, bevor die erste Stage läuft. Jede Datei unter vars/ wird dabei zu einem Step: Aus deploy.groovy wird der Aufruf deploy(). Unter src/ liegen Groovy-Klassen für umfangreichere Logik, unter resources/ Templates und Skripte, die der Code mit libraryResource lädt.
Wo die Library registriert ist, bestimmt ihre Rechte. Global eingetragene Libraries gelten als vertrauenswürdig und dürfen auch Jenkins-interne APIs aufrufen. Libraries auf Ordnerebene laufen in der Groovy-Sandbox, wie ein normales Jenkinsfile. Wer eine Library global freigibt, sollte deshalb auch regeln, wer in ihr Repository schreiben darf.
Im Industrie-Kontext kommt es besonders auf die Versionierung über Git-Refs an. Ein Team pinnt seine Pipeline an einen geprüften Tag, ein anderes entwickelt auf der main-Branch mit. Das zählt, wenn dieselbe Library Embedded- und IT-Pipelines bedient und eine Änderung nicht ungeprüft in einen sicherheitsrelevanten Build rutschen darf. So bleibt der Standard zentral gepflegt, wird aber kontrolliert ausgerollt.
Die Stolpersteine zeigen sich meist erst nach Jahren. Library-Code unterliegt der CPS-Transformation, weshalb nicht jedes Groovy-Idiom funktioniert und manche Methoden @NonCPS brauchen. Ohne Tests wird eine gewachsene Library zur Blackbox: die eine vars-Funktion, die 40 Pipelines speist und die seit dem Weggang ihres Autors niemand anzufassen wagt. Claude Code kann eine solche Library lesen, ihre Funktionen dokumentieren und sie mit JenkinsPipelineUnit-Tests absichern, bevor jemand umbaut.
Ein Deploy-Step für alle OT-Deployments
Jedes Produktteam hatte seine eigene Variante, um vor dem Deployment das Wartungsfenster zu prüfen. Die Plattform-Gruppe stellt nun einen deployToOt-Step in der Shared Library bereit, der Wartungsfenster, OPC-UA-Statuscheck und Audit-Logging kapselt. Jede Pipeline ruft ihn mit einer Zeile auf, und eine Korrektur wirkt überall gleichzeitig.
Safety-Pipeline bleibt auf dem freigegebenen Stand
Eine Firmware-Pipeline unterliegt ISO 26262, Web-Projekte derselben Firma entwickeln die Library laufend weiter. Die Safety-Pipeline bindet die Library an einen freigegebenen Tag, die Web-Projekte nutzen main. Eine Änderung erreicht den Safety-Build erst, nachdem sie den Freigabeprozess durchlaufen hat.
Tests vor dem Umbau einer Legacy-Library
Ein Team will eine alte Library umbauen, weiß aber nicht genau, was sie tut. Claude Code erzeugt für jede vars-Funktion ein JenkinsPipelineUnit-Test-Skeleton mit passenden Mocks, das Team ergänzt die fachlichen Assertions. Nach dem Umbau zeigen dieselben Tests, ob sich das Verhalten geändert hat.
Lohnt sich eine Jenkins Shared Library?
Eine Shared Library zieht wiederkehrende Pipeline-Logik an einen Ort — der Gewinn wächst mit der Zahl Ihrer Pipelines. Zwei Klicks ordnen ein.
Wie viele Jenkins-Pipelines pflegen Sie?
- Wie referenziert eine Pipeline eine bestimmte Version der Shared Library?
- Über die @Library-Annotation mit Branch, Tag oder Commit hinter dem @-Zeichen, etwa @Library("meine-lib@v2.3.0") _. Ohne explizite Angabe lädt Jenkins die Default-Version aus der Systemkonfiguration. Für reproduzierbare Builds sollten Sie die Version explizit pinnen.
- Was gehört in vars/ und was in src/?
- vars/ enthält global aufrufbare Custom-Steps, deren Dateiname zum Step-Namen wird, zum Beispiel deploy.groovy für deploy(). src/ enthält klassische Groovy-Klassen mit Paketstruktur für umfangreichere Logik, die die vars-Steps intern nutzen.
- 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. Heißen Steps in beiden Libraries gleich, wird schwer nachvollziehbar, welcher tatsächlich läuft. Eindeutige Präfixe für Step-Namen vermeiden das.
Wo steht Ihr Team bei Jenkins Shared Library?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu Jenkins Shared Library: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01JenkinsShared Libraries(externe Seite, öffnet in neuem Tab)
Verzeichnisaufbau, Versionierung und Einbindung wiederverwendbarer Pipeline-Bausteine.
- /02Jenkins PluginsPipeline: Shared Groovy Libraries(externe Seite, öffnet in neuem Tab)
Das Plugin hinter der Funktion, mit Konfiguration global und je Ordner.
- /03GitHubworkflow-cps-global-lib-plugin(externe Seite, öffnet in neuem Tab)
Quellcode und Änderungsverlauf, hilfreich bei Fragen zum Klassenlader.
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