What is Jenkins? CI/CD Automation Explained

Jenkins is an open-source automation server that has powered CI/CD pipelines at thousands of organisations for over a decade. Originally forked from Hudson in 2011, it became the default answer to "how do we automate builds and deployments?" before cloud-native alternatives existed. In 2026 it remains widely deployed -- particularly in enterprise environments -- though the landscape around it has changed significantly.

Understanding Jenkins means understanding CI/CD as a practice: the principle that code changes should be automatically built, tested, and deployed rather than handled manually by humans running scripts.

How Jenkins Works

Jenkins runs as a Java application on a server you control. It listens for trigger events -- a Git push, a webhook, a scheduled cron -- and responds by executing a pipeline. Pipelines are defined in a Jenkinsfile checked into your repository alongside your application code. This is called pipeline-as-code, and it means your CI/CD logic is versioned, reviewed, and auditable like any other code.

Jenkins distributes work using a controller/agent model. The controller node orchestrates jobs and stores configuration. Agent nodes (also called workers) do the actual build work. You can run agents on physical servers, VMs, Docker containers, or Kubernetes pods.

Declarative vs Scripted Pipelines

Jenkins supports two pipeline syntaxes. Declarative pipelines use a structured, opinionated syntax designed for readability. Scripted pipelines give you the full power of Groovy but require more discipline to keep maintainable. For most teams starting today, declarative is the right choice.

Here is a practical Jenkinsfile for a Node.js application:

pipeline {
  agent {
    docker {
      image 'node:20-alpine'
      args '-u root'
    }
  }

  environment {
    IMAGE_NAME = "myapp"
    REGISTRY   = "123456789.dkr.ecr.eu-west-1.amazonaws.com"
  }

  stages {
    stage('Install') {
      steps {
        sh 'npm ci'
      }
    }

    stage('Test') {
      steps {
        sh 'npm test -- --ci --coverage'
      }
      post {
        always {
          junit 'coverage/junit.xml'
        }
      }
    }

    stage('Build Image') {
      when {
        branch 'main'
      }
      steps {
        sh """
          docker build -t ${IMAGE_NAME}:${BUILD_NUMBER} .
          docker tag ${IMAGE_NAME}:${BUILD_NUMBER} ${REGISTRY}/${IMAGE_NAME}:${BUILD_NUMBER}
        """
      }
    }

    stage('Push') {
      when {
        branch 'main'
      }
      steps {
        withCredentials([string(credentialsId: 'ecr-token', variable: 'ECR_TOKEN')]) {
          sh """
            echo ${ECR_TOKEN} | docker login --username AWS --password-stdin ${REGISTRY}
            docker push ${REGISTRY}/${IMAGE_NAME}:${BUILD_NUMBER}
          """
        }
      }
    }
  }

  post {
    failure {
      slackSend channel: '#deployments', message: "Build failed: ${BUILD_URL}"
    }
  }
}

The when { branch 'main' } directive means the image build and push only run on the main branch -- feature branches run tests only. The withCredentials block pulls secrets from Jenkins's credential store rather than hardcoding them in the file.

Jenkins vs GitHub Actions

The honest comparison: Jenkins requires you to run and maintain a server. GitHub Actions does not. For a team of 2--5 engineers building a new product, that operational cost is rarely worth it. For a 50-engineer org with complex multi-repo pipelines, shared libraries, and fine-grained permission requirements, Jenkins's flexibility can be worth the overhead.

Jenkins wins on plugin ecosystem -- there are over 1,800 plugins covering almost every integration imaginable. It also handles fan-out orchestration well: triggering builds across multiple repositories in sequence or parallel, something GitHub Actions handles only awkwardly. Jenkins pipelines can also be parameterised interactively, which makes it useful for manual deployment workflows.

GitHub Actions wins on zero operational overhead, native GitHub integration, and a fast learning curve. See the GitHub Actions entry for a direct comparison.

When to Use Jenkins vs Modern CI Tools

Use Jenkins when: your organisation already runs it and migration cost is high; you need complex multi-pipeline orchestration with shared libraries; you have compliance requirements that mandate self-hosted CI; or you need fine-grained control over the build environment.

Consider alternatives when: you are starting from scratch; your team is small; you use GitHub and want native integration; or operational overhead is a concern.

Jenkins is part of the DevOps tools landscape that every practitioner should understand, even if they choose a different tool for their own pipelines.

Frequently Asked Questions