“But it worked in staging” …..
We have all said this at some point in our careers. A critical release is on the line, we are behind our deadlines, we push to production and something breaks. Under stress, the words tumble out: “But it worked in staging”.
The myth of staging
But, even if it had worked in staging, we couldn’t have been confident of it working in production.
Because production is its own beast.
Because production infrastructure is more powerful than staging.
Because production traffic can’t be reproduced in staging.
Because copying production data to staging is a security nightmare.
So, why have a staging environment? In fact, why have 2-4 pre-production environments each designed to take the risk out of software delivery when we will inevitably say: “But it worked in staging”.
Getting to the final act: production
Instead, the answer is to:
- invest in CI/CD pipelines to get to production as soon as possible
- give developers the ability to gradually rollout features in production behind a feature flag
- invest in automated QA that detects problems in production.
If you do these steps, you will be able to get rid of practically all your pre-production environments. And if you think this is costly, imagine the savings in infrastructure and human costs if you could remove all those environments.
And the faster your team can get from ‘it worked in staging’ to ‘it works in production’.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Learn how Walmart uses product experimentation as a way to increase engineering impact and progressive delivery as a way to reduce the risk of moving fast.
There’s more than one way to succeed with Continuous Delivery. In this article we summarize four of the common tactics various organizations employ.