Why shared libraries reduce duplication in Jenkins - Performance Analysis
We want to see how using shared libraries affects the amount of repeated work in Jenkins pipelines.
How does sharing code change how much work Jenkins does as projects grow?
Analyze the time complexity of the following Jenkins pipeline snippet using a shared library.
@Library('commonLib') _
pipeline {
agent any
stages {
stage('Build') {
steps {
commonLib.buildProject()
}
}
stage('Test') {
steps {
commonLib.runTests()
}
}
}
}
This pipeline calls shared library functions instead of repeating build and test steps in each pipeline.
Look for repeated code or calls that happen multiple times.
- Primary operation: Calling shared library functions for build and test steps.
- How many times: Each pipeline calls these functions once per stage, but many pipelines reuse the same library code.
Imagine the number of pipelines grows.
| Number of Pipelines (n) | Approx. Code Duplication |
|---|---|
| 10 | Low duplication because shared code is reused |
| 100 | Still low duplication; one shared library serves all pipelines |
| 1000 | Duplication remains low; no need to copy build/test steps 1000 times |
Pattern observation: Using shared libraries keeps duplication steady even as pipelines increase.
Time Complexity: O(n)
This means the work grows linearly with the number of pipelines, but the shared code itself is written once and reused.
[X] Wrong: "Using shared libraries means Jenkins runs the same code multiple times, so it duplicates work."
[OK] Correct: The shared library code is reused in writing, but Jenkins executes only what each pipeline needs. The duplication is in code writing, not in execution.
Understanding how shared libraries reduce duplication shows you can write cleaner, easier-to-maintain pipelines. This skill helps you work smarter with Jenkins and DevOps tools.
"What if each pipeline modified the shared library code locally instead of using it as is? How would that affect duplication and time complexity?"