Jenkins Shared Libraries: Don't Repeat Your Pipeline Code

WHY IT EXISTS: As an organization adopts Jenkins Pipeline for more projects, common patterns emerge. Instead of copying and pasting code between Jenkinsfiles, which is error-prone and hard to maintain, Shared Libraries were created to share parts of pipelines between projects and keep code DRY (Don't Repeat Yourself).

THE MENTAL MODEL: Treat a Shared Library as a common dependency for your pipelines. Instead of pasting Groovy code into every Jenkinsfile, you import a versioned library from a central source control repository, just like you'd import a package in Python or a JAR in Java. This lets you manage, version, and test your CI/CD logic independently of the application code.

HOW IT WORKS: A Shared Library is a source control repository (like Git) with a specific folder structure. Jenkins checks out this repository and makes its code available to your pipelines. There are two key directories: vars/ and src/. The vars/ directory holds Groovy scripts that become global variables in your pipeline. For example, a file named vars/myUtils.groovy containing a function doSomething() would be callable as myUtils.doSomething(). The src/ directory is for more complex, object-oriented code, following a standard Java/Groovy source structure (e.g., src/com/myorg/MyClass.groovy). This code is compiled and added to the pipeline's classpath. You configure the library in Jenkins, specifying its name, SCM location, and an optional default version like a branch or tag.

WHEN TO USE IT: Use Shared Libraries when you have common, repeated logic across multiple Jenkinsfiles. This is ideal for standardizing tasks like building Docker images, running security scans, deploying to specific environments, or sending notifications. It enforces consistency and makes updating a process across all projects as simple as pushing a commit to the library repository.

WHEN NOT TO USE IT: For logic that is truly unique to a single project's pipeline, a Shared Library is overkill. Simple helper functions can be defined directly within the Jenkinsfile itself. Using a library for a one-off task adds the unnecessary complexity of managing and versioning a separate repository.

ONE CANONICAL EXAMPLE: A common use case is creating a standardized notification function. You could create a file vars/notifications.groovy in your shared library. Inside, you define a function slack(message). In any Jenkinsfile that imports this library, you can now simply call notifications.slack("Build failed on ${env.JOB_NAME}") in your post block, abstracting away all the complex logic of sending a Slack message.