Release is not deployment
Here’s a sentence that sounds impossible until this lesson, and obvious forever after: the delivery feature has been running in production for three weeks, and no customer has ever seen it.
The trick is prying apart two words that casual speech treats as one.
What is deployment?
DeploymentConcept · lights on your mapdeploymentNew code landing on the live servers. An engineering event, automated and frequent, that says nothing about whether customers can see anything new: a change can land and sit dark for weeks. is code arriving on the production servers: a technical act, the pipeline’s business, possibly happening many times a day.
Deployment moves bytes, not experiences. Code can be deployed to production and remain completely invisible to users, sitting dark.
What is a release?
A releaseConcept · lights on your mapreleaseThe moment customers can actually use a feature. Owned by the product side, chosen for marketing and support readiness, and with flags it needs no deploy, just a switch, flipped when the product side says so. is the feature becoming available to users: a product act, a decision about people and timing.
Release day is when marketing wants the announcement out, when the support team is ready for questions, when the moment suits the customers. None of those are engineering questions. And once the two words are pried apart, none of them has to wait on a deploy.
Engineers also use release for a versioned build, as in “release 2.3.” In this lesson it means the product act.
What is a feature flag?
The instrument that separates them is the feature flagConcept · lights on your mapfeature flagAn on/off setting the code consults before showing a feature. Lets code ship dark, turn on for a chosen audience (staff, one city, 1%), widen gradually, and vanish in seconds when trouble appears, all without touching a deploy. Module 8’s configuration idea, doing product work., a configuration switch wrapping the feature. These are the same flags you met in Module 8’s configuration lesson, promoted here from plumbing to product superpower.
The code checks the switch, if flags.delivery_enabled: show it, and behaves exactly as before when the flag is off.
Deploy with the flag off, and the code rides the pipeline safely to production, dark. Releasing becomes a separate act entirely, done later by flipping the flag.
And the flag does not have to flip for everyone at once:
The panic button writes itself. Something’s wrong? Flag off, and the feature is gone in seconds, with no deploy, no drama, and no late-night pipeline run.
Three ways to meet reality gradually
Three more terms refine the same instinct. They are recognition terms, so the goal is to place them when they come up in deploy conversations, not to master them.
A canary releaseRecognition — just know it existscanary releaseExposing a fraction of real users to the new version before everyone else, and reading the health signals (Module 13) before going wider. Named for the bird miners carried to detect gas early. sends the new version to a small slice of real traffic first, watches the vital signs, then widens. The name comes from the coal mines, where miners carried a caged canary underground. The bird succumbed to poison gas before people did, so a sick canary meant get out now. The small slice of users plays the bird, meeting the new version first so that everyone else does not have to.
A blue-green deploymentRecognition — just know it existsblue-green deploymentTwo full copies of production side by side, one live and one holding the new version, with the load balancer deciding which receives users. Going live is one redirect; undoing it is the same redirect in reverse. keeps two identical production environments (blue running the current version, green running the new one) and flips traffic between them at Module 9’s load balancer. The cutover is instant, and so is the undo: the switch flips back.
Shadow modeRecognition — just know it existsshadow modeBoth versions handle every real request, but only the old one’s output reaches the customer; the new one’s is logged and compared behind the scenes. Zero user risk with full-realism input, which is why Module 15 finds it everywhere AI features ship. runs the new code against real production traffic while users see only the old code’s answers. The understudy performs to an empty house, the ultimate dress rehearsal.
All three are the same instinct: meet reality gradually.
The mental model to remember
Deployment moves bytes: code onto the production servers, on the pipeline’s schedule, possibly many times a day.
A release moves experiences: a feature becoming available to users, on the product’s schedule.
The feature flag is the switch that separates them. Deploy dark, release by flipping, widen the audience step by step if the flag system allows it, and turn it off in seconds if something goes wrong.
Canary releases, blue-green deployments, and shadow mode are three refinements of one instinct: meet reality gradually.
You should now be able to hear “it’s deployed but not released” and know it is not a contradiction, and explain why launch day no longer requires a risky launch-morning deploy.
Marketing wants the delivery feature to launch Tuesday 9am sharp, with the press release. Engineering's pipeline deploys whenever PRs merge. Old-world thinking says to schedule a risky 8:55am deploy. Flag-world thinking says:
▼ answer the check to continue ▼