Introduction to Jenkins
The original CI/CD automation server — still everywhere in the enterprise.
Before GitHub Actions and GitLab CI, there was Jenkins — the open-source automation server that popularised continuous integration. It’s self-hosted, endlessly extensible, and still runs the pipelines of a huge number of companies. Knowing Jenkins is a genuine advantage in the job market.
🎯 Learning Objectives
By the end of this lesson you will:
- Understand what Jenkins is and what it automates
- Know the controller/agent architecture
- Understand plugins and why they matter
- Compare Jenkins with cloud-native CI like GitHub Actions
What is Jenkins?
Jenkins is a self-hosted automation server. You install it on your own infrastructure, and it runs jobs and pipelines: building code, running tests, deploying releases — triggered by code changes, schedules, or manual clicks.
💡 The one-line version
Jenkins is a server you run yourself that automates the build-test-deploy cycle. Its superpower is flexibility — thousands of plugins let it integrate with almost anything.
Controller / Agent Architecture
Jenkins scales by separating the brain from the muscle:
┌─────────── Controller ───────────┐
│ schedules jobs, stores config, │
│ serves the web UI │
└──────────────┬────────────────────┘
│ dispatches work
┌──────────────┼──────────────┐
Agent 1 Agent 2 Agent 3
(runs builds) (runs builds) (runs builds)| Component | Role |
|---|---|
| Controller (master) | Orchestrates jobs, stores configuration, serves the UI. Shouldn’t run heavy builds itself. |
| Agent (node) | Executes the actual build work, on separate machines. |
This lets you run many builds in parallel across many machines, and use agents with different environments (Linux, Windows, GPU, etc.).
Plugins — Jenkins’ Superpower (and Caveat)
Jenkins itself is a small core; nearly all capability comes from plugins — over 1,800 of them. Git integration, Docker, Kubernetes, cloud deploys, notifications: all plugins.
⚠ Plugins are power and risk
Plugins make Jenkins do almost anything, but they’re also its biggest maintenance burden: version conflicts, security updates, and occasional breakage. Keep plugins minimal and updated — treat them as dependencies you must maintain.
Jenkins vs Cloud-Native CI
| Jenkins | GitHub Actions | |
|---|---|---|
| Hosting | You host and maintain it | Fully managed by GitHub |
| Setup | More involved | Minimal — it’s built in |
| Flexibility | Extreme (plugins, any environment) | High, within GitHub’s model |
| Cost | Your infrastructure | Included / usage-based |
| Best for | Complex, on-prem, highly customised needs | Projects already on GitHub |
💡 Why learn both?
Cloud CI is simpler for new projects, but Jenkins runs deeply entrenched enterprise pipelines and works anywhere — including air-gapped, on-prem environments. Many DevOps roles still list Jenkins as a requirement.
See It Yourself
The quickest way to try Jenkins is with Docker:
docker run -d --name jenkins \
-p 8080:8080 -p 50000:50000 \
-v jenkins_home:/var/jenkins_home \
jenkins/jenkins:ltsOpen http://localhost:8080, paste that initial password, and you’re in — the volume keeps your setup across restarts.
🧪 Hands-on Lab
Run Jenkins Locally
- Start the official Jenkins LTS container with a persistent volume
- Retrieve the initial admin password from the logs
- Explain why the controller shouldn’t run heavy builds itself
🧠 Knowledge Check
In Jenkins' architecture, what is the role of an agent?
Where does most of Jenkins' functionality come from?
💼 Interview Preparation
When would you choose Jenkins over a cloud-native CI tool?
Summary
You now understand what Jenkins is, its controller/agent architecture, the central role of plugins, and how it compares to cloud CI. Next, you’ll set it up and create your first job.