Build a CI/CD Pipeline with Jenkins: Practical Tutorial

By Khimananda Oli | Last reviewed: August 2026

Automating software delivery is the difference between shipping weekly and shipping on demand, yet many teams still struggle to build a CI/CD pipeline with Jenkins that is both reliable and maintainable. While newer tools exist, Jenkins remains the industry standard for complex, customizable automation due to its massive plugin ecosystem and flexibility. This guide moves beyond basic "Hello World" examples to show you how to architect a production-grade pipeline using Declarative syntax, ephemeral Docker agents, and secure credential handling.

How do you architect a secure Jenkins CI/CD pipeline?

A common mistake I see when teams first evaluate CI/CD tools or migrate legacy scripts is treating the Jenkins controller as a build server. In 2026, the controller should only orchestrate; it must never execute builds directly. Architecting for security and scalability requires separating concerns strictly.

Your pipeline architecture should follow three non-negotiable principles:

• Ephemeral Agents: Every build runs in a fresh container. This eliminates "it works on my machine" issues caused by leftover state from previous builds.
• Pipeline as Code: The entire workflow lives in a Jenkinsfile committed to your repository. Configuration via the web UI is forbidden for production jobs because it cannot be audited or rolled back.
• Least Privilege Execution: Agents receive only the specific credentials needed for their current stage, injected at runtime and masked in logs.

How do you write a robust Declarative Jenkinsfile?

Declarative Pipeline syntax provides a structured, opinionated way to define workflows. It enforces validation before execution and integrates cleanly with Blue Ocean and other visualization tools. When you build a CI/CD pipeline with Jenkins, always prefer Declarative over Scripted unless you have a specific metaprogramming requirement.

Defining stages and Docker agents

The following example demonstrates a modern pipeline structure. Note the use of specific image tags—never use :latest in production pipelines, as it breaks reproducibility.

pipeline {
    agent none

    environment {
        APP_NAME = 'my-service'
        REGISTRY = 'registry.example.com'
    }

    stages {
        stage('Test') {
            agent {
                docker {
                    image 'node:20-alpine'
                    args '-v /tmp:/tmp'
                }
            }
            steps {
                sh 'npm ci'
                sh 'npm run test:unit'
            }
        }

        stage('Build & Push') {
            agent {
                docker {
                    image 'docker:24-dind'
                    args '--privileged'
                }
            }
            steps {
                script {
                    def tag = "${env.BUILD_NUMBER}-${env.GIT_COMMIT.take(7)}"
                    sh "docker build -t ${REGISTRY}/${APP_NAME}:${tag} ."
                    withCredentials([usernamePassword(credentialsId: 'registry-creds', usernameVariable: 'USER', passwordVariable: 'PASS')]) {
                        sh "echo $PASS | docker login ${REGISTRY} -u $USER --password-stdin"
                        sh "docker push ${REGISTRY}/${APP_NAME}:${tag}"
                    }
                }
            }
        }
    }

    post {
        always {
            cleanWs()
        }
        failure {
            echo 'Pipeline failed. Check logs above.'
        }
    }
}

This configuration uses agent none at the top level, which forces each stage to declare its own execution environment. This prevents wasting resources on idle containers during stages that don't need them and allows mixing different tech stacks (e.g., Node for testing, Docker-in-Docker for building) within a single pipeline.

How do you manage secrets and credentials safely?

Credential mismanagement is the leading cause of security incidents in CI/CD systems. Never hardcode passwords, API keys, or SSH private keys in your Jenkinsfile or environment variables defined in the UI. Instead, leverage the Credentials Binding Plugin and Jenkins Credentials Store.

1. Store centrally: Add credentials via Manage Jenkins → Credentials. Use scoped credentials (folder-level) to limit access between teams.
2. Inject dynamically: Use withCredentials blocks to bind secrets only for the duration of specific shell commands.
3. Mask automatically: Jenkins automatically redacts bound variables from console output. However, avoid echoing variables or writing them to files that might be archived as artifacts.
4. Rotate regularly: Treat CI/CD credentials like production secrets. Implement rotation schedules and audit usage via the Credentials Usage report.

For infrastructure provisioning tasks within your pipeline, consider integrating external secret managers rather than storing cloud provider keys directly in Jenkins. If you are deploying infrastructure alongside your application, referencing patterns from Infrastructure as Code with Terraform ensures your pipeline secrets align with your state management strategy.

What are the essential Jenkins plugins in 2026?

Jenkins core is minimal; functionality comes from plugins. Installing too many creates maintenance debt, but skipping essentials cripples usability. Based on current production environments, these are the non-negotiable plugins for any team learning how to build a CI/CD pipeline with Jenkins:

Avoid installing plugins solely for convenience features if they duplicate existing functionality. Each plugin increases your attack surface and upgrade complexity. Audit your plugin list quarterly and remove anything unused.

How do you optimize pipeline performance and reliability?

Slow pipelines kill developer productivity. After helping multiple organizations reduce build times by 40–60%, I've found that optimization usually comes down to caching, parallelization, and right-sizing agents.

Implement dependency and layer caching

Docker builds benefit enormously from BuildKit cache mounts. Instead of reinstalling dependencies every run, mount the package manager cache directory:

stage('Build') {
    agent { docker { image 'docker:24-dind' } }
    steps {
        sh '''
            DOCKER_BUILDKIT=1 docker build \
              --build-arg BUILDKIT_INLINE_CACHE=1 \
              --cache-from ${REGISTRY}/${APP_NAME}:cache \
              --target production \
              -t ${REGISTRY}/${APP_NAME}:${TAG} .
        '''
    }
}

For non-containerized builds, use the stash/unstash steps or workspace caching plugins to preserve node_modules, vendor, or compiled binaries between stages. Network I/O for dependency resolution is often the single largest time sink.

Parallelize independent stages

Wrap independent stages in a parallel block. Unit tests, linting, and static analysis can typically run simultaneously. This doesn't reduce total compute cost, but it dramatically reduces wall-clock feedback time for developers waiting on merge checks.

How do you handle deployment approvals and rollbacks?

Continuous delivery doesn't mean unattended deployment to production. Mature pipelines include explicit gates and automated rollback capabilities. Use the input step to pause execution until manual approval is granted:

stage('Deploy to Production') {
    when { branch 'main' }
    options { timeout(time: 1, unit: 'HOURS') }
    input {
        message "Deploy ${APP_NAME}:${TAG} to production?"
        ok "Deploy"
        submitter "release-approvers"
    }
    steps {
        sh "./deploy.sh production ${TAG}"
    }
}

Always pair deployment steps with health checks and rollback logic. If your target platform supports it (like Kubernetes), integrate readiness probes into your deployment script. For traditional VPS deployments, ensure you have a verified rollback procedure before automating forward deployments. Teams managing Laravel applications on Ubuntu servers will find relevant patterns in guides on zero-downtime deployment strategies that complement Jenkins orchestration.

Track deployment metadata. Tag successful builds in your artifact registry and record which commit SHA corresponds to each production release. When incidents occur, this traceability reduces mean-time-to-resolution significantly.

Next Steps for Your Jenkins Pipeline

You now have the architectural foundation to build a CI/CD pipeline with Jenkins that meets 2026 production standards. Start with the Declarative template provided, enforce Docker agent isolation from day one, and treat your Jenkinsfile as first-class application code subject to review and testing. Avoid the temptation to over-engineer early; get a reliable green build flowing before adding advanced matrix builds or custom shared libraries.

If your team needs help designing compliant, scalable Jenkins infrastructure or migrating from fragile legacy setups, reach out to discuss your specific requirements. Whether you're optimizing for SOC 2 audit readiness or simply trying to cut build times in half, getting the foundation right prevents costly rework later.