Comparisons
Pairs that get conflated in real conversations, and a few that get treated as synonyms when one is a prerequisite for the other. Neither column wins — what decides is the change in front of you. Each record leads with the confusion, because the confusion is why the record exists.
Release vs Deployment
People treat them as one event, so "we deployed" is heard as "users are now affected". That collapses the safest tool in the domain: deploying the code and releasing the behaviour separately is what makes dark launches, flags and instant disablement possible. It also makes rollback ambiguous during an incident — rolling back a deployment does not undo a release that a flag is still serving, and turning off a flag does not remove the code that shipped.
Use "deployment" for the technical act of putting a new version onto infrastructure — new instances running, new image pulled, new process serving.
Use "release" for the moment behaviour becomes visible to users — traffic shifted, flag enabled, feature announced.
| Dimension | Deployment | Release |
|---|---|---|
| What changes | Which artifact is running on the infrastructure | Which behaviour users actually get |
| Who notices | Nobody, if done well | Users, by definition |
| Reversal | Redeploy the previous artifact — minutes, and bounded by version coexistence | Flip the flag or shift traffic — seconds, and bounded by state already written |
| Risk carried | Runtime risk: startup, config, resources, compatibility with the version beside it | Product and correctness risk under real users |
| Gate | Pipeline checks and rollout health | Product decision, exposure plan, and business signals |
| Coupled by default in | Simple pipelines with no flag system | Nothing — decoupling is a deliberate investment |