Jenkins

Jenkins is a long-established, self-hosted automation server. It is flexible, but you run it yourself, which shapes most decisions about it.

How it works

A Jenkins installation has a controller and one or more agents. The controller is the service that holds configuration, handles authentication and authorisation, and decides what runs where. Agents are small Java processes on separate machines that carry out the work. The Jenkins documentation discourages running builds on the controller’s built-in node for security, performance and scalability reasons, and describes setting its executors to 0.

Pipelines are defined in a text file called a Jenkinsfile, normally stored in the root of the repository so the pipeline is versioned and reviewed with the code. Declarative syntax uses a structured pipeline block. Scripted syntax is Groovy-based and more flexible but harder to maintain. Functionality beyond the core comes from plugins.

A practical example

A minimal declarative pipeline, taken from the pattern in the official documentation:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Building...'
            }
        }
    }
}

The agent directive allocates an executor and workspace, and each stage groups steps. Real pipelines add test, scan and deploy stages, and usually target agents by label.

Common mistakes

• Running builds on the controller, which exposes credentials and degrades the service for everyone.
• Treating plugins as free. Each one adds upgrade and compatibility work, and an unmaintained plugin becomes a risk.
• Configuring jobs through the web UI only, so the setup cannot be reviewed or rebuilt.
• Sharing long-lived agents with state left in workspaces, which makes builds hard to reproduce.
• Having no plan for controller backup and recovery.

When to use it and when not to

Jenkins suits environments with complex legacy requirements, air-gapped or on-premises networks, or deep integration with internal tooling. Teams that want less operational overhead often prefer a hosted option such as GitHub Actions or GitLab CI. If you are weighing a move, the Jenkins migration plan outlines how such work can be approached.

See also

• CI/CD
• GitHub Actions
• GitLab CI
• Docker
• Jenkins consulting