The controlled act of moving finished code into production so users get it.
Why it exists
Writing code does not put it in front of users; it has to be moved onto the servers that run it, reliably and repeatably, and doing that by hand is slow and error-prone. Deployment and releases exist as the controlled process of shipping a version out, so getting new code live is routine rather than risky.
How it actually works
Deploying pushes new code to the production servers. Done well, it's careful and observable: often rolled out gradually, watched for errors, and reversible if something goes wrong. Done carelessly, it's how outages happen.
"Deploy" (the technical act of shipping code) and "release" (making a feature available to users) can be separated, so code can be live but switched off until you choose to turn it on, which is what feature flags enable.
A senior PM walks you through it
A junior PM, stuck
The night before our launch, eng said the new checkout is "deployed but not released" and I could not tell my stakeholders whether users actually have it. Marketing wants to announce tomorrow. I do not want to promise the feature is live and then find out it was sitting there switched off the whole time.
Those are two different events wearing one word. Deploy means the new code is now running on the production servers; release means users can actually reach the feature, and a feature flag is the switch between them. Here is the pipeline log for that build, TiffinBox release v2.4.1, trimmed to the lines that decide your answer. Read the last line first, then walk up with me.
Deploy pipeline log, TiffinBox release v2.4.1
2026-03-06T12:50:02ZINFOci build v2.4.1 succeeded
2026-03-06T12:52:40ZINFOci tests passed 214 of 214
2026-03-06T12:58:11ZINFOdeploy v2.4.1 rolled out to 10% of servers (canary)
2026-03-06T13:03:11ZINFOdeploy canary error rate 0.3% over 5m, within limit
2026-03-06T13:04:09ZINFOdeploy v2.4.1 rolled out to 100% of servers
2026-03-06T13:04:10ZINFOflags new_checkout=OFF in production (staging=ON)
2026-03-06T13:04:12ZINFOcheckout serving version=v2.4.1 flag new_checkout=OFF
Click a step to see the lines it points at.
Mistakes I've seen
Announcing a feature to users the day the code deploys, before the flag flips. The code being on the servers is not the same as anyone being able to use it, and the gap between them is exactly one config line.
Reading a green pipeline as proof the release is healthy. This run passed every check and still shipped the code that broke checkout minutes later; a passing deploy is a snapshot at 10% traffic, not a guarantee at 100%.
Asking eng "is it live?" without saying which meaning. Deployed and released are different events, so the one-word question gets you a yes that answers the other one.
Treating the flag as engineering's to flip on their schedule. Separating deploy from release is your launch-timing lever; you decide when new_checkout goes ON, independent of when the code shipped.
Tell your stakeholders: "The code is deployed to all servers as of 13:04, but new_checkout is flagged OFF in production, so users do not have it yet. We can release on our own timing by flipping the flag, no new deploy needed." You separated deploy from release and pointed at the exact line that proves which one happened.
Where a PM meets this
Deploy timing matters: many teams avoid Friday-afternoon deploys so problems don't surface over the weekend.
Separating deploy from release gives you control over launch timing independent of engineering's schedule, a useful lever.
Hear it in a meeting
"Code's deployed but flagged off; we release to users Monday morning."