All articles
Practice
·
6 min read
A rollout is not a deploy
Deploys move code. Rollouts move risk. Treating them as the same step is why release days feel dangerous.
IV
Ida Vestergaard
Co-founder, Product
Cover · set this frame’s Fill to an image
A deploy puts new code on servers. A rollout decides which users see the behaviour that code enables. Most teams collapse the two into one moment, and then every release carries the full risk of every change in it.
Separating them changes the shape of a bad day. A broken deploy is still a broken deploy, but a broken feature behind a flag is a thirty-second rollback and a calm conversation.
The practical rule we use: if a change touches what a user sees or pays for, it goes behind a flag with a stepped rollout. If it is a refactor with no user-visible change, it ships with the deploy.
This is not about caution for its own sake. Teams that separate rollouts from deploys deploy more often, because each deploy carries less.