Day 26: Jenkins Declarative Pipeline

This content originally appeared on DEV Community and was authored by Udoh Deborah

Day 26 is all about stepping up from Freestyle Projects to Jenkins Pipelines, which is the real deal in CI/CD. Let me walk you through it step by step:

• Pipeline: This is a powerful concept in continuous integration and continuous delivery (CI/CD). Think of it like an automated assembly line for your software. Each step—like building the code, running tests, and deploying the app—is a station on the line, and the pipeline ensures they all happen in the correct order, every time.

Declarative Pipeline: This is the modern, recommended way to write a Jenkinsfile. It uses a structured syntax that’s easy to read and understand, and it gives you a lot of built-in features. It’s like using a pre-defined template for your pipeline; you just fill in the blanks, which makes the code more maintainable.

• Scripted Pipeline: This is the older, more flexible style. It uses Groovy scripting, which gives you complete control over every aspect of the pipeline. It’s like writing a program from scratch; you can do anything you want, but it requires more coding knowledge and can be harder to maintain for complex projects.

Here’s a quick analogy:

• Declarative pipeline is like following a recipe to bake a cake The steps and ingredients are clearly laid out.
• Scripted pipeline is like being a master chef, free to improvise and create a cake from scratch with no set recipe.

Both have their uses, but for most modern projects, the Declarative approach is preferred for its simplicity and readability.

The Big Picture

Why you should have a Pipeline

When you define your pipeline in a Jenkinsfile and commit it to your source code repository, you’re treating the automation of your software’s delivery as a first-class citizen—just like your application code itself. It’s like creating a permanent, versioned blueprint for how your software is built and deployed.

This approach offers two major advantages:

Automatic Branch and PR Builds:

By keeping the Jenkinsfile in your repository, you don’t have to manually create and configure a new Jenkins job every time a developer creates a new branch or a pull request. Jenkins can be configured to automatically discover these new branches and run the pipeline defined in the Jenkinsfile. This is crucial for:

Speed: Developers get instant feedback on their changes without waiting for a manual setup.

Consistency: Every branch and PR is built and tested using the exact same process, eliminating “it worked on my machine” issues.

Collaborative Code Review:

Since the pipeline is just another file in your repository, it can be reviewed, changed, and improved by the entire team, just like any other code. This means:

• Visibility: Everyone on the team can see and understand how the application is built and deployed.

• Quality: You can make sure the pipeline follows best practices and is error-free by catching issues in a code review before they break the build.

• Version Control: You have a complete history of all changes made to your build process, so you can easily revert to a previous working version if something goes wrong.

In short, Pipeline as Code makes your build and deployment process reliable, transparent, and a shared responsibility for the entire team. It’s a fundamental concept in modern DevOps.

Step-by-Step Guide: Jenkins Declarative Pipeline

1. Create a Jenkins Pipeline Job

• Log in to Jenkins.
• Click New Item → Enter a job name (e.g., pipeline-hello-world).
• Select Pipeline (not Freestyle).
• Click OK.

2. Add Pipeline Script

In the job configuration:

• Scroll down to the Pipeline section.
• Select Pipeline script (for quick demo) OR Pipeline script from SCM (if you want Jenkinsfile inside GitHub repo).
• Paste the Hello World Declarative Pipeline example:

pipeline {
    agent any 

    stages {
        stage('Build') {
            steps {
                echo 'Building the application...'
            }
        }
        stage('Test') {
            steps {
                echo 'Running tests...'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying the application...'
            }
        }
    }
}

3. Save & Run

• Click Save.
• Click Build Now.
• Open the console output → You should see:

   Building the application...
   Running tests...
   Deploying the application...

This is the Jenkins “Hello World” Declarative Pipeline in action.

4. (Optional) Store Jenkinsfile in GitHub

Instead of pasting directly in Jenkins, you can:

• Create a file called Jenkinsfile in your repo:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Building...'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing...'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying...'
            }
        }
    }
}

• Push it to GitHub.

• In Jenkins → Job config → Select Pipeline script from SCM → Point to your repo.

Now Jenkins will always run the pipeline defined in your repo’s Jenkinsfile.

Why This Matters

• Freestyle projects = manual + UI-driven.
• Pipelines = automated + stored as code.
• You now treat your CI/CD pipeline like code → versioned, reviewed, and repeatable.

This content originally appeared on DEV Community and was authored by Udoh Deborah