Jenkins
Jenkins is the long-standing, self-hosted CI/CD server. Its enormous plugin ecosystem means it can automate almost anything and integrate with almost everything — which is both its strength and its trap. You own the server, the plugins, the upgrades, and the security.
In an era of hosted CI (GitHub Actions, GitLab CI), Jenkins remains common where teams need on-prem control, deep customization, or have years of existing pipelines. The key to keeping it healthy is treating it as high-value infrastructure with real governance.
TL;DR
- A self-hosted CI/CD server, extensible through plugins.
- Prefer pipeline-as-code (a
Jenkinsfile) over UI-configured jobs. - Govern plugins and credentials tightly — Jenkins is high-value infrastructure.
- Flexible, but fragile without discipline (plugin sprawl, snowflake agents).
Quick Example
A declarative Jenkinsfile keeps the pipeline in version control alongside the code:
Core Concepts
- Job/Pipeline — a build definition; pipelines are defined as code in a
Jenkinsfile. - Agent (node) — a worker that executes builds (keep these ephemeral where possible).
- Credentials — Jenkins' secret store, injected into builds.
- Plugins — the extension mechanism for everything from SCM to deploy targets.
Best Practices
- Use declarative pipelines in a
Jenkinsfile, not click-configured jobs. - Keep build agents ephemeral (containers/VMs spun up per build) to avoid drift.
- Pin, review, and minimize plugins — sprawl is the top source of fragility.
- Restrict admin access and rotate credentials; never echo secrets in logs.
Comparison: Jenkins vs hosted CI
See GitHub Actions.
Common Mistakes
UI-configured jobs instead of pipeline-as-code
Plugin sprawl
FAQ
When should I choose Jenkins over hosted CI?
When you need on-prem/self-hosted control, must integrate with internal systems a SaaS can't reach, require deep customization, or already have substantial Jenkins pipelines. For greenfield projects on GitHub/GitLab, hosted CI is usually simpler and lower-maintenance.
What is pipeline-as-code in Jenkins?
Defining your build/test/deploy pipeline in a Jenkinsfile committed to the repository, rather than configuring jobs through the web UI. It makes pipelines versioned, reviewable, and reproducible — and is the recommended approach.
Why is plugin management such a big deal?
Jenkins' power comes from plugins, but uncontrolled plugins cause upgrade conflicts, breakage, and security vulnerabilities. Curate a minimal set, review additions, and keep them updated — treat the plugin list like a dependency manifest.
How do I keep Jenkins secure?
Restrict admin access with role-based permissions, store secrets in the credentials store (never in logs or Jenkinsfiles), keep Jenkins and plugins patched, use ephemeral agents, and put it behind your network controls. It's a high-value target.
Related Topics
- CI/CD Pipelines — The fundamentals
- GitHub Actions — Hosted alternative
- Docker — Ephemeral build agents
- Secrets Management — Handling credentials
- DevOps — The broader practice