Environments & Release Strategy
Preview, staging, production — plus rollbacks, feature flags, and canaries.
35 minDifficulty 3/5opsAI-writtenWritten by a model on 16 August 2026 and not yet read by a person. Checked automatically: schema, the pedagogical rules the hand-written material is held to, and every diagram parsed for real.
Before this
Why this exists
A feature is tested by the developer locally, deemed "ready," and deployed straight to production — where it immediately breaks because the developer's local database had different data, or an environment variable wasn't set the same way. Environments exist precisely to interpose a realistic REHEARSAL of production between "looks done" and "actually serving real users."
The mental model
Each environment answers a different question. Local: does this even run? Preview/staging: does this work against something close to real conditions, safely, before anyone real sees it? Production: this is what actual users experience, and it's the one environment where a mistake has real consequences — which is exactly why the earlier environments exist, to catch mistakes before they reach it.
How it works
A preview environment per pull request catches integration issues before merge
Rather than one shared staging environment everyone's changes compete for, a preview deployment PER pull request gives each change its own isolated, realistic environment — a reviewer (or the author) can click a link and interact with the ACTUAL feature running against real infrastructure, catching integration issues that a local dev server, with different config and data, wouldn't surface.
Feature flags decouple deploying code from releasing a feature
Deploying code that includes a new feature, gated behind a flag that's OFF by default, means the code is safely in production — tested against real infrastructure — without being visible or active for real users yet. Turning the flag on (often for a small percentage of users first) is a SEPARATE decision from the deploy itself, letting a team decouple 'is this code safely running in production' from 'is this feature live for everyone.'
A canary release limits a bad deploy's blast radius
Rather than deploying a new version to 100% of production traffic at once, a canary release routes a small percentage (say, 5%) of traffic to the new version first, watching error rates and key metrics before gradually increasing that percentage. If something's wrong, only 5% of users were ever affected, and rolling back means simply routing traffic back to the known-good version — far less disruptive than an all-at-once deploy going wrong.
A rollback needs to be fast and well-rehearsed, or it's not actually a safety net
A rollback strategy that's never been tested, or takes 30 minutes of manual steps to execute, provides far less real safety than one that's a single command or button click, executable in under a minute — the value of 'we can roll back' depends entirely on how FAST and RELIABLE that rollback actually is when something goes wrong at 2am.
The mechanism
Code progresses through environments of increasing realism and consequence: local development for immediate iteration, a preview or staging environment mirroring production infrastructure for safe validation, and production itself, serving real traffic. Release strategies like feature flags and canary deployments further decouple WHEN code is technically deployed from WHEN it's actually exposed to real users, and to how many, giving teams fine-grained control over risk at each step.
What people get wrong
- Testing a feature locally is equivalent to testing it in a staging/preview environment.
- Local environments typically differ from production in real ways — different data volume, different configuration, sometimes different infrastructure entirely (a local SQLite database versus a production Postgres cluster) — that a staging environment, closer to production's actual setup, is specifically designed to catch before they surprise you in production. Bugs that only manifest under production-like conditions (real data volume, actual network latency between services, production configuration) are exactly the class of bug a good staging environment exists to surface before real users encounter them.
- A feature flag is only useful for gradually rolling out a feature to users.
- Feature flags are equally valuable for decoupling DEPLOY from RELEASE even for an instant, all-or-nothing toggle — deploying flagged-off code to production ahead of time (even by days) lets you verify it runs correctly in the real environment before the actual release moment, reducing what has to go right at the exact moment of a launch. This decoupling is a genuinely different and additional benefit from the commonly-cited 'gradual rollout' use case, and it's often the more immediately practical one for reducing launch-day risk.
- Having a rollback plan documented somewhere counts as having a reliable rollback strategy.
- A rollback strategy that hasn't actually been PRACTICED or automated tends to reveal missing steps, wrong assumptions, or simply take much longer than expected precisely when it's needed most, under real incident pressure. The gap between 'documented' and 'actually fast and reliable under pressure' is exactly where many incidents get needlessly prolonged, because the untested rollback plan doesn't work as smoothly as assumed.
When not to use it
- The team is very small, releases infrequently, and the overhead of maintaining a full staging environment isn't justified yet.
- A lighter-weight approach — thorough local testing plus feature flags for risky changes — may be sufficient until the team or release frequency grows enough to justify the added infrastructure.
- A change is extremely low-risk (a copy/text fix with no logic change).
- A full canary rollout process may be unnecessary overhead for this specific case — matching the release rigor to the actual risk level of the change is reasonable, rather than applying maximum caution universally.
Terms
- Preview environment
- — An isolated, deployed environment created per pull request or branch, letting a change be tested against realistic infrastructure before merging.
- Feature flag
- — A runtime toggle controlling whether a feature is active, decoupling deploying code from releasing it to users.
- Canary release
- — Gradually rolling out a new version to a small percentage of traffic first, limiting the blast radius of a problem before a full rollout.
- Rollback
- — Reverting to a previous, known-good version in response to a problem, whose real value depends on how fast and reliably it can actually be executed.
In an interview
Why might a team deploy a completed feature to production behind a feature flag that's turned off, rather than waiting to deploy until the exact moment they want to launch it?
- deploying ahead of time, flagged off, verifies the code runs correctly against real production infrastructure and configuration before the actual launch moment
- this reduces what has to go right AT the moment of launch — the deploy itself is already proven, only the flag flip remains
- if something's wrong with the deploy itself, it's caught earlier and separately from the pressure of an active launch
Can you recall it?
Why does a canary release limit the impact of a bad deployment more effectively than deploying to 100% of traffic at once?