In software development, staging is the process of testing your code in a live environment before pushing it to production. A staging environment is pretty much a replica of a production environment, so you can see exactly what users will experience once you release the code. Development teams often work with multiple instances within three types of environments:
Local environment – every developer has one. Here, code is committed to various branches of development streams and previewed locally.
Staging environment – runs code in a live environment for testing purposes. Developers might stage release candidates as they approach rollout, or much earlier in the development phase to verify git pushes. Stages can be connected directly to the main branch, or to feature branches which are not yet merged into master.
Production environment – runs the live version of a project.
Why development teams often skip the stage
As an exact replica of your production environment, a staging environment can easily require the same effort that goes into maintaining the production environment. And that additional effort can grow exponentially if multiple release candidates are all in staging at the same time.
What’s more, staging adds yet another step to a developer’s daily. Which is something they’re not exactly keen on unless it’s absolutely necessary. Why stage if my project looks fine on localhost, right?
But we shouldn’t be too hasty. Staging has a lot of benefits. And with the right tools at hand, staging requires no extra cost or effort at all.
The benefits of staging
Your designers are happier
Working with a designer on a project with frontend? Give them a chance to check whether the look and feel of the latest release meets their expectations. Speaking from experience, unpleasant surprises can put a dampener on the team spirit.
Clients know what’s coming
Misunderstandings during concept creation are common. Even if a deployment goes exactly as planned, your client might have had something different in mind. Send them a preview link to align expectations before going live.
No more awkward “it looked different on my machine” moments
Who hasn’t been there? An issue flares up with a live project, but the person responsible claims they didn’t have this issue on their local machine. These scenarios are completely avoidable if you rigorously test for multiple scenarios during the staging phase.
Responsibility is shared
Sure, you can ask teammates to review your pull request. That way you weren't the only person who saw the code before release. But PRs don’t replace fully-fledged stages. With stages you can delegate essential quality checks to QA or test engineers.
Everyone stays in the loop
There's no crystal ball showing project managers how far you are with the code on your local machine. Using staging environments to let them see the progress from time to time will make them happy – and probably save you from replying to anxious emails.
Changing the staging game
Deploy Now is a build tool created by developers for developers for building and hosting static site generators, PHP apps and single page applications on custom engineered IONOS infrastructure.
Create a feature branch locally, push it to staging, view your code live, merge to production and automatically shut down the staging environment.
That's how easy staging with Deploy Now is.
Every Deploy Now package offers staging branches as SSL-secured preview URLs. Share these URLs with clients and team members or use them to check your code on different devices and browsers.
With no extra cost and effort required for managing additional infrastructure, should you still skip the stage? Absolutely not.
If you work with multiple branches already, your daily workflow won't even change. Your code is built and deployed automatically, so it’s super quick and simple to run your code in a live environment early and often.
What about you? Why do you think every dev team should use staging environments?
Top comments (22)
Days of “let’s deploy and be on the lookout” are gone indeed.
develop
Works well for us!
I think heroku allows you to do all of this by default. It has staging and production environments. Plus it has review apps that can be linked to an issue in JIRA.
In Deploy Now, we've implemented the following mechanic:
If a dev opens a new branch in addition to main, we directly deploy it under a preview URL using the same build workflow that is also used in "main". The staging environment receives a generated preview URL incl. SSL. One the branch gets deleted/merged, we delete the staging environment. But if someones pushes to main, updates go live instantly.
Does this sound like a good workflow for you, or would you design it differently? @vjnvisakh & @joolsmcfly
Sounds pretty good to me except for small details.
We deploy feature branches we deem deployable/advanced enough (test suites are automatically run only if you push to a branch that has an open pull request).
If you're in the early stages of a new feature then it's not very useful to have a preview URL as it might be broken.
Our main branch is protected so you cannot push to it directly. You have to open a pull request first. That way we make sure tests are run and that someone reviews your changes.
We merge pull requests only if the matching pipeline (our test suite basically) is successful and if at least one person validates your PR.
Hope this helps!
Helps, thanks a lot :)
Indeed but review apps only work with GitHub if I understand the doc correctly: devcenter.heroku.com/articles/gith...
ah! yes. heroku only has github support currently.
Staging rules!
This!
Totally agree!
I totally agree with you on this. Before going live staging is a must dor developers.
Couldn't agree more. Never trust localhost alone
Happy designer, happy live.
Thanks for Sharing Really Appreciated your efforts. Now Starting following you!
Thanks a lot! :)
My company goes a step during our process of deployment including deploying to the following websites:
Also we have protected (can't be deleted) git branches called:
Sounds interesting. How do you structure and store feedback between the project manager and the responsible developer? @hollyw00d
@roberts we message the responsible project manager to view a link in a STAGING environment. Often I also sent them an IM (Instant Message) message as well to ensure they receive it.
Then if the responsible project manager approves the link in a STAGING environment that we push the work live (AKA deploy to PROD).
Makes sense. So an automatic notification for the project manager whenever a Staging environment was created/updated and a tool integration where the project manager could drop documented feedback and e.g. annotate screenshots would feel overeingineered? @hollyw00d
We don't have an automated system yet to contact a project manager for to review work that is pushed to STAGING. That would be a great idea.
Since we have multiple teams working in parallel, it's best for the team to stay updated with the progress of development. Once the development is done for a sprint we demo it to the client on staging itself. We then move it to QA env once they are satisfied and then goes to internal testing by clients and then to production.
Did you implement any automatic notification mechanisms whenever an update on a stage gets rolled out, like Slack/Email notifications? @vjnvisakh