Jenkins Explained: The Original CI/CD Workhorse

Introduction

Before GitHub Actions and GitLab CI 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 requirements 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, while 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. Choose hosted CI for most new projects, and choose Jenkins when control, self-hosting, or exotic environments demand it.

CI/CD, the original way

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