When working with CI/CD in Jenkins, flexibility is key. What if you want to build different branches, deploy to different environments, or control whether certain stages should run?

That’s where Parameterized Pipelines come into play.

In this blog, we’ll walk through creating a fully functional parameterized pipeline in Jenkins using String, Choice, and Boolean parameters — along with real-world pipeline code to deploy to Git, SonarQube, Nexus, and Tomcat.

Let’s get started!

Steps to Create a Parameterized Pipeline in Jenkins

Step 1: Create a New Pipeline Job

• Go to your Jenkins Dashboard

• Click “New Item”

• Give your project a name (e.g., Parameterized-Pipeline)

• Select “Pipeline”

• Click OK

  

Step 2: Enable Build Parameters

• Inside your project configuration:

  • Go to the “General” section

  • Check the box for “This project is parameterized”

    

Step 3: Add Parameters

Now let’s add three types of parameters that the pipeline will use.

1. String Parameter

• Click “Add Parameter” > String Parameter

• Fill in the details:

  • Name: BRANCH_NAME

  • Default Value: development

  • Description: Git branch to build

    

2. Choice Parameter

• Click “Add Parameter” > Choice Parameter

• Fill in the details:

  • Name: ENVIRONMENT

  • Choices:

      rCopyEditdev
      qa
      prod
    

  • Description: Deployment environment

    

3. Boolean Parameter

• Click “Add Parameter” > Boolean Parameter

• Fill in the details:

  • Name: DEPLOY_TO_TOMCAT

  • Default Value: checked (true)

  • Description: Deploy WAR to Tomcat?

    

Step 4: Add Pipeline Code

Scroll down to the Pipeline section and choose Pipeline Script.

Paste the following code:

groovyCopyEdit// Jenkins Declarative Pipeline with Parameters
pipeline {
    agent any

    tools {
        maven "maven-3.9.9"
    }

    parameters {
        string(name: 'BRANCH_NAME', defaultValue: 'development', description: 'Git branch to build')
        choice(name: 'ENVIRONMENT', choices: ['dev', 'qa', 'prod'], description: 'Deployment environment')
        booleanParam(name: 'DEPLOY_TO_TOMCAT', defaultValue: true, description: 'Deploy WAR to Tomcat?')
    }

    stages {
        stage('Git Checkout') {
            steps {
                echo "Checking out branch: ${params.BRANCH_NAME}"
                git branch: "${params.BRANCH_NAME}", url: 'https://github.com/Bancslink/my-web-app-project.git'
            }
        }

        stage('Build') {
            steps {
                sh "mvn clean package"
            }
        }

        stage('SonarQube Report') {
            steps {
                sh "mvn sonar:sonar"
            }
        }

        stage('Deploy to Nexus') {
            steps {
                sh "mvn deploy"
            }
        }

        stage('Deploy to Tomcat') {
            when {
                expression { return params.DEPLOY_TO_TOMCAT }
            }
            steps {
                echo "Deploying WAR file to Tomcat in environment: ${params.ENVIRONMENT}"
                sh """
                    curl -u sandeep:1234 \
                        --upload-file /var/lib/jenkins/workspace/Declarative-pipeline-jio/target/maven-web-application.war \
                        "http://3.111.169.249:8000/manager/text/deploy?path=/maven-web-application&update=true"
                """
            }
        }
    }
}

Click Save.

The parameters block declares build parameters, which means when you click “Build with Parameters,” Jenkins will show these options in the UI, so you can customize how the job runs.

Line by Line Explanation

1) string(...)

groovyCopyEditstring(
    name: 'BRANCH_NAME',
    defaultValue: 'development',
    description: 'Git branch to build'
)

• Parameter Type: String (text input field)

• Name: BRANCH_NAME (variable you reference as params.BRANCH_NAME)

• Default Value: 'development' (pre-filled in the UI)

• Description: shows the help text “Git branch to build”
  Use Case:
  If you want to build a specific branch (e.g., feature/login), you enter it here.

2)choice(...)

groovyCopyEditchoice(
    name: 'ENVIRONMENT',
    choices: ['dev', 'qa', 'prod'],
    description: 'Deployment environment'
)

• Parameter Type: Choice (dropdown menu)

• Name: ENVIRONMENT

• Choices: ['dev', 'qa', 'prod']

  • The user selects one of these options.

• Description: explains the purpose of the dropdown.
  Use Case:
  Deploy to Dev, QA, or Production environment depending on the selection.

3) booleanParam(...)

groovyCopyEditbooleanParam(
    name: 'DEPLOY_TO_TOMCAT',
    defaultValue: true,
    description: 'Deploy WAR to Tomcat?'
)

• Parameter Type: Boolean (checkbox)

• Name: DEPLOY_TO_TOMCAT

• Default Value: true (checked by default)

• Description: instructs the user what this toggle controls.
  Use Case:
  If checked, the pipeline deploys to Tomcat after the build. If unchecked, it skips deployment.

How you use them in your pipeline
You reference them via:

groovyCopyEditparams.BRANCH_NAME
params.ENVIRONMENT
params.DEPLOY_TO_TOMCAT

For example:

groovyCopyEditgit branch: "${params.BRANCH_NAME}"
when { expression { return params.DEPLOY_TO_TOMCAT } }

Bottom Line:
This block makes your pipeline flexible and reusable, so a single job can build any branch, deploy to any environment, and optionally skip deployment.

Step 5: Build with Parameters

• Go back to the Jenkins Dashboard

• Click on your pipeline project (e.g., Parameterized-Pipeline)

• Select “Build with Parameters”

  

• You’ll see three fields:

  • Git Branch Name

  • Deployment Environment

  • Deploy WAR to Tomcat?

• Fill them in or keep defaults, then click Build

  

• Once build starts it shows build number and final build steps here.

  

  

Done! What Happens Now?

• Jenkins checks out the selected Git branch

• Builds the code using Maven

• Sends code quality analysis to SonarQube

• Publishes artifacts to Nexus

• Optionally (if checkbox is checked), deploys WAR to Tomcat

  

  Click on /maven-web-application it will open final output as below

• 

Conclusion

With Parameterized Pipelines in Jenkins, you unlock powerful, reusable, and customizable CI/CD workflows that can adapt to different environments and use cases.

Whether you're a DevOps engineer or developer, mastering this feature helps you automate smarter, reduce duplication, and increase flexibility.