Hybrid CI/CD approaches in Jenkins - Time & Space Complexity
We want to understand how the time to run a hybrid CI/CD pipeline changes as we add more projects or steps.
How does the pipeline's work grow when combining continuous integration and delivery tasks?
Analyze the time complexity of the following Jenkins pipeline snippet.
pipeline {
agent any
stages {
stage('Build') {
steps {
script {
for (int i = 0; i < projects.size(); i++) {
build job: projects[i], wait: true
}
}
}
}
stage('Deploy') {
steps {
parallel projects.collectEntries { [(it): { deploy(it) }] }
}
}
}
}
This pipeline builds multiple projects one after another, then deploys them all at the same time in parallel.
Look at the loops and parallel tasks that repeat work.
- Primary operation: Loop over projects to build sequentially, then parallel deploy.
- How many times: Once per project for build, once per project for deploy.
As the number of projects grows, the build time adds up, but deploy happens all at once.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 builds + 1 parallel deploy |
| 100 | 100 builds + 1 parallel deploy |
| 1000 | 1000 builds + 1 parallel deploy |
Pattern observation: Build time grows linearly with projects; deploy time stays roughly constant due to parallelism.
Time Complexity: O(n)
This means the total time grows directly with the number of projects because builds run one after another.
[X] Wrong: "Because deploy is parallel, the whole pipeline runs in constant time regardless of projects."
[OK] Correct: The build stage is sequential and takes longer as projects increase, so total time still grows with project count.
Understanding how sequential and parallel steps affect pipeline time helps you design efficient CI/CD workflows and explain your choices clearly.
What if we changed the build stage to run builds in parallel too? How would the time complexity change?