DEV Community

Cover image for 5 reasons to start staging your code right now
Robert Schleinhege for IONOS

Posted on • Originally published at docs.ionos.space

5 reasons to start staging your code right now

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)

Collapse
 
joolsmcfly profile image
Julien Dephix

Days of “let’s deploy and be on the lookout” are gone indeed.

  • we use Docker for local env so our machines have the same versions as production.
  • we have a staging site for final testing before going live (preprod.somesite.com)
  • finally we have a home made script to deploy branches so they can be tested in isolation (2737.preprod.somesite.com where 2737 is a task ID in Jira, thanks to nginx / certbot wildcards) before they are merged to develop

Works well for us!

Collapse
 
vjnvisakh profile image
Visakh Vijayan

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.

Collapse
 
roberts profile image
Robert Schleinhege • Edited

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

Thread Thread
 
joolsmcfly profile image
Julien Dephix

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!

Thread Thread
 
roberts profile image
Robert Schleinhege

Helps, thanks a lot :)

Collapse
 
joolsmcfly profile image
Julien Dephix

Indeed but review apps only work with GitHub if I understand the doc correctly: devcenter.heroku.com/articles/gith...

Thread Thread
 
vjnvisakh profile image
Visakh Vijayan

ah! yes. heroku only has github support currently.

Collapse
 
betterblonde profile image
betterblonde

Staging rules!

Collapse
 
andrewbaisden profile image
Andrew Baisden

This!

Collapse
 
roberts profile image
Robert Schleinhege

Totally agree!

Collapse
 
shshank profile image
Shshank

I totally agree with you on this. Before going live staging is a must dor developers.

Collapse
 
simonsaysthis profile image
Simon Morgan

Couldn't agree more. Never trust localhost alone

Collapse
 
mvpw profile image
Marvin Pawlowski

Happy designer, happy live.

Collapse
 
chawalapk profile image
ChawalApk • Edited

Thanks for Sharing Really Appreciated your efforts. Now Starting following you!

Collapse
 
roberts profile image
Robert Schleinhege

Thanks a lot! :)

Collapse
 
hollyw00d profile image
Matt Jennings

My company goes a step during our process of deployment including deploying to the following websites:

  • DEV (AKA "development"): Another developer reviews and a project manager (non-developer) NEVER reviews
  • STAGING: A developer and project manager reviews
  • PROD (AKA "production" or the live site): A developer and project manager reviews

Also we have protected (can't be deleted) git branches called:

  • develop
  • staging
  • production
Collapse
 
roberts profile image
Robert Schleinhege

Sounds interesting. How do you structure and store feedback between the project manager and the responsible developer? @hollyw00d

Collapse
 
hollyw00d profile image
Matt Jennings

@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).

Thread Thread
 
roberts profile image
Robert Schleinhege

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

Thread Thread
 
hollyw00d profile image
Matt Jennings

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.

Collapse
 
vjnvisakh profile image
Visakh Vijayan

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.

Collapse
 
roberts profile image
Robert Schleinhege

Did you implement any automatic notification mechanisms whenever an update on a stage gets rolled out, like Slack/Email notifications? @vjnvisakh