Staging Environments— An anti-pattern?

Leena
Continuous Delivery
2 min readApr 27, 2020

It was a great Keynote @ Agile India 2016, by Timothy Fitz. Timothy Fitz coined the term Continuous Deployment @ IMVU, where Lean Startup was born.

https://www.youtube.com/watch?v=qu89JWEshlU

The slides were spot on explaining how branching is an anti-pattern for continuous integration.

https://twitter.com/pgchamberlin/status/710813810664329216
https://twitter.com/jezhumble/status/710700323392753665

The main takeaway for me was his points related to Staging environments.

https://www.slideshare.net/TimothyFitz/continuous-deployment-beyond-continuous-delivery/68

The staging environment is always considered as a second class citizen. And we hardly get any feedback because there are no actual users.

I started thinking about how many times I’ve got real feedback from staging servers. Hardly any. We needed an environment to open up the features to a few users. The same can be achievable using Feature Flags.

And since then, I’ve been trying not to use staging servers. When you are consulting, it is difficult to do everything you wanted to. I hardly deployed to Staging server as part of the deployment pipeline for our product.

We use demo servers for experiments (mostly technical experiments) or testing. We brought up servers whenever needed and brought it down once the experiment is over. Those servers were never long-running. There should be set up scripts to bring the servers on demand. In our case, it was straightforward as we are using Heroku.

We should rethink about anything that disturbs the flow of code to production. Manual Testing, Code Reviews, Staging servers. can slow us down. The alternates are: Automated testing, Feature Flags, Pair programming or delayed reviews.

--

--

Leena
Continuous Delivery

Co-founder/CTO @ PracticeNow, Bangalore, India. A strong believer of lean principles, an evangelist and practitioner of Continuous delivery