All The World’s A Staging Server

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.