DEV Community

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

5 reasons to start staging your code right now

Robert Schleinhege on June 29, 2022

In software development, staging is the process of testing your code in a live environment before pushing it to production. A staging environment i...
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