Jenkins Explained: The Original CI/CD Workhorse

Introduction

Before GitHub Actions (the batch 13 post) and GitLab CI (the batch 23 post) made pipelines a checkbox, there was Jenkins: an open-source automation server, released in 2011, that has run builds, tests, and deployments for a generation of teams. It is older, rougher around the edges, and still everywhere — especially in enterprises with strict security rules or unusual build environments. Understanding Jenkins explains the CI/CD idea in its purest form: a server that watches your code and runs jobs for you.

Pipelines as code, agents, and plugins

Jenkins organises automation around three ideas:

• Jobs and pipelines — a pipeline is a sequence of stages (build, test, deploy) defined in a Jenkinsfile stored in the repo, so the pipeline versions with the code, like GitLab's .gitlab-ci.yml.
• Agents — the work runs on agents (build machines), which can be local, cloud, or Docker containers, so one Jenkins controller orchestrates many environments.
• Plugins — over a thousand plugins connect Jenkins to nearly everything: Git, Docker, Kubernetes, Slack, cloud providers, and test tools. If a tool exists, a Jenkins plugin probably talks to it.

A declarative pipeline shows the shape — stages, steps, and an agent, all in the repo:

pipeline {
    agent any
    stages {
        stage('Test') {
            steps {
                sh 'npm test'
            }
        }
        stage('Deploy') {
            steps {
                sh './deploy.sh'
            }
        }
    }
}

Push code, Jenkins detects it, the pipeline runs, and the team sees green or red — the CI/CD loop in its classic form.

The honest trade

Jenkins's trade is maintenance: you run the server, update plugins, manage security, and debug Groovy pipeline quirks yourself — hosted CI (GitHub Actions, GitLab CI) removes that burden entirely. Its interface also shows its age. But Jenkins wins where hosted CI cannot go: air-gapped networks, custom hardware, legacy systems, and organisations that must keep build infrastructure in-house. The rule of thumb: hosted CI for most new projects; Jenkins when control, self-hosting, or exotic environments demand it.

Takeaway

Jenkins is the original CI/CD workhorse: pipelines as code in a Jenkinsfile, agents running the work, and plugins connecting everything. It trades convenience for control — and for teams that need that control, it remains the right tool.

Originally published at https://practicaldevblog.blogspot.com/2026/10/jenkins-explained-original-cicd.html