Jenkins
The original open-source automation server. Self-hosted, infinitely customisable, and still the backbone of many enterprise CI/CD pipelines.
Overview
Jenkins, originally created as Hudson in 2004 and forked to Jenkins in 2011, is the oldest and most widely used open-source automation server. It provides hundreds of plugins for building, testing, and deploying software. Jenkins is self-hosted, giving organisations complete control over their CI/CD infrastructure.
While newer tools like GitHub Actions and GitLab CI have gained popularity, Jenkins remains dominant in enterprises with complex, custom requirements that cloud-hosted platforms cannot satisfy.
What it's used for
Jenkins is essential when:
- Self-hosted CI/CD required: Data sovereignty, security, or compliance mandates on-premise infrastructure.
- Complex pipelines: Multi-stage pipelines with conditional logic, parallel execution, and custom integrations.
- Legacy system integration: Connect to mainframes, proprietary systems, or custom hardware.
- Plugin ecosystem needed: 1,800+ plugins for virtually any integration.
Pros & Cons
Pros
- Infinitely customisable with 1,800+ plugins
- Self-hosted — full control over infrastructure
- Free and open source
- Mature and battle-tested for 20+ years
- Massive community and extensive documentation
Cons
- High maintenance burden — requires dedicated admin time
- Plugin quality varies — some are outdated or unmaintained
- UI is dated compared to modern CI/CD platforms
- Security requires vigilance — Jenkins has had notable CVEs
- Scaling requires expertise (master-slave architecture, Kubernetes)
Platforms & Integrations
Jenkins runs on Windows, macOS, and Linux. It requires Java. It can be deployed on-premise, in the cloud, or on Kubernetes.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | Full server, all plugins, community support |
| CloudBees | Custom | Enterprise Jenkins with support, security patches, and advanced features |
NZ Context
Jenkins is the dominant CI/CD tool in NZ government agencies and large enterprises where data sovereignty, security policy, or legacy integration rules out cloud-hosted runners. NZ central government departments and major financial services organisations have run Jenkins for a decade or more — their pipelines are deeply embedded and not going anywhere soon. For NZ QA professionals, Jenkins experience is a genuine differentiator when targeting public sector or enterprise roles, where on-premise infrastructure is still the norm. That said, Jenkins is less in demand among NZ SaaS startups and modern product companies, which have largely standardised on GitHub Actions or GitLab CI.
Alternatives
- GitHub Actions — Cloud-native, zero-maintenance alternative for GitHub users.
- GitLab CI — Built-in CI/CD with better UX and self-hosted options.
- Azure DevOps — Microsoft's integrated CI/CD with strong enterprise features.
When to choose Jenkins
A quick decision guide for NZ teams evaluating CI/CD options.
| Choose Jenkins when… | Choose something else when… | Combine with… |
|---|---|---|
| You operate on-premise infrastructure for compliance or data sovereignty reasons — common in NZ government and financial services. | Your team is fewer than 20 engineers and nobody wants to own a Jenkins server — use GitHub Actions instead and spend that time on testing. | Docker and Kubernetes for ephemeral build agents — eliminates the classic "works on Jenkins, fails in prod" environment mismatch. |
| You need to integrate with legacy systems — mainframes, proprietary test hardware, or internal package registries — that cloud CI can't reach. | Your codebase lives in GitHub or GitLab and your pipelines are straightforward — native CI/CD is simpler, cheaper, and faster to onboard. | SonarQube for static analysis and OWASP ZAP for security scanning — Jenkins orchestrates both in a single Declarative Pipeline. |
| You have complex fan-out pipelines — dozens of microservices, parallel test shards, or multi-environment promotion gates — that need shared library code across teams. | You're starting a greenfield project in 2025 — the maintenance overhead rarely pays off until you've outgrown hosted CI limits. | Artifactory or Nexus for artefact management — Jenkins publishes build outputs; Artifactory stores and promotes them through environments. |
| You already have a Jenkins instance and a team that knows it — switching costs are real and GitHub Actions won't automatically save you time. | Your team is entirely on Azure — Azure DevOps Pipelines is tightly integrated with Azure services and removes the self-hosting burden entirely. | Terraform or Ansible for infrastructure provisioning — Jenkins calls them as pipeline steps, giving you a single audit trail across code and infra changes. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
plugin.txt file and a dedicated Jenkins controller in Docker so upgrades are testable before touching production. Don't touch any job until you understand what it deploys — in a managed services context, a broken pipeline means a client SLA breach.The bottom line: Jenkins earns its keep when you have complex, long-lived pipelines that no hosted platform can replicate — but the moment you're spending more time maintaining Jenkins than writing tests, that's the signal to migrate.
Interview questions
Questions you are likely to get if you list Jenkins on your CV — with what interviewers are really testing for.
What is the difference between a Freestyle job and a Declarative Pipeline in Jenkins, and when would you choose each?
What they’re really testing: Whether you understand the evolution of Jenkins and can articulate trade-offs, not just that you've clicked through the UI.
Strong answer covers: Freestyle jobs are UI-configured and quick to set up but not version-controlled; Declarative Pipelines live in a Jenkinsfile in the repo, enabling code review and history. Mention that most NZ enterprise teams migrating off Freestyle use Declarative Pipeline in conjunction with a shared library so every squad shares common stages (build, test, deploy) without duplicating code.
When would you choose Jenkins over GitHub Actions for a new project?
What they’re really testing: Whether you default to Jenkins out of habit or can make a principled infrastructure decision based on real constraints.
Strong answer covers: Jenkins wins when data sovereignty or compliance rules out cloud-hosted runners (common in NZ government and financial services), when you need to integrate with on-premise systems that cloud CI can’t reach, or when pipelines are complex enough that the plugin ecosystem outweighs the maintenance cost. For a typical NZ SaaS startup in 2025, GitHub Actions is almost always the better default.
You’re joining Revenue NZ’s software delivery team. They have a Jenkins instance running 150 jobs, some of which haven’t run in over a year. How do you approach it in the first month?
What they’re really testing: Whether you’ll act cautiously in a high-stakes government environment or charge in and break something critical.
Strong answer covers: Start by mapping which jobs are active (build history, last run timestamps), document what each triggers and what it deploys before touching anything. Pin the current plugin versions to a plugins.txt file and containerise Jenkins so plugin upgrades can be tested in isolation. Revenue NZ and similar agencies tie pipelines to live services — a broken job can mean a failed batch process affecting citizens, so change control must come before any cleanup.
Your Selenium tests pass consistently on your local machine but fail intermittently on Jenkins. How do you diagnose and fix it?
What they’re really testing: Whether you can think systematically about environment differences rather than just re-running the build and hoping.
Strong answer covers: First compare environments: browser version, screen resolution, available memory, and timezone on the agent vs your machine. Common causes are headless browser config missing --no-sandbox or a window size that changes element visibility, timing differences due to slower CI agents triggering race conditions, and tests sharing state across runs because Jenkins doesn’t reset the database between builds. Fix by running browsers in Docker on a fixed image, adding explicit waits with a maximum timeout, and isolating test data per build using unique identifiers or database rollbacks.
How would you structure a Jenkins pipeline for a large NZ organisation with 10 development squads each deploying their own microservices?
What they’re really testing: Whether you understand the operational reality of running Jenkins at scale, not just writing a single Jenkinsfile.
Strong answer covers: Use a Jenkins shared library in its own repo so common stages (security scan, test reporting, Slack notification) are written once and imported by each squad’s Jenkinsfile. Run build agents on Kubernetes using the Kubernetes plugin so agents are ephemeral and scale with load — no more queued builds because the agent pool is full. Separate controllers per environment (dev, test, prod) with promotion gates between them, and keep the production controller read-only to most engineers so only the pipeline itself can trigger production deployments.