Jenkins & CI/CD Roadmap
Five stages, each gated by a capability rather than a lesson count. Jenkins comes first because it makes every concept explicit, and stage 4 is deliberately platform-neutral — Cloud Build, Cloud Deploy, deployment strategies and supply-chain enforcement stand on their own whatever runs your pipeline.
Dependencies that are not optional
Most lessons can be taken in any order within a stage. These four cannot.
- Build once, promote before everything about deployment If the artifact is rebuilt per environment, every test that ran earlier was about different bytes — and no strategy or gate downstream can recover that.
- Readiness probes before rolling, blue-green and canary Every zero-downtime strategy depends on the platform telling a ready pod from a started one. A wrong probe turns a rolling update into a rolling outage.
- Credential scope before pull-request builds A fork PR runs unreviewed code. If it can reach a deploy credential, the CI system is an open shell on your infrastructure.
- Backward-compatible migrations before any rollback claim Two versions run at once in every strategy except recreate. A migration the previous release cannot read means you do not have a rollback, whatever the tooling says.
Stage 1 — Foundations
~1hKnow what you are building before you build it
Git, containers, and a service you can deploy. No Jenkins experience assumed.
- ▸Separate CI, continuous delivery and continuous deployment by where the gate sits
- ▸Measure a delivery system with four DORA numbers rather than describing it
- ▸Build once and promote the same digest through every environment
- ▸Explain why a Jenkins controller should run zero executors
- ▸Convert a freestyle job into a multibranch pipeline and get PR builds
You can state your own deployment frequency, lead time, change failure rate and time to restore from real data — and prove whether the artifact in production is the one that was tested.
Stage 2 — Pipelines
~1.5hWrite pipelines that are readable, fast and hard to hang
Stage 1. A Jenkins you can break, ideally in a container.
- ▸Use all seven declarative blocks, and know what options prevents
- ▸Place agents so an approval never holds a build executor
- ▸Reach for when, parallel and matrix deliberately — including beforeAgent
- ▸Bind credentials narrowly and recognise the five ways masking is defeated
- ▸Run builds on ephemeral pod agents, and build images with no Docker socket
Given a 25-minute pipeline, you can name its longest stage from measurement, cut it, and explain which of your changes traded durability for speed.
Stage 3 — Scaling Jenkins
~1hOperate Jenkins so it is not the thing that breaks
Stage 2. Ideally more than one repository, so libraries earn their keep.
- ▸Ship a shared library versioned, tested and pinned to a tag
- ▸Rebuild a controller from JCasC plus plugins.txt rather than a backup
- ▸Run a restore drill and know what the backup does not cover
- ▸Triage a failing build in a fixed order instead of by intuition
- ▸Quarantine a flaky test with an owner rather than retrying it
You delete your non-production controller and rebuild it from Git in under an hour — and the list of things you had to do by hand afterwards is written down.
Stage 4 — Cloud-Native Delivery
~2.5hManaged build and managed promotion, and what they change
Stages 1–2. A Google Cloud project for the Cloud Build and Cloud Deploy lessons.
These seven lessons are deliberately not Jenkins-specific. Cloud Build and Cloud Deploy get two lessons each and stand on their own; the strategy, supply-chain and platform lessons apply whatever runs your pipeline.
- ▸Use the full Cloud Build step schema, including waitFor, secretEnv and the artifacts block
- ▸Pick a caching strategy from measured build durations rather than from a blog post
- ▸Give every trigger its own identity, and reach private networks with a private pool
- ▸Model delivery as pipelines, targets, releases and rollouts, with manifests rendered once
- ▸Inject per-target values with deploy parameters, and separate render identity from deploy identity
- ▸Gate a canary on a verify job that would actually catch a regression, and automate the rest
- ▸Choose between rolling, blue-green and canary on blast radius and traffic volume
- ▸Make supply-chain claims enforceable with signing, digests and admission control
- ▸Choose a platform from a constraint rather than a feature list
You can promote one release through three targets with a held approval and a canary aborted by its own verify job — and separately show a cluster refusing an unsigned image.
Stage 5 — Capstone
~1hProve every gate closes, not just that it deploys
Stages 1–4. The project assumes all of them.
- ▸Ship one commit to production through build, scan, sign, stage and gated promotion
- ▸Run nine drills, including the four that fail on pipelines that deploy perfectly
- ▸Measure rollback time from the decision, not from the command
- ▸State for every gate whether it fails open or closed
Project — handed a commit SHA, you can say what was built, what is inside it, who approved it, where it runs and how to undo it, from the pipeline alone.
Scope, and what changes underneath it
This path covers Jenkins with declarative pipelines
and Google Cloud Build and Cloud Deploy. Anything
describing Jenkins with helm init-era tooling,
freestyle-only jobs or Blue Ocean as the primary UI is dated — and the fastest way to date a
Jenkins document is to check whether the pipeline lives in the repository.
Where a lesson quotes a default, verify it in your own installation rather than trusting any
document, including this one:
jenkins-plugin-cli --list and
gcloud builds describe settle most
disagreements in seconds.