Jenkins shared library

Situation

The pipeline was a copy in every repository. Across more than 40 services, a regular developer could not change it without DevOps. Security checks were not part of the build, so one service could ship a package another would have scanned. Parameters were hardcoded, so a new option meant editing every repository.

What we did

One shared library and reusable downstream jobs across more than 40 services. Developers change that path themselves. The build stage audits and scans before it builds. Each repository still says what it produces.

1. 1.One library for every service

   Repeated logic went into a Jenkins shared library. The services stopped keeping their own copy. A developer changes that library. The change applies to every job that calls it, without a DevOps handoff for each repository.

2. 2.Audit and scan before the build

   The pipeline was split into downstream jobs. One of them is an atomic build stage: packages are audited and scanned, and only then does the build run. That stage is the same for every service.

3. 3.Parameters looked up, not copied

   Active Choices fills the job parameters from the live options, instead of a list hardcoded in each Jenkinsfile.

4. 4.What stays in the repository

   What the service builds stays in its repository: a container image, a Python package, or whatever that repo ships. The core logic does not.

What changed

• A developer changes the pipeline without waiting on DevOps
• More than 40 services use that path
• Every one of them is audited and scanned before the build
• What a service produces stays in its own repository