A few years ago, I decided to scrap development environments from our workflow to make feature deployments easier. And since then, I’ve never gone back.
Development. Staging. Production.
Back then, we had environments for development, staging and production and sometimes a few branched environments for features that were not ready for release anytime soon.
- Development – This was used internally, so the team could see how the current features in development were coming along.
- Staging – Completed features were deployed to this environment so all parties could do their testing and feedback.
- Production – This was the live version of the website.
Branches were set up within our source control repositories to match the environments, and these would automatically deploy when changes were pushed.
Focus on development.
All seemed great at first until our team started to grow, and we quickly noticed that :
- We were setting up multiple staging environments because different team members were developing features, and they weren’t shipping simultaneously.
- Data was out of sync across all environments. Development did not match staging, and staging never matched production. This led to minor issues when deployed to production because the data was different and untested. We tried automatically syncing the databases but just hit more complications.
- Hosting costs were increasing.
- Code conflicts were frequent and becoming a pain. These often broke the staging environments.
- And, after all this, our clients never tested out the features on staging, so it was just a waste of resources.
In summary, it added more complexities than was required, and the whole process pulled us away from actual development.
Small updates. Ship faster.
So, one day I came into the office and announced that we were scrapping the development and staging environments to cheers from the dev team. We replaced our existing workflow with a single one: local development to production.
This allowed us to ship faster with smaller updates, allowing for sufficient testing from our end. And, because of this, we could fix and deploy bugs within hours rather than the days it usually took us. We could review work locally in-house on each devs machine by creating ssh tunnels and creating code reviews to maintain clean coding.
To this day, I have never created development or staging environments. The only exception to this is Shopify, where I create development stores because there is no local development environment available, and sometimes you don’t want content visible to the public just yet.
Outside of Shopify projects, if I ever need to show my clients the work in progress, I send them an annotated screen recording of it in action, which is enough for them to give feedback.