Why staging and production drift apart, and how to keep them in step

“It worked in staging” is the most common sentence in a post-incident review. The release was the same; the environment was not. Environment drift is rarely dramatic. It accumulates through small, reasonable actions until the staging result stops predicting the production one.

Where drift comes from

• Hotfixes applied straight to production under pressure and never back-ported.
• Configuration and secrets edited by hand in one environment.
• Infrastructure updated out of band: a managed service version, a node pool, a network rule.
• Schema changes applied manually to unblock someone.
• Data that diverges in shape, volume or edge cases, so the same code takes different paths.
• Feature flags set differently and forgotten.

How to detect drift before a release

Compare, do not assume. Before a release, diff the things that matter between the target environment and the one you tested in: deployed versions of every service, configuration values, schema, infrastructure definitions and flag states. The diff should be produced by a tool, read by a person and attached to the release so the decision to proceed is made against the real target.

How to keep environments in step

• Give every change one path. If a hotfix must go straight to production, it goes through the same review and record, just faster.
• Define infrastructure and configuration as code, and apply it to every environment from the same source.
• Run migrations through the release plan in every environment, never by hand.
• Refresh staging data on a schedule, masked where needed, so its shape tracks production.
• Review flag states as part of the release, and expire flags that have served their purpose.

Accept known differences, document them

Some differences are deliberate: scale, cost, external integrations pointed at sandboxes. Write them down next to the environment so a release is judged against a known list rather than a guess. A documented difference is a constraint; an undocumented one is a surprise.

Dorvi keeps environments comparable by design: it holds each environment’s versions, configuration and infrastructure, shows the difference before a release, and records what changed and who approved it, across the clouds you already run.