Jenkins pipelines

What Jenkins is

Jenkins is an open-source automation server written in Java. It started in 2011 (as a fork of an older tool called Hudson) and is one of the oldest CI tools still in wide use. Unlike GitHub Actions, you host it yourself: on a VM, in a container, or on Kubernetes. That gives you full control, and full responsibility.

Controller and agents

The controller is the central Jenkins server. It stores job settings and build history, serves the web UI, and decides which build runs where. Agents (also called nodes) are the machines that actually run builds; each has a number of executors, which are slots for builds running at the same time. Agents can be permanent VMs, or created on demand as containers or Kubernetes pods.

Jobs: freestyle versus pipeline

A freestyle job is configured by clicking through forms in the web UI. It is quick to start but hard to review, copy or version. A Pipeline job is defined in code, in a file called Jenkinsfile, written in a Groovy-based language. There are two styles: declarative (a fixed, readable structure) and scripted (full Groovy code). Start with declarative.

pipeline {
    agent { label 'linux' }                      // run on an agent with this label

    environment {
        APP = 'shop-api'
        REGISTRY = credentials('registry-creds') // username and password from the Jenkins store
    }

    options {
        timeout(time: 30, unit: 'MINUTES')
    }

    stages {
        stage('Checkout') {
            steps { checkout scm }
        }
        stage('Install and test') {
            steps {
                sh 'npm ci'
                sh 'npm test'
            }
        }
        stage('Build image') {
            steps {
                sh "docker build -t registry.example.com/${APP}:${env.GIT_COMMIT} ."
            }
        }
        stage('Push image') {
            when { branch 'main' }
            steps {
                sh 'echo "$REGISTRY_PSW" | docker login registry.example.com -u "$REGISTRY_USR" --password-stdin'
                sh "docker push registry.example.com/${APP}:${env.GIT_COMMIT}"
            }
        }
        stage('Approve production') {
            when { branch 'main' }
            steps { input message: 'Deploy to production?' }
        }
    }

    post {
        always  { junit 'reports/**/*.xml' }     // publish test results every time
        success { echo 'Pipeline passed' }
        failure { echo 'Pipeline failed: tell the team' }
    }
}

Reading it from top to bottom: pipeline wraps everything. agent says where to run. environment sets variables; credentials('registry-creds') reads a stored username and password and also creates REGISTRY_USR and REGISTRY_PSW. stages holds the stage blocks, each with steps such as sh (run a shell command). when runs a stage only in some cases. post runs after the stages: always, on success, or on failure.

Plugins, multibranch pipelines and webhooks

Most Jenkins features come from plugins: Git, Pipeline, Credentials, Kubernetes agents, JUnit reports and around two thousand more. A multibranch pipeline job scans a repository, finds every branch and pull request that has a Jenkinsfile, and creates a pipeline for each. A webhook is a message GitHub, GitLab or Bitbucket sends to Jenkins on every push, so builds start at once instead of Jenkins checking (polling) the repository every few minutes.

When teams choose Jenkins, and what it costs

• Chosen for: running fully inside a company network (common in Indian banks and insurers with strict data rules), huge flexibility, many existing pipelines, and no per-minute fees.
• Costs: someone must patch Jenkins and its plugins, back up its home folder, scale agents and handle plugin conflicts. Plugins are a common source of security advisories, so keep them few and up to date.