Continuous Deployment
Date: 2026-08-17
Every change that passes the pipeline goes to production automatically. It sounds reckless and is generally safer than the alternative — small frequent deploys fail smaller and are far easier to diagnose than a quarterly release containing four hundred changes.
Continuous deployment releases every change passing automated verification to production, without a human approval step.
Continuous delivery is the same pipeline with a manual trigger — always able to deploy, choosing when.
CONTINUOUS DELIVERY always deployable,
someone presses go
CONTINUOUS DEPLOYMENT it just goes
Why frequent is safer
The counterintuitive claim, and the reasoning holds:
QUARTERLY RELEASE
400 changes at once
something breaks
→ which of the 400?
→ rollback loses all of them
→ the release is a high-stakes event
→ so it's rehearsed, feared, delayed
CONTINUOUS
1 change at a time
something breaks
→ it's the thing that just deployed
→ roll back one change
→ deploying is routine
Batch size is the variable. Small deploys fail small, diagnose instantly, and roll back cleanly — Continuous Integration.
The prerequisites
This is the part that matters, because continuous deployment without them is genuinely reckless:
1 A TRUSTED TEST SUITE
comprehensive enough to be the gate,
reliable enough to believe
— Flaky Tests
2 FEATURE FLAGS
deploy ≠ release. Incomplete work
ships dark — Feature Flags
3 FAST ROLLBACK
one action, under a minute
4 MONITORING AND ALERTING
you find out before customers do
5 PROGRESSIVE ROLLOUT
canary or percentage-based, so a
bad deploy reaches few people
— Rollouts as Experiments
6 BACKWARDS-COMPATIBLE MIGRATIONS
expand–contract, never a breaking
schema change — Database Migrations
See: Flaky Tests · Feature Flags · Rollouts as Experiments · Database Migrations
Points 2 and 6 are the ones teams underestimate. Without feature flags, incomplete work needs a long branch, which defeats the whole model. Without expand–contract, any schema change makes rollback impossible — Backwards Compatibility.
Deploy is not release
The distinction that makes it workable:
DEPLOY the code is in production
RELEASE users can see it
Separating them removes almost all the risk. Code ships continuously, behind flags; features are turned on deliberately, to a percentage, and can be turned off without a deploy.
It also decouples engineering from marketing timelines, which is frequently the real blocker to shipping frequently.
Rollback strategy
REVERT AND REDEPLOY
a git revert through the pipeline
← clean, and takes a full build
REDEPLOY THE PREVIOUS ARTEFACT
faster — no rebuild
← requires keeping artefacts
FLAG OFF
instant, no deploy at all
← the fastest, and only works for
flagged changes
BLUE-GREEN / TRAFFIC SHIFT
switch back to the previous
environment
Flag-off is the fastest and should be the first response for anything behind a flag. Rolling forward with a fix is tempting and usually wrong under pressure — restore service first, diagnose after.
Test the rollback path. A rollback nobody has exercised is a hope, and finding out during an incident is the worst time.
The database constraint
Code rolls back; data doesn’t.
BAD
deploy drops a column
→ rollback restores code expecting it
→ the column is gone
GOOD — expand–contract
1 add the new column, write both
2 migrate, switch reads
3 drop the old column, LATER,
in a separate deploy
Every step is independently reversible, which is what makes continuous deployment compatible with schema change at all — Database Migrations.
What you get
- Lead time from commit to production measured in minutes
- Smaller, more diagnosable failures
- No release-day ritual, and no batching pressure
- Faster feedback, so experiments and fixes land while the context is fresh
When it isn’t appropriate
Being fair about it:
- Regulated environments requiring sign-off or an audited artefact
- Client-installed software — mobile apps, desktop, anything with a store review
- No automated test coverage worth trusting. Then continuous delivery first, and build the suite
- Genuinely high-consequence single actions — a payment migration deserves a human
“We’re not ready” is usually accurate and usually about the prerequisites rather than the practice — the honest next step is picking the missing one and building it.