DevOps PeachBefore CI servers, teams built and tested by hand and integrated late — bugs surfaced late and releases slipped. Jenkins is an open-source automation server: it reacts to events (push, PR, schedule), runs a build → test → deploy pipeline and reports the result.
flowchart LR
D["Developer"] -- "git push" --> G[("GitHub")]
G -- "webhook" --> J["Jenkins controller"]
J --> B["Build"] --> T["Test"] --> DP["Deploy"]
DP --> U["Users"]
J -- "results, notifications" --> D
- CI: automatically integrate and check many people's changes on a shared branch.
- CD pipeline: the automated path taking software from version control to users; every commit goes through it.
- Jenkins does not replace Maven, npm or Docker — it orchestrates them and runs them on agents.
- Features: configuration through the web UI and Jenkinsfiles, over 1,000 plugins, distributed builds on many agents.
Installing Jenkins LTS (Long-Term Support, recommended for production):
| Method | Main command | Notes |
|---|---|---|
| Docker | docker run -d --name jenkins -p 8080:8080 -p 50000:50000 -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-jdk21 |
The volume keeps JENKINS_HOME; port 50000 is for inbound agents |
| Linux package | apt/dnf from the Jenkins repo, run by systemd |
sudo systemctl status jenkins |
Open http://localhost:8080/, enter the initial admin password (printed in the log or stored in secrets/initialAdminPassword under JENKINS_HOME), install the suggested plugins and create an admin user.
Traps: using the latest tag (weekly releases) when LTS is wanted; running the container without a volume — removing it loses every job and setting.
| Command | Meaning |
|---|---|
docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword |
Get the initial password |
sudo systemctl status jenkins |
Service status (package install) |
Job types
| Type | Use |
|---|---|
| Freestyle project | Simple jobs configured in the UI; hard to review and version |
| Pipeline | One pipeline defined by a Jenkinsfile |
| Multibranch Pipeline | Creates a pipeline per branch and pull request that contains a Jenkinsfile |
| Organization Folder | Scans a GitHub or Bitbucket organisation and creates Multibranch jobs for every repository |
New work should use Pipeline or Multibranch Pipeline so the build logic lives in Git.
Triggering builds
A webhook from GitHub, GitLab, or Bitbucket tells Jenkins about a push or PR immediately; it needs Jenkins to be reachable from the Git server. Polling (pollSCM) checks the repository on a schedule and is a fallback when webhooks are impossible. Builds can also run on a timer, after another job, or manually with parameters.
Inside JENKINS_HOME
| Path | Holds |
|---|---|
jobs/ |
Job configuration and build history |
plugins/ |
Installed plugins |
secrets/ |
Encryption keys for credentials |
config.xml |
Global configuration |
workspace/ |
Checked-out code for builds on the controller |
Back up JENKINS_HOME regularly (excluding large workspaces), and test restoring it.
Running Jenkins well
- Stay on the LTS line and update plugins regularly; outdated plugins are the most common Jenkins security problem.
- Put Jenkins behind HTTPS (a reverse proxy) and enable authentication with SSO or matrix-based authorisation.
- Keep builds off the controller; use agents, often ephemeral containers or cloud VMs.
- Discard old builds (
buildDiscarder) so disk usage stays under control.
Jenkins and its alternatives
Jenkins is self-hosted, extremely flexible, and widely used in enterprises, but you maintain the server and plugins. Hosted services such as GitHub Actions, GitLab CI/CD, and Azure Pipelines trade some flexibility for less maintenance. The concepts (pipeline as code, agents, credentials, stages) transfer between them.