Avoiding hard-coded values in Jenkins - Time & Space Complexity
When we avoid hard-coded values in Jenkins pipelines, we often use variables or parameters instead. This changes how the pipeline runs depending on input size or values.
We want to understand how the pipeline's work grows when we replace fixed values with inputs that can change.
Analyze the time complexity of the following Jenkins pipeline snippet.
pipeline {
agent any
parameters {
string(name: 'SERVERS', defaultValue: 'server1,server2', description: 'List of servers')
}
stages {
stage('Deploy') {
steps {
script {
def serverList = params.SERVERS.split(",")
for (int i = 0; i < serverList.size(); i++) {
echo "Deploying to ${serverList[i]}"
}
}
}
}
}
}
This pipeline takes a list of servers as input and deploys to each one by looping through the list.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping through the list of servers to deploy.
- How many times: Once for each server in the input list.
As the number of servers increases, the deployment steps increase proportionally.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 deployment steps |
| 100 | 100 deployment steps |
| 1000 | 1000 deployment steps |
Pattern observation: The work grows directly with the number of servers; doubling servers doubles the work.
Time Complexity: O(n)
This means the time to complete deployment grows linearly with the number of servers provided.
[X] Wrong: "Using parameters instead of hard-coded values makes the pipeline run instantly regardless of input size."
[OK] Correct: The pipeline still runs steps for each input item, so more inputs mean more work and longer run time.
Understanding how input size affects pipeline execution helps you design flexible and efficient automation. This skill shows you can think about scaling and resource use in real projects.
"What if we changed the input from a list of servers to a nested list of server groups? How would the time complexity change?"