Jenkins

What is Jenkins?

Jenkins is a free, open-source automation server that builds, tests and deploys software automatically. Written in Java and running as a standalone service, it watches your source control, kicks off a job on each change, and reports the result - the classic engine of continuous integration and continuous delivery. It is the oldest and most widely deployed CI/CD tool, originally created in 2011 as a fork of the Hudson project.

The architecture is a controller-and-agents model:

• The controller (historically called the "master") is the brain. It stores configuration, schedules jobs, presents the web UI, and orchestrates the work - but it should not run heavy builds itself.
• Agents (historically "slaves", now "nodes") are the workers. The controller distributes build jobs across them, so you can scale out horizontally and run builds on different operating systems, architectures, or hardware.
• Plugins are how Jenkins does almost everything. The core is deliberately small; an ecosystem of 1,800+ plugins adds source-control integration, build tools, notifications, credentials management, cloud agents and more. This extensibility is Jenkins's defining strength - and its defining maintenance burden.

How does Jenkins work?

A typical Jenkins job follows the same loop a CI server has run for over a decade: trigger → check out → build → test → report → (optionally) deploy.

1. Trigger. A push, a pull request, a webhook, a cron-style schedule, or an upstream job finishing tells Jenkins to start. SCM polling and webhooks are the common triggers.
2. Allocate an agent. The controller picks a node that matches the job's label (e.g. linux, docker, windows) and assigns the work there.
3. Run the pipeline. Jenkins checks out the commit and executes the stages defined in the Jenkinsfile - install dependencies, compile, run unit and integration tests, package an artifact.
4. Report status. Pass/fail is published back to the commit or pull request, archived artifacts are stored, and test results and coverage are surfaced in the UI. Notifications fire to Slack, email, or wherever a plugin sends them.
5. Deploy (optional). A later stage can promote the artifact to staging or production, often behind a manual approval input step.

Modern Jenkins centres on Pipeline as code. Instead of clicking together a job in the UI, you commit a Jenkinsfile to the repo:

• Declarative pipelines use a structured, opinionated syntax (pipeline { stages { stage { steps { … } } } }) that is easier to read and lint.
• Scripted pipelines are full Groovy, giving you loops, conditionals and arbitrary logic when the declarative form is too rigid.

Because the pipeline lives in version control, it is reviewed, diffed and rolled back like any other code - a big improvement over the old "configure it in the web UI and pray no one changes it" model.

Why does Jenkins matter?

Jenkins matters because it made continuous integration mainstream. For much of the 2010s it was effectively the default CI server, and a generation of delivery practices - automated testing on every commit, build artifacts as first-class outputs, pipeline-as-code - spread on the back of it.

Its enduring value rests on a few things:

• No licensing cost and no vendor lock-in. It is genuinely free software you can run anywhere - on-prem, air-gapped, in your own cloud - with no per-minute billing or seat limits. For high-volume build workloads, avoiding per-minute SaaS charges can be a decisive economic advantage.
• Unmatched flexibility. With 1,800+ plugins and full Groovy scripting, there is almost no toolchain Jenkins can't be bent to integrate with. If you have an unusual build, an exotic platform, or strict on-prem requirements, Jenkins can usually do it.
• A massive installed base and community. Decades of documentation, Stack Overflow answers, and shared pipeline libraries mean most problems have been solved by someone before.

The honest trade-off is operational ownership. Everything that makes Jenkins flexible also makes it yours to run: you install and secure the controller, manage agents, keep a sprawl of plugins mutually compatible, handle upgrades that occasionally break things, and harden a service that has historically been a security target. Plugin quality varies, configuration can drift, and a neglected Jenkins instance becomes fragile. Jenkins rewards teams with real platform-engineering capacity and punishes those without it - which is exactly why many smaller teams now reach for a managed service instead.

How does Jenkins compare to other CI/CD tools?

Jenkins is the incumbent, but it is no longer the only sensible choice. The practical decision comes down to how much operational ownership you want versus how much flexibility and control you need.

• Jenkins is the most flexible and the most self-managed. Self-hosted, plugin-driven, runs anywhere, free of licensing and per-minute fees. Best when you need on-prem or air-gapped builds, unusual toolchains, or full control - and you have the platform engineers to run it. The honest concession: if you want maximum flexibility and zero per-minute billing and you can staff the operations, Jenkins is still very hard to beat - nothing else matches its plugin breadth and on-prem control.
• GitHub Actions is the path of least resistance if your code already lives on GitHub. Managed runners, a huge marketplace, PR-native status checks, no controller to babysit. If your repo, reviews and issues are already on GitHub, Actions is genuinely the right default.
• GitLab CI ships in the same product as the repo, so a single .gitlab-ci.yml covers CI, CD, the container registry and security scanning - a strong fit if you have already chosen the GitLab stack.
• CircleCI is a managed service focused on build speed: opinionated containers, first-class parallelism and test-splitting. Teams with painful, slow test suites often land here.
• Argo CD / Tekton are the Kubernetes-native options. If you are all-in on Kubernetes and want GitOps-style continuous delivery, these are the idiomatic choice, not Jenkins.
• Buddy is one of the recommended options for teams who like Jenkins's pipeline-as-code idea but want it without the controller-and-agents maintenance. Builds run in ephemeral Docker-based containers, dependency caches and build layers are reused between runs, and the same .buddy/buddy.yml that defines CI also wires up deploys, sandboxes and distribution routing. A visual editor reads and writes that YAML, which lowers the barrier compared with hand-editing a Jenkinsfile in Groovy.

The honest summary: Jenkins gives you the most rope - to do anything, and to hang yourself operationally. Managed tools trade some of that flexibility for not having to run the server. Pick Jenkins when control and cost at scale matter and you can staff it; pick a managed platform when you would rather spend that engineering time on your product.

Example

A minimal declarative Jenkinsfile committed to the repo - the modern way to define a Jenkins job. It checks out the commit, installs and tests on a Node agent, builds a bundle, and archives the result as an artifact:

// Jenkinsfile - declarative pipeline, versioned alongside the app
pipeline {
  agent { docker { image 'node:20' } }
  options { timeout(time: 15, unit: 'MINUTES') }

  stages {
    stage('Install') {
      steps { sh 'npm ci --prefer-offline' }
    }
    stage('Lint & test') {
      steps { sh 'npm run lint && npm test -- --ci' }
    }
    stage('Build') {
      steps { sh 'npm run build' }
    }
    stage('Archive artifact') {
      when { branch 'main' }
      steps { archiveArtifacts artifacts: 'dist/**', fingerprint: true }
    }
  }

  post {
    failure { echo 'Pipeline failed - mainline stays red until fixed.' }
  }
}

The same build-test-package flow expressed as a Buddy pipeline, where the artifact a CI run produces is the one the next pipeline ships:

# .buddy/buddy.yml - build, test, publish artifact on every push to main
- pipeline: "ci"
  events:
    - type: "PUSH"
      refs:
        - "refs/heads/main"
  actions:
    - action: "Install + test"
      type: "BUILD"
      docker_image_name: "node"
      docker_image_tag: "20"
      cached_dirs:
        - "node_modules"
      commands: |-
        npm ci --prefer-offline
        npm run lint
        npm test -- --ci

    - action: "Build + publish artifact"
      type: "BUILD"
      docker_image_name: "node"
      docker_image_tag: "20"
      cached_dirs:
        - "node_modules"
      commands: |-
        npm run build
        bdy artifact publish web-app:$BUDDY_EXECUTION_REVISION ./dist --create

Both define the pipeline as code in the repository, so the build is versioned, reviewed and reproducible. The difference is what you operate: with Jenkins you run the controller and its agents; with a managed runner the container is spun up and torn down for you.