Production Is Done
Work is only done when it's live in production
"Done" is one of the most abused words in software. Code review passed? Not done. QA signed off? Not done. Merged to main? Still not done. Done means one thing: released to real users in production, with monitoring in place.
Everything else is in progress.
Deploy Is Not Release
These two words get used interchangeably. They shouldn't.
Deploy means the code is running in production. It's on the servers, it's executing, but users may not see it yet. A deploy behind a disabled feature flag is still a deploy — the code is live, but the feature isn't.
Release means users interact with it. A feature flag flipped to 1% of traffic is a release. A new page accessible to everyone is a release. An A/B test running against real users is a release.
The distinction matters because it separates the risk of shipping code from the risk of exposing functionality. Deploys should be boring and frequent. Releases are business decisions — they happen when the feature is ready, not when the code happens to land.
What Doesn't Count
Passing code review means the code looks right to someone. It doesn't mean users are getting value from it. QA approval means it works in a controlled environment. Production is not a controlled environment. Staging is close, but staging isn't production — real traffic, real data, and real edge cases live in production only.
Work that isn't deployed doesn't count. For anyone.
Why the Definition Matters
When release equals done, ambiguity disappears. No more "it's done on my machine." No more "it's basically done, I just need to deploy it." The definition forces the developer to make deployment simple. If deploying is painful, it gets avoided. If it's routine, it happens constantly — and that's exactly the behavior both sides want.
It also kills the "one more thing" trap. The moment done means released, there's no room for "let me just add this small thing before it goes out." It's live. Improvements go in the next release.
Feature Flags Bridge the Gap
Deploy early, release when ready. Push code to production with the flag disabled. Keep developing. Test against the real production environment. Flip the flag when it's ready. The main branch stays production-ready at all times — no long-lived feature branches, no integration hell at the end of a sprint.
Incomplete work gets deployed safely. Complete work gets released deliberately. The two don't have to wait on each other.
Deployment Is a Process, Not an Event
Deploy multiple times a day if the work supports it. Once a week if that's the rhythm. The frequency matters less than the friction. Automated CI/CD, a full test suite, one-command deployments — when that infrastructure is in place, deploying stops being a discipline and starts being the natural way work happens.
Production becomes the default state, not a destination visited occasionally.