Avoiding hard-coded values in Jenkins - Mini Project: Build & Apply

Avoiding Hard-Coded Values in Jenkins Pipeline

📖 Scenario: You are creating a Jenkins pipeline script to build and deploy a simple application. To make your pipeline flexible and easy to maintain, you want to avoid hard-coding values like the branch name and build environment directly in the script.

🎯 Goal: Build a Jenkins pipeline script that uses variables for branch name and environment instead of hard-coded values. This will help you reuse the pipeline for different branches and environments easily.

📋 What You'll Learn

Create variables for branch name and environment

Use these variables in the pipeline stages

Print the values of these variables during the build

Avoid any hard-coded strings for branch or environment in the pipeline steps

💡 Why This Matters

🌍 Real World

In real projects, hard-coded values make pipelines rigid and hard to update. Using variables allows teams to reuse pipelines for multiple branches and environments without changing the code.

💼 Career

DevOps engineers and Jenkins administrators often create pipelines that must work across many projects and environments. Knowing how to avoid hard-coded values is essential for writing maintainable and scalable CI/CD pipelines.

1

Create variables for branch and environment

Create two variables called branchName and environment and set them to "main" and "production" respectively.

Jenkins

# Create variables branchName and environment with values "main" and "production"
# Your code here

Hint

Use def to declare variables in Jenkins scripted pipeline.

2

Use variables in the pipeline stages

Add a pipeline block with an agent any. Inside stages, create a stage called Build that echoes the message "Building branch: ${branchName}" using the branchName variable.

Jenkins

def branchName = "main"
def environment = "production"

// Add pipeline block with Build stage that echoes branchName
// Your code here

Hint

Use pipeline and stage blocks. Use echo to print messages.

3

Add a Deploy stage using the environment variable

Inside the existing pipeline block, add a new stage called Deploy that echoes the message "Deploying to environment: ${environment}" using the environment variable.

Jenkins

def branchName = "main"
def environment = "production"

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo "Building branch: ${branchName}"
            }
        }
        // Add Deploy stage here
        // Your code here
    }
}

Hint

Add another stage block inside stages with echo step.

4

Print both variables in the pipeline

Add a final stage called Print Info inside the pipeline that echoes both branchName and environment in the format: "Branch: ${branchName}, Environment: ${environment}".

Jenkins

def branchName = "main"
def environment = "production"

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo "Building branch: ${branchName}"
            }
        }
        stage('Deploy') {
            steps {
                echo "Deploying to environment: ${environment}"
            }
        }
        // Add Print Info stage here
        // Your code here
    }
}

Hint

Use echo to print both variables in one message inside a new stage.

Practice

1. Why should you avoid hard-coded values in Jenkins pipelines?

easy

A. Because Jenkins does not support hard-coded values

B. Because hard-coded values run faster

C. To reduce the number of pipeline steps

D. To make pipelines flexible and easier to maintain

Solution

1. Step 1: Understand pipeline flexibility

   Hard-coded values fix data in one place, making changes difficult and pipelines less reusable.

2. Step 2: Recognize benefits of environment variables

   Using environment variables allows easy updates and reuse without changing pipeline code.

3. Final Answer:

   To make pipelines flexible and easier to maintain -> Option D

4. Quick Check:

   Flexibility = Avoid hard-coded values [OK]

Hint: Remember: environment variables make pipelines flexible [OK]

Common Mistakes:

• Thinking hard-coded values improve speed
• Believing Jenkins disallows hard-coded values
• Confusing fewer steps with better practice

2. Which syntax correctly uses an environment variable MY_VAR in a Jenkins pipeline script?

easy

A. echo 'Value is $MY_VAR'

B. echo "Value is ${MY_VAR}"

C. echo "Value is %MY_VAR%"

D. echo "Value is MY_VAR"

Solution

1. Step 1: Identify correct variable syntax in Groovy

   Jenkins pipeline scripts use Groovy, where environment variables are accessed as ${VAR_NAME} inside strings.

2. Step 2: Compare options

   echo "Value is ${MY_VAR}" uses ${MY_VAR}, which is the correct Groovy syntax for environment variables in strings.

3. Final Answer:

   echo "Value is ${MY_VAR}" -> Option B

4. Quick Check:

   Groovy env var syntax = ${VAR} [OK]

Hint: Use ${VAR} to access env variables in Jenkins Groovy scripts [OK]

Common Mistakes:

• Using $VAR without braces in Groovy strings
• Using Windows-style %VAR% syntax
• Writing variable name as plain text

3. Given this Jenkins pipeline snippet:

environment {
  GREETING = 'Hello'
}

pipeline {
  agent any
  stages {
    stage('Print') {
      steps {
        echo "${GREETING}, World!"
      }
    }
  }
}

What will be the output when this pipeline runs?

medium

A. Hello, World!

B. ${GREETING}, World!

C. GREETING, World!

D. Error: GREETING not defined

Solution

1. Step 1: Understand environment block usage

   The environment block defines GREETING as 'Hello', making it available in the pipeline steps.

2. Step 2: Evaluate echo statement

   The echo uses "${GREETING}, World!" which substitutes GREETING with 'Hello'.

3. Final Answer:

   Hello, World! -> Option A

4. Quick Check:

   Env var substitution = Hello, World! [OK]

Hint: Environment vars replace ${VAR} in pipeline steps [OK]

Common Mistakes:

• Expecting literal ${GREETING} output
• Confusing variable scope outside environment block
• Assuming syntax error due to quotes

4. You have this Jenkins pipeline snippet:

environment {
  PASSWORD = credentials('my-secret')
}

steps {
  echo "Password is $PASSWORD"
}

What is the problem with this code?

medium

A. Echoing password directly exposes sensitive data

B. credentials() cannot be used inside environment block

C. Using $PASSWORD instead of ${PASSWORD} causes no substitution

D. Missing quotes around credentials ID

Solution

1. Step 1: Understand credentials usage

   Using credentials('my-secret') loads a secret securely into PASSWORD variable.

2. Step 2: Identify security risk

   Echoing the password directly prints sensitive data in logs, which is unsafe.

3. Final Answer:

   Echoing password directly exposes sensitive data -> Option A

4. Quick Check:

   Never print secrets in logs [OK]

Hint: Never echo secrets; use them securely [OK]

Common Mistakes:

• Thinking $PASSWORD syntax is wrong in Groovy
• Believing credentials() can't be in environment block
• Ignoring security risks of printing secrets

5. You want to avoid hard-coded URLs in your Jenkins pipeline. Which approach best achieves this while keeping the URL secret and reusable?

hard

A. Write the URL directly in the pipeline script as a string

B. Pass the URL as a command-line argument to Jenkins

C. Store the URL in Jenkins credentials and access it via environment variable

D. Use a global variable in the pipeline script with the URL

Solution

1. Step 1: Identify secure storage for sensitive data

   Jenkins credentials store secrets securely and allow reuse without exposing them in code.

2. Step 2: Use environment variables to access credentials

   Accessing credentials via environment variables avoids hard-coding and keeps pipelines flexible.

3. Final Answer:

   Store the URL in Jenkins credentials and access it via environment variable -> Option C

4. Quick Check:

   Secure reuse = credentials + env vars [OK]

Hint: Use Jenkins credentials for secret reusable values [OK]

Common Mistakes:

• Hard-coding secrets in scripts
• Passing secrets insecurely via command line
• Using global vars that expose secrets