Jenkins CI/CD & Groovy Pipelines: 12-Day Production Masterclass 🛠️🚀

Day 1 CI/CD Architecture, The 5 Core Stages & Server Provisioning

Jenkins is an open-source automation server powered by an extensible plugin ecosystem. When developers write code and push it to a remote Git repository, Jenkins automates the entire lifecycle—building the artifact with Maven, deploying to a QA server, executing automated Selenium tests, and delivering the verified build to Production.

The 5 Core Stages of a Jenkins CI/CD Pipeline

1. Continuous Download: Pulling the latest source code pushed by developers from a Git repository.
2. Continuous Build: Compiling the source code and packaging it into an executable artifact (e.g., .war or .jar) using Maven.
3. Continuous Deployment: Deploying the packaged build artifact into the Testing/QA environment (Apache Tomcat server).
4. Continuous Testing: Running automated functional test suites (Selenium) against the deployed QA application.
5. Continuous Delivery: Promoting the tested and approved artifact to the live Production server.

Three-Server Infrastructure Topology (Vagrant or AWS Cloud)

To simulate a real enterprise environment, provision three Ubuntu Linux servers:

• Server 1 — Jenkins Server: Coordinates CI/CD jobs and builds artifacts.
• Server 2 — QA Server (Tomcat): Hosts the application for automated testing.
• Server 3 — Production Server (Tomcat): Hosts the final production release.

# === Option A: Local Provisioning via HashiCorp Vagrant & VirtualBox ===
# 1. Install Oracle VM VirtualBox and HashiCorp Vagrant
# 2. Verify Vagrant installation in terminal/CMD
vagrant --version

# 3. Create project directory, place Vagrantfile, and boot the VMs
mkdir jenkins-lab && cd jenkins-lab
vagrant init ubuntu/focal64
vagrant up

# === Option B: Cloud Provisioning on AWS EC2 ===
# Launch 3 Ubuntu Server instances (t2.micro / t2.medium) named:
# 1. Jenkins-Master (Open Port 22, 8080)
# 2. QA-Tomcat-Server (Open Port 22, 8080)
# 3. Prod-Tomcat-Server (Open Port 22, 8080)

Day 2 Installing Jenkins, JDK, Maven & Configuring QA/Prod Tomcat Servers

Configure your three Ubuntu instances with their required software stacks: OpenJDK 11, Git, Maven, and Jenkins on the CI server, and Apache Tomcat 9 on the QA and Production servers.

1. Setting Up the Jenkins Server (Java, Git, Maven & Jenkins WAR)

# 1. Update apt package index and install OpenJDK 11
sudo apt-get update
sudo apt-get install -y openjdk-11-jdk
java -version

# 2. Install Git and Apache Maven
sudo apt-get install -y git
sudo apt-get install -y maven

# 3. Download the Generic Java Package (.war) for Jenkins LTS
wget https://get.jenkins.io/war-stable/2.401.3/jenkins.war
ls -la

# 4. Start Jenkins from the WAR file (runs on port 8080)
java -jar jenkins.war

# 5. Access http://:8080 in your browser, paste the initialAdminPassword,
#    select "Install suggested plugins", and create your Admin user.

2. Setting Up QA & Production Servers (Tomcat 9 & Manager Roles)

Install tomcat9 and tomcat9-admin on both the QA and Production servers, then configure tomcat-users.xml with the manager-script role so Jenkins can deploy WAR files remotely:

# 1. Update packages and install Tomcat 9 + Admin tools
sudo apt-get update
sudo apt-get install -y tomcat9 tomcat9-admin

# 2. Navigate to Tomcat configuration directory and edit tomcat-users.xml
cd /etc/tomcat9
sudo vim tomcat-users.xml

<!-- Add inside the <tomcat-users> block in /etc/tomcat9/tomcat-users.xml -->
<tomcat-users>
  <role rolename="manager-script"/>
  <user username="cloudsinfo" password="cloudsinfo" roles="manager-script"/>
</tomcat-users>

# 3. Restart Tomcat 9 service to apply credentials
sudo service tomcat9 restart

Day 3 Freestyle Jobs: Continuous Download (Git) & Continuous Build (Maven)

Before writing pipelines as code, understand how Jenkins executes individual CI stages using Freestyle Projects and workspace directories.

1. Continuous Download & Continuous Build in a Freestyle Job

1. Go to Jenkins Dashboard → New Item, enter a job name (e.g., Dev-Maven-Build), select Freestyle project, and click OK.
2. Under Source Code Management, select Git and paste the repository URL: https://github.com/cicdclouds/cicdclouds-javawebapp.git.
3. Under Build Steps → Add build step, choose Invoke top-level Maven targets (or Execute shell) and run mvn package.
4. Click Apply & Save, then click Build Now.

# Inspecting the generated WAR artifact on the Jenkins Server filesystem:
cd ~/.jenkins/workspace/Dev-Maven-Build/webapp/target/
ls -la
# Output shows packaged artifact: webapp.war

Day 4 Continuous Deployment, Selenium Testing & Upstream/Downstream Chaining

Automate WAR deployment to Tomcat containers using the Deploy to container plugin and chain multiple Freestyle jobs together into an automated Upstream/Downstream workflow.

1. Installing "Deploy to container" & Deploying to QA Tomcat

1. Navigate to Manage Jenkins → Plugins → Available plugins, search for Deploy to container, and install without restart.
2. Open your build job configuration → Post-build Actions → Add post-build action → Deploy war/ear to a container.
3. Set WAR/EAR files to **/*.war and Context path to testapp.
4. Click Add Container → Tomcat 9.x Remote, add your Tomcat credentials (cloudsinfo / cloudsinfo), and set Tomcat URL to http://<QA_PRIVATE_IP>:8080.

2. Chaining Jobs (Build Triggers: Build after other projects are built)

# Job 1: Dev-Build-Deploy (Downloads code, runs 'mvn package', deploys to QA Tomcat)
# Job 2: QA-Functional-Test (Triggered automatically if Job 1 is stable)
#   - Pulls https://github.com/cicdclouds/cicdclouds-testwebapp.git
#   - Executes: java -Dapp.host= -Dapp.port=8080 -Dapp.context="" -jar target/functionalapi-tests.jar java -Dapp.host= -Dapp.port= -Dapp.context= -jar target/functionalapi-tests.jar
# Job 3: Prod-Delivery (Triggered automatically if Job 2 succeeds)
#   - Deploys **/*.war to Production Tomcat server (context path: prodapp)

Day 5 User Administration (RBAC), Cron Scheduling, SSH Peering & Systemd Service

In production, developers and QA engineers should only see and trigger jobs relevant to their team. Use the Role-based Authorization Strategy plugin to enforce granular access control.

1. Role-Based Authorization Strategy (RBAC) Setup

1. Create Users: Go to Dashboard → Manage Jenkins → Users → Create User (create a Developer user and a Tester user).
2. Install Plugin: Go to Manage Jenkins → Plugins → Available plugins, search for Role-based Authorization Strategy, and install without restart.
3. Enable Strategy: Go to Manage Jenkins → Security → Authorization, select Role-Based Strategy, and save.
4. Manage Roles: Go to Manage Jenkins → Manage and Assign Roles → Manage Roles:
   • Global roles: Create employee role with basic Overall: Read permission.
   • Item roles: Create developer role with Pattern dev.* (or Dev.*) and tester role with Pattern test.* (or Test.*) with Build/Read permissions.
5. Assign Roles: Go to Assign Roles, add users under Global roles (employee) and bind them to their respective Item roles (developer or tester).

2. Scheduling Builds (Build Periodically with Cron Syntax)

To trigger a job on a fixed schedule regardless of code changes, open Job → Configure → Build Triggers → Build periodically and define the 5 cron fields (MINUTE HOUR DOM MONTH DOW based on the server's timezone):

# Cron Syntax: MINUTE (0-59)  HOUR (0-23)  DOM (1-31)  MONTH (1-12)  DOW (0-7)
# Example 1: Run every 15 minutes
H/15 * * * *

# Example 2: Run daily at 11:30 PM server time
30 23 * * *

3. Password & Passwordless SSH Between Linux Servers

# === Step A: On Target Server (Server 2) ===
sudo passwd ubuntu                     # Set password for ubuntu user
sudo vim /etc/ssh/sshd_config          # Change 'PasswordAuthentication no' to 'yes'
sudo service ssh restart               # Restart SSH daemon

# === Step B: On Source Server (Server 1) - Setup Passwordless SSH ===
ssh-keygen                             # Press Enter to generate RSA keypair in ~/.ssh
cd ~/.ssh && ls
ssh-copy-id ubuntu@ # Copy public key to Server 2
ssh ubuntu@         # Verify passwordless login

4. Permanent Debian/Ubuntu Service Installation (Instead of java -jar)

# Install Jenkins as a permanent background systemd service on Ubuntu
sudo apt-get update
sudo apt-get install -y openjdk-11-jdk git maven

curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee \
  /usr/share/keyrings/jenkins-keyring.asc > /dev/null

echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

sudo apt-get update
sudo apt-get install -y jenkins
sudo systemctl status jenkins

Day 6 Master-Slave Distributed Architecture & Label-Restricted Builds

Running every build on a single Jenkins server exhausts CPU and RAM. In a Master-Slave (Controller-Agent) Architecture, the Jenkins Master manages scheduling and UI while offloading heavy build and testing workloads to remote Slave/Agent machines over SSH.

1. Preparing the Slave Node & Establishing SSH from Jenkins Master

# === On Jenkins Master ===
# Switch to jenkins user, generate SSH keys, and copy to the Slave Ubuntu node
sudo su - jenkins
whoami
ssh-keygen
ssh-copy-id ubuntu@
ssh ubuntu@

# === On Slave Node (Ubuntu) ===
# 1. Install Java (mandatory for Jenkins agent execution)
sudo apt-get update
sudo apt-get install -y openjdk-11-jdk
java -version

# 2. Download agent.jar / slave.jar from the Jenkins Master and set permissions
wget http://:8080/jnlpjars/slave.jar
chmod 777 slave.jar

# 3. Create a dedicated workspace directory for the agent
mkdir myfolder
cd myfolder
pwd
# Copy this path (e.g., /home/ubuntu/myfolder) for the Remote Root Directory

2. Registering the Slave Node in Jenkins Dashboard

1. Install the Command Agent Launcher plugin under Manage Jenkins → Plugins.
2. Go to Dashboard → Manage Jenkins → Nodes and Clouds → New Node.
3. Enter Node name slave1, select Permanent Agent, and click Create.
4. Configure the node settings:
   • Number of executors: Number of concurrent jobs that can run on the slave (e.g., 2).
   • Remote root directory: Paste the folder path from the slave (/home/ubuntu/myfolder).
   • Labels: myslave.
   • Launch method: Select Launch agent via execution of command on the controller.
   • Launch command: ssh ubuntu@172.31.9.219 java -jar /home/ubuntu/slave.jar
5. Pinning a Job to the Slave: Open your testing job → Configure → General → Restrict where this project can be run → enter Label Expression: myslave. Now development jobs run on Master and testing runs on the Slave!

Day 7 Pipeline as Code (Groovy): Scripted vs. Declarative Pipelines

Pipeline as Code defines your entire CI/CD workflow inside a single Groovy script (Jenkinsfile) instead of clicking through manual UI configurations.

• Version Controlled: Track pipeline changes in Git alongside application code.
• Disaster Recovery: Jobs are never lost even if the Jenkins server crashes.
• Bypass Heavy UI Plugins: Implement logic directly in Groovy code.
• Resilient Execution: Pipelines survive both planned and unplanned Jenkins restarts.

Scripted Pipeline vs. Declarative Pipeline Syntax

// === 1. Scripted Pipeline Skeleton ===
node('built-in') {
    stage('ContinuousDownload') {
        git 'https://github.com/cicdclouds/cicdclouds-javawebapp.git'
    }
    stage('ContinuousBuild') {
        sh 'mvn package'
    }
    stage('ContinuousDeployment') {
        // Use Pipeline Syntax Snippet Generator -> deploy: Deploy war/ear to a container
        deploy adapters: [tomcat9(credentialsId: 'tomcat-creds', path: '', url: 'http://172.31.16.84:8080')], contextPath: 'testapp', war: '**/*.war'
    }
    stage('ContinuousTesting') {
        git 'https://github.com/cicdclouds/cicdclouds-testwebapp.git'
        sh 'java -jar /var/lib/jenkins/workspace/scriptedpipeline1/testing.jar'
    }
    stage('ContinuousDelivery') {
        deploy adapters: [tomcat9(credentialsId: 'tomcat-creds', path: '', url: 'http://172.31.29.58:8080')], contextPath: 'prodapp', war: '**/*.war'
    }
}

Day 8 Complete Declarative Pipeline, Release Approvals, SCM Jenkinsfile & Webhooks

Build a complete 5-stage Declarative Pipeline featuring interactive Delivery Manager approval gates (input), store your Jenkinsfile in a remote Git repository, and trigger builds automatically via Poll SCM or GitHub Webhooks.

1. Full 5-Stage Declarative Pipeline with Manual Approval Gate

pipeline {
    agent any
    stages {
        stage('ContinuousDownload') {
            steps {
                git 'https://github.com/cicdclouds/cicdclouds-javawebapp.git'
            }
        }
        stage('ContinuousBuild') {
            steps {
                sh 'mvn package'
            }
        }
        stage('ContinuousDeployment') {
            steps {
                deploy adapters: [tomcat9(credentialsId: '8cc7d40a-bab0-438d-8dc2-f0d886815228', path: '', url: 'http://172.31.16.84:8080')], contextPath: 'test1', war: '**/*.war'
            }
        }
        stage('ContinuousTesting') {
            steps {
                git 'https://github.com/cicdclouds/cicdclouds-testwebapp.git'
                sh 'java -jar /home/ubuntu/.jenkins/workspace/DeclarativePipeline/testing.jar'
            }
        }
        stage('ContinuousDelivery') {
            steps {
                input message: 'Waiting for Approval from the DM!', submitter: 'adarsh'
                deploy adapters: [tomcat9(credentialsId: '8cc7d40a-bab0-438d-8dc2-f0d886815228', path: '', url: 'http://172.31.29.58:8080')], contextPath: 'prod1', war: '**/*.war'
            }
        }
    }
}

2. Pushing Jenkinsfile to Remote Git Repository (Pipeline Script from SCM)

# 1. Clone project repository and re-initialize for your own GitHub repo
git clone https://github.com/cicdclouds/cicdclouds-javawebapp.git
cd maven/
ls -a
rm -rf .git
git init

# 2. Create Jenkinsfile and paste your Declarative Pipeline code
vim Jenkinsfile

# 3. Stage, commit, and push to your remote GitHub repository using a Personal Access Token
git add .
git commit -m "Add production Jenkinsfile"
git branch -M main
git remote add origin https://github.com//.git
git push -u origin main

# 4. In Jenkins Job -> Configure -> Pipeline:
#    - Definition: Pipeline script from SCM
#    - SCM: Git
#    - Repository URL: https://github.com//.git
#    - Script Path: Jenkinsfile

3. Automated Build Triggers: Poll SCM vs. GitHub Webhook

• Poll SCM: In Job Configuration → Build Triggers → Poll SCM, enter * * * * *. Jenkins checks GitHub every minute and triggers a build only if new commits exist.
• GitHub Webhook (Event-Driven):
  1. In GitHub Repository → Settings → Webhooks → Add webhook.
  2. Set Payload URL to http://<JENKINS_PUBLIC_IP>:8080/github-webhook/ and Content type to application/json.
  3. In Jenkins Job → Build Triggers, check GitHub hook trigger for GITScm polling.

Day 9 Native SCP Artifact Deployment, SMTP Email Setup & Post Conditions

Instead of relying on the UI-based Deploy to container plugin, enterprise engineers often copy compiled .war artifacts directly into Tomcat's /var/lib/tomcat9/webapps/ folder over SSH using scp.

1. Configuring SSH & Folder Permissions for SCP Deployment

# 1. On QA and Prod Servers: Grant write permission on Tomcat webapps directory
sudo chmod o+w -R /var/lib/tomcat9/webapps/

# 2. On Jenkins Server (as jenkins user): Copy SSH keys to QA and Prod servers
sudo su - jenkins
ssh-keygen
ssh-copy-id ubuntu@172.31.7.30   # QA Server IP
ssh-copy-id ubuntu@172.31.7.247  # Prod Server IP

2. Scripted Pipeline Using Direct SCP Deployment

node('built-in') {
    stage('ContinuousDownload') {
        git 'https://github.com/cicdclouds/cicdclouds-javawebapp.git'
    }
    stage('ContinuousBuild') {
        sh 'mvn package'
    }
    stage('ContinuousDeployment') {
        sh 'scp /var/lib/jenkins/workspace/ScriptedPipeline2/webapp/target/webapp.war ubuntu@172.31.7.30:/var/lib/tomcat9/webapps/testapp.war'
    }
    stage('ContinuousTesting') {
        git 'https://github.com/cicdclouds/cicdclouds-testwebapp.git'
        sh 'java -jar /var/lib/jenkins/workspace/ScriptedPipeline2/testing.jar'
    }
    stage('ContinuousDelivery') {
        sh 'scp /var/lib/jenkins/workspace/ScriptedPipeline2/webapp/target/webapp.war ubuntu@172.31.7.247:/var/lib/tomcat9/webapps/prodapp.war'
    }
}

3. Declarative Pipeline with Post Conditions & SMTP Email Alerts

Configure Gmail SMTP under Manage Jenkins → System → E-mail Notification (SMTP server: smtp.gmail.com, Use SMTP Authentication, Use SSL, Port 465), then add a post block to your Declarative Pipeline:

pipeline {
    agent any
    stages {
        stage('ContinuousDownload') {
            steps {
                git 'https://github.com/cicdclouds/cicdclouds-javawebapp.git'
            }
        }
        stage('ContinuousBuild') {
            steps {
                sh 'mvn package'
            }
        }
        stage('ContinuousDeployment') {
            steps {
                deploy adapters: [tomcat9(credentialsId: '376e01e8-e628-40d2-aaec-6452f707a3ff', path: '', url: 'http://172.31.20.211:8080')], contextPath: 'qaapp', war: '**/*.war'
            }
        }
        stage('ContinuousTesting') {
            steps {
                git 'https://github.com/cicdclouds/cicdclouds-testwebapp.git'
                sh 'java -jar /home/ubuntu/.jenkins/workspace/DeclarativePipeline2/testing.jar'
            }
        }
    }
    post {
        success {
            input message: 'Required approvals', submitter: 'adarsh'
            deploy adapters: [tomcat9(credentialsId: '376e01e8-e628-40d2-aaec-6452f707a3ff', path: '', url: 'http://172.31.21.226:8080')], contextPath: 'myprodapp', war: '**/*.war'
        }
        failure {
            mail bcc: '', body: 'Continuous Integration is giving a failure msg', cc: '', from: '', replyTo: '', subject: 'CI Failed', to: 'selenium.saikrishna@gmail.com'
        }
    }
}

Day 10 Stage-Level Exception Handling (try / catch) & Team-Specific Alerts

A global post { failure } block only sends a generic failure email. By wrapping individual stages in try / catch(Exception e) blocks, you can route targeted failure alerts to the exact responsible team (Git Admin, Developers, Middleware, QA Testers, or Delivery Team).

1. Declarative Pipeline with Stage-Level Exception Handling

pipeline {
    agent any
    stages {
        stage('ContDownload') {
            steps {
                script {
                    try {
                        git 'https://github.com/cicdclouds/cicdclouds-javawebapp.git'
                    } catch(Exception e1) {
                        mail bcc: '', body: 'Jenkins is unable to download from GitHub', cc: '', from: '', replyTo: '', subject: 'Download Issue', to: 'git_admin@gmail.com'
                        exit(1)
                    }
                }
            }
        }
        stage('ContBuild') {
            steps {
                script {
                    try {
                        sh label: '', script: 'mvn package'
                    } catch(Exception e2) {
                        mail bcc: '', body: 'Jenkins is unable to create an artifact', cc: '', from: '', replyTo: '', subject: 'Build Issue', to: 'developers@gmail.com'
                        exit(1)
                    }
                }
            }
        }
        stage('ContDeployment') {
            steps {
                script {
                    try {
                        sh label: '', script: 'scp /var/lib/jenkins/workspace/DeclarativePipeline/webapp/target/webapp.war ubuntu@172.31.36.247:/var/lib/tomcat8/webapps/newtest1.war'
                    } catch(Exception e3) {
                        mail bcc: '', body: 'Jenkins is unable to deploy into the QA Servers', cc: '', from: '', replyTo: '', subject: 'Deployment Issue', to: 'middleware@gmail.com'
                        exit(1)
                    }
                }
            }
        }
        stage('ContTesting') {
            steps {
                script {
                    try {
                        git 'https://github.com/cicdclouds/cicdclouds-testwebapp.git'
                        sh label: '', script: 'echo "Testing Passed"'
                    } catch(Exception e4) {
                        mail bcc: '', body: 'Functional Testing has failed', cc: '', from: '', replyTo: '', subject: 'Testing Issue', to: 'testers@gmail.com'
                        exit(1)
                    }
                }
            }
        }
        stage('ContDelivery') {
            steps {
                script {
                    try {
                        sh label: '', script: 'scp /var/lib/jenkins/workspace/DeclarativePipeline/webapp/target/webapp.war ubuntu@172.31.35.219:/var/lib/tomcat8/webapps/prod.war'
                    } catch(Exception e5) {
                        mail bcc: '', body: 'Jenkins is unable to deploy into Prod servers', cc: '', from: '', replyTo: '', subject: 'Delivery Issue', to: 'delivery@gmail.com'
                        exit(1)
                    }
                }
            }
        }
    }
}

2. Scripted Pipeline with Exception Handling & CatLight Desktop Notifications

In a Scripted Pipeline, try / catch blocks are placed directly inside each stage without needing a script { } wrapper. Additionally, teams can install CatLight on their desktops to receive real-time tray notifications whenever a Jenkins build breaks.

Day 11 Jenkins Shared Libraries: Reusable User-Defined Groovy Functions

When dozens of microservices share the same CI/CD steps, duplicating Groovy code across every Jenkinsfile violates the DRY (Don't Repeat Yourself) principle. Jenkins Shared Libraries let you store reusable user-defined Groovy functions inside a central Git repository under the vars/ directory.

1. Creating a Shared Library in GitHub (vars/math.groovy & vars/cicd.groovy)

1. Create a public GitHub repository for your Shared Library and create a vars/ folder.
2. Create vars/math.groovy (for basic arithmetic functions) and vars/cicd.groovy (for reusable CI/CD stages).
3. Register the library in Manage Jenkins → System → Global Pipeline Libraries with Name: mylibrary, Default version: main (or master), and your Git repository URL.

// === File 1: vars/math.groovy ===
def sum(a, b) {
    echo "The sum of ${a} and ${b} is ${a + b}"
}
def sub(a, b) {
    echo "The subtraction of ${a} and ${b} is ${a - b}"
}
def mul(a, b) {
    echo "The product of ${a} and ${b} is ${a * b}"
}
def division(a, b) {
    echo "The division of ${a} and ${b} is ${a / b}"
}

// === File 2: vars/cicd.groovy ===
def newDownload(repo) {
    git "https://github.com/cicdclouds/${repo}"
}
def newBuild() {
    sh 'mvn package'
}
def newDeploy(jobname, ip, context) {
    sh "scp /var/lib/jenkins/workspace/${jobname}/webapp/target/webapp.war ubuntu@${ip}:/var/lib/tomcat9/webapps/${context}.war"
}
def runSelenium(jobname) {
    sh "java -jar /var/lib/jenkins/workspace/${jobname}/testing.jar"
}

2. Calling the Shared Library in Declarative & Scripted Pipelines

// === Declarative Pipeline Calling Shared Library (@Library) ===
@Library('mylibrary') _

pipeline {
    agent any
    stages {
        stage('ContDownload') {
            steps {
                script {
                    cicd.newDownload("maven.git")
                }
            }
        }
        stage('ContBuild') {
            steps {
                script {
                    cicd.newBuild()
                }
            }
        }
        stage('ContDeployment') {
            steps {
                script {
                    cicd.newDeploy("DeclarativePipelinewithSharedLibraries", "172.31.32.68", "testapp")
                }
            }
        }
        stage('ContTesting') {
            steps {
                script {
                    cicd.newDownload("FunctionalTesting.git")
                    cicd.runSelenium("DeclarativePipelinewithSharedLibraries")
                }
            }
        }
        stage('ContDelivery') {
            steps {
                script {
                    cicd.newDeploy("DeclarativePipelinewithSharedLibraries", "172.31.32.210", "prodapp")
                }
            }
        }
    }
}

// === Scripted Pipeline Calling Shared Library ===
@Library('mylibrary') _

node('built-in') {
    stage('ContDownload') {
        cicd.newDownload("maven.git")
    }
    stage('ContBuild') {
        cicd.newBuild()
    }
    stage('ContDeployment') {
        cicd.newDeploy("ScriptedPipelinewithsharedlibraries", "172.31.32.68", "testapp")
    }
    stage('ContTesting') {
        cicd.newDownload("FunctionalTesting.git")
        cicd.runSelenium("ScriptedPipelinewithsharedlibraries")
    }
    stage('ContDelivery') {
        cicd.newDeploy("ScriptedPipelinewithsharedlibraries", "172.31.32.210", "prodapp")
    }
}

Day 12 Multibranch Pipelines: Simultaneous Branch Discovery & Execution

A Multibranch Pipeline automatically discovers, manages, and executes pipelines for every branch in a Git repository that contains a Jenkinsfile. For example, your master branch can run the full 5-stage CI/CD pipeline while a feature branch like loans runs only the download and build stages.

Step-by-Step Git Multi-Branch Setup & Jenkins Configuration

# 1. Clone the base Maven repository and initialize a fresh Git repo
git clone https://github.com/cicdclouds/cicdclouds-javawebapp
cd maven/
ls -la
rm -rf .git
git init

# 2. Create Jenkinsfile on the main/master branch with the full 5-stage Shared Library pipeline
vim Jenkinsfile
git add .
git commit -m "Full CI-CD Jenkinsfile on master branch"

# 3. Create and switch to a new feature branch 'loans'
git checkout -b loans

# 4. Edit Jenkinsfile on 'loans' branch to execute ONLY ContinuousDownload
vim Jenkinsfile
git add .
git commit -m "Download-only Jenkinsfile on loans branch"

# 5. Push all branches to your remote GitHub repository
git remote add origin https://github.com//.git
git push -u origin --all

1. Go to Jenkins Dashboard → New Item, enter a name, select Multibranch Pipeline, and click OK.
2. Under Branch Sources → Add source → Git, paste your repository URL.
3. Under Build Configuration, ensure Mode is set to by Jenkinsfile and Script Path is Jenkinsfile.
4. Click Save. Jenkins automatically scans the repository, detects both master and loans branches, and executes each branch's customized Jenkinsfile simultaneously!