Shared libraries

One reviewed pipeline vocabulary for every repo.

Once you have a dozen pipelines, they start to repeat — the same build-scan-push logic copy-pasted into forty Jenkinsfiles that then drift apart. A shared library extracts that common logic into one versioned Groovy repository that every pipeline imports, so a fix or a new security step is written once and adopted everywhere, and each Jenkinsfile shrinks to a few readable lines.

@Library('acme-pipelines@v3') _    // pin a version/tag of the shared library
 
standardPipeline(
  language: 'node',
  deployTo: 'staging'
)   // one reviewed function expands into the full build/test/scan/deploy pipeline

How a shared library is structured

A shared library is a Git repo with a vars/ directory of reusable steps (each file a global function like standardPipeline) and a src/ tree for supporting classes. Jenkins is configured to load it, and pipelines import it with @Library, pinning a tag so an upstream change cannot silently alter every build. The library is code, reviewed through pull requests, so the pipeline logic every team runs has been vetted once.

def call(Map cfg) {
  pipeline {
    agent { label 'linux' }
    stages {
      stage('Build') { steps { sh "make build" } }
      stage('Test')  { steps { sh "make test" } }
      stage('Scan')  { steps { sh "make scan" } }   // one place to add a security gate
    }
  }
}

Why this is a security win

The security value is centralization. When a new scan or a signing step needs to go into every pipeline, you add it to the shared library once and everyone gets it on their next build — instead of chasing forty repos. And because the library is the one place pipeline logic lives, it is the one place to review and control, rather than trusting each team’s hand-rolled Jenkinsfile. Pin the version so adoption is deliberate.