What a Release Actually Involves (Beyond Clicking Deploy)
Updated: Aug 10
"We're shipping Friday." That sentence usually paints a picture in your head: someone leans over a keyboard at 5 p.m., presses a big SHIP button, and the new thing is live. Cheers all around.
The button is real. But pressing it is the least interesting thing that happens that day. The release is everything around the button — the checks before it, the careful way you turn the feature on, and the plan for what to do if it misbehaves. Miss those, and "shipping Friday" turns into "firefighting Saturday."
This article walks the whole chain, start to finish, on one small feature so you can see each step actually happen. If you're new to this, that's the point — you'll leave able to picture what "releasing" really means, and to ask the two questions that de-risk almost all of it.
The one distinction that clears up half the confusion
Two words get used as if they mean the same thing. They don't.
Deploying means putting the new code onto the servers. The code is there, sitting on the machines that run your product.
Releasing means making the new behavior available to users. The code doesn't just sit there anymore — people can now see it and use it.
Here's why the difference matters: you can deploy code that's switched off. A feature flag is a simple on/off switch in the code. You deploy with the switch off — the code ships to the servers but nobody sees anything new. Then, later, when you're ready, you flip the switch to on. That's the release.
Splitting one scary event ("everything changes at once") into two smaller ones ("get the code out" and, separately, "turn it on") is the single most useful move in this whole article. Each half can be checked and undone on its own.
Plain takeaway: deploy = move the code onto the servers. Release = turn the behavior on for users. They are two different moments, and keeping them separate is what makes the rest safe.
The feature we'll follow the whole way
(Developed example — a simple scenario.)
Imagine an online store. The team is adding a "save for later" button — the little link on a product that moves it out of your cart and into a saved list, so you can come back to it another day. Small feature. Nothing fancy.
We're going to carry this exact feature through every step of the release. Same button, all the way down. Watch what "shipping save-for-later" actually requires.
The release chain, one step at a time
Before the walkthrough, here's the whole chain in a table — every step, what it's checking, and what tends to break if you skip it. Skim it now; we'll do each row in detail underneath.
Step | What it checks | What goes wrong if you skip it |
1. Confirm it's really done | The work covers the real cases, not just the happy path | You ship a feature that breaks the moment a user does something ordinary |
2. Test / QA | The code does what it's supposed to, and old things still work | Bugs reach real customers instead of getting caught in private |
3. Staging check | It behaves in a copy of the real setup, not just a laptop | "Worked on my machine" — then fails on the real servers |
4. The deploy | The new code lands on the servers cleanly | A half-finished deploy leaves the product in a broken, in-between state |
5. Smoke test | The basics still work right after deploy | The site is down for minutes before anyone notices |
6. Gradual rollout + monitoring | Real users are fine, watched closely, turned on slowly | A hidden problem hits everyone at once instead of a handful |
7. Rollback plan | You can undo it fast if it goes wrong | A bad release stays live while people scramble for a fix |
Now the walkthrough.
1. Confirm the work is really done
"Done" is slipperier than it sounds. The developer says save-for-later is done — the button works, they clicked it, the item moved to the saved list. Great. But done for whom?
What happens if a logged-out visitor clicks it? There's no account to save it to.
What if the item is out of stock by the time they come back?
What if they save the same item twice?
Is there a test proving it still works next week when someone changes the cart code?
None of those are edge cases you invented to be difficult — they're Tuesday. This is where a shared definition of done earns its keep: a plain checklist the whole team agreed on that says what "finished" has to cover. Without it, "done" means "worked once, for me, just now."
The single most valuable question you can ask here is: what does "done" actually mean for this feature? Asking it out loud, before anyone deploys, surfaces the gaps while they're still cheap to fix. (More on this in Definition of Done vs. Acceptance Criteria.)
Plain takeaway: pin down what "done" covers before you ship, or you'll find out live.
2. Test and QA
Now the feature gets checked on purpose, not by accident. Some of this is automated — tests that run by themselves and shout if something breaks. Some is a person clicking through save-for-later the way a real shopper would, trying the awkward paths from step 1.
Two things get checked here. First, does the new feature do what it should? Second — and people forget this one — did adding it break anything that already worked? Maybe the save-for-later change quietly messed up the regular "add to cart" button. Testing is how you catch that in private instead of hearing about it from customers.
Plain takeaway: testing checks both the new thing works and the old things still do.
3. Check it on staging
Your laptop is not the real world. Staging is a practice copy of the live setup — same kind of servers, same kind of database — where the feature runs one last time before the real thing. It catches the classic "but it worked on my machine" surprise, which usually comes from the real environment being configured differently than a developer's laptop.
Save-for-later gets exercised on staging: real-ish data, the actual login system, the actual database. If the saved list only works when connected to the real database in a certain way, staging is where you find out — not production. (If the words staging and production are new, start with Dev, Staging, and Production Environments Explained.)
Plain takeaway: staging is a dress rehearsal on a copy of the real stage, so opening night has no surprises.
4. The deploy itself
This is the famous button. And thanks to the deploy-vs-release split, it's now the boring part. The save-for-later code moves onto the live servers — but the feature flag is still off, so no shopper sees anything change yet. The code is present; the behavior is not turned on.
Most teams don't press a literal button by hand anymore; an automated pipeline moves the code out consistently every time, which removes a whole category of human slip-ups. (That automation has a name: CI/CD, explained in plain English.)
Plain takeaway: the deploy just lands the code; with the flag off, nobody's experience has changed yet.
5. Smoke test
The moment the deploy finishes, run a smoke test — a tiny, fast check that the important basics still work. The name comes from electronics: plug it in and see if smoke pours out. You're not testing everything; you're confirming the building isn't on fire.
For our store: can you load the homepage? Can you add a normal item to the cart and check out? If those core paths are fine, the deploy didn't obviously break the store. It takes a couple of minutes and it's the difference between "we noticed in two minutes" and "a customer emailed us an hour later." (See Smoke Testing: The Five-Minute Quality Gate.)
Plain takeaway: right after deploying, a quick smoke test tells you the basics didn't just break.
6. Turn it on gradually, and watch
Here's the release — flipping that flag on. But you don't have to flip it on for everyone at once. You can turn save-for-later on for 1% of shoppers first, watch, then 10%, then everyone. This is a gradual rollout, and it's your safety margin.
While it's on for that first slice, you monitor: are error rates climbing? Are saved lists actually saving? Is anything slower than before? If a problem shows up, it's hitting a handful of people, not your whole customer base. You caught it small.
Plain takeaway: turning a feature on slowly, while watching, means a hidden problem hits a few users instead of all of them.
7. Have a rollback plan ready
Even with all of that, something can still go wrong. The question a release plan must answer before you ship is: how do we undo this, fast?
Because we used a feature flag, the answer for save-for-later is wonderfully simple — flip the switch back off. The feature disappears for users instantly, without a panicked emergency deploy at 5 p.m. on a Friday. If you'd wired everything together in one big irreversible change, "undo" would mean scrambling to write and ship new code under pressure — exactly when mistakes multiply.
Plain takeaway: decide how you'll undo the release before you make it, and a feature flag makes "undo" a single switch.
Why this whole thing works
Step back and notice the shape. The two ideas that make releasing safe are both small:
Separate "move the code" from "turn it on." That one split is what lets you deploy quietly, smoke test in peace, roll out slowly, and undo with a switch. Everything calm about the chain above comes from this.
Ask "what does 'done' actually mean here?" early. That question drags the awkward cases — logged out, out of stock, saved twice — into the open at step 1, while they're cheap, instead of at step 6 in front of real shoppers.
A release isn't one dramatic button press. It's a short chain of small, reversible steps, each one asking a plain question and each one leaving you able to back out. The button gets the credit. The chain does the work.
Sources
This article is a composite explainer built from common industry release practices — feature flags, staging environments, smoke tests, gradual rollouts, and rollback planning — taught through a single illustrative feature ("save for later"). The store, the feature, and the walkthrough are a simple scenario for teaching, not a record of a specific company.
Keep learning. This article is part of the Start Here path in the ShiftQuality Learning Center.
