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’.