Jenkins is a job runner with an enormous plugin ecosystem — which is both why it survives everywhere and why every neglected Jenkins becomes a liability.
Jenkins runs automation jobs on a schedule or a trigger. A controller schedules work and stores configuration; agents execute it. The job itself is a Jenkinsfile committed alongside your code.
git push / webhook / cron / manual
│
↓
┌──────────────────┐ assigns work
│ CONTROLLER │ ─────────────────────┐
│ · schedules │ ↓
│ · stores config │ ┌──────────────────┐
│ · serves the UI │ │ AGENT (node) │
│ · NEVER builds │ ←──────────│ runs the stages │
└──────────────────┘ results │ has the tools │
└──────────────────┘
static VM · Docker · Kubernetes pod
pipeline {
// Run each stage in a fresh container. Nothing persists between builds,
// which is the whole point — no "works on agent-3" mysteries.
agent {
kubernetes {
yaml '''
apiVersion: v1
kind: Pod
spec:
containers:
- name: node
image: node:22-alpine
command: ['cat']
tty: true
'''
}
}
options {
timeout(time: 30, unit: 'MINUTES') // never let a job hang forever
disableConcurrentBuilds() // one build per branch at a time
buildDiscarder(logRotator(numToKeepStr: '30')) // or the disk fills
}
environment {
IMAGE = "registry.example.com/web"
// Never interpolate a credential with ${} — see the warning below
REGISTRY = credentials('registry-creds')
}
stages {
stage('Test') {
steps {
container('node') {
sh 'npm ci'
sh 'npm test -- --ci --reporters=jest-junit'
}
}
post {
always { junit 'junit.xml' } // publish results even on failure
}
}
stage('Build and push') {
when { branch 'main' } // PRs are tested, never published
steps {
container('node') {
// Tag with the commit SHA: immutable and traceable
sh 'docker build -t $IMAGE:$GIT_COMMIT .'
sh 'docker push $IMAGE:$GIT_COMMIT'
}
}
}
stage('Deploy') {
when { branch 'main' }
steps {
// Wait for the rollout, and FAIL if it does not succeed
sh 'kubectl set image deploy/web web=$IMAGE:$GIT_COMMIT'
sh 'kubectl rollout status deploy/web --timeout=5m'
}
}
}
post {
failure { slackSend(channel: '#alerts', message: "Build ${env.BUILD_URL} failed") }
always { cleanWs() }
}
}
withCredentials([usernamePassword(
credentialsId: 'registry-creds',
usernameVariable: 'USER',
passwordVariable: 'PASS')]) {
// Single quotes: the shell expands $PASS, Groovy never sees the value
sh 'echo "$PASS" | docker login -u "$USER" --password-stdin registry.example.com'
}
A Multibranch Pipeline scans a repository and creates a job per branch and per pull request automatically, each running that branch's own Jenkinsfile.
repo
├── main → job, runs Jenkinsfile from main
├── feature/x → job, created automatically on push
└── PR #42 → job, runs the PR's Jenkinsfile
(from a fork? see the security warning)
Trigger it with a webhook rather than polling — polling every minute across 200 repos is wasted load and slow feedback.
Why should the Jenkins controller have zero executors?
Because a build runs code from a repository, and the controller holds every secret you have.
$JENKINS_HOME contains credentials, job definitions, plugin configuration and the private key that identifies the instance. If builds execute there, any repository Jenkins builds can read all of it — and pull requests from forks can modify the Jenkinsfile that does the reading.
Setting numExecutors: 0 and running all work on agents means a compromised build gets an ephemeral container, not your CI system.
Declarative or scripted pipelines, and why?
Declarative, and the reason is that its constraints are the feature.
Declarative
Scripted
Validated before the build starts
Yes
No — fails mid-run
Renders correctly in the UI
Yes
Partially
Expressive power
Deliberately limited
Full Groovy
Long-term outcome
A readable pipeline
A bespoke program only its author understands
Scripted pipelines let each team invent its own control flow, and over a few years you get Groovy applications with no tests sitting in the deploy path for production. Declarative keeps pipelines comparable across repositories, which is what lets a platform team support them at all.
For the genuinely dynamic case, declarative allows a script { } block — so you keep the structure and escape only where you must.
Jenkins versus GitHub Actions versus GitLab CI — how do you choose?
Ask what constraint you actually have, then pick:
Jenkins
GitHub Actions
GitLab CI
Who operates it
You
GitHub
GitLab (or you)
Runs air-gapped
Yes
Self-hosted runners only
Yes
Cost model
Your hardware
Per-minute
Per-minute or self-hosted
Config lives in
Jenkinsfile
.github/workflows/
.gitlab-ci.yml
Ecosystem
~1,800 plugins
Marketplace actions
Built-in, fewer add-ons
Main risk
Plugin CVEs, neglect
Supply chain: third-party actions
Coupling to GitLab
Decision rules:
Must self-host for regulatory or network reasons → Jenkins.
Already on GitHub, normal project → Actions. Do not run CI you could rent.
Already on GitLab → GitLab CI; the integration is the point.
Very high build volume where per-minute billing hurts → self-hosted runners for the hosted product, before rebuilding on Jenkins.