I have sad news - staging is a lie and will never be identical to production, because production is unknowable. Trying to replicate it is often prohibitively expensive.

But I also have good news - production can contain multitudes, including features you aren’t ready to turn on or activate yet. You can hide in the dark and do integration testing at the same time.

It's simplistic to say that you should just kill the idea of a staging server and do everything in production. There are obviously problems with that - you need to do unit testing, you need to avoid things that will take down a service, you may need to do essential cutovers. But it's worth examining what benefit you're getting from staging and whether you could re-allocate that effort.

Join me for an exploration of the ways that you might be able to kill staging and perform better.

• What is the actual value of a staging environment?
• What are some questions to ask about why we have staging?
• How can I re-engineer releases to save costs?

Sad news
   Staging is a lie
   Green is expensive
   Production is unknowable
Good news
   Production can contain multitudes
   You can hide in the dark
   Integration testing takes many forms
But what about?
   Unit testing
   Bad ideas
   Essential cutovers?
Conclusion 
   Launch darkly 
   Branch by abstraction 
   Test in Production

Who should attend this talk: People who design software architecture, identify as devops, or are trying to increase the release cadence of their product.

Academic level: There's nothing an introductory person wouldn't understand, but it will be more relevant to someone with a couple years experience in the field.

What is the take away in this talk: Think about what value a staging server has to your organization, and how you want to maximize that value while increasing release cadence.