Staging Environment Best Practices and How to Fix Yours

Even gone cowboy-style and pushed code to production directly? Many experts argue that testing your production-ready code in staging first is essential and the most reliable way. In fact, staging environments have been central to proofing code ahead of production deployment for decades now. But not everyone gets the most value out of theirs. So let’s explore some staging environment best practices. So you can fix what may be broken by identifying the following issues.

Staging Environment best practices: It should be an exact production replica

This one’s easy. The point of having a staging environment is to use it as a mirror of the production environment. Staging is used to test ‘production-ready’ code for residual and/or potentially high impact bugs before production. If it isn’t an exact mirror image of production, there’s no value in putting your code through a staging environment.

Did the developer forget to retrofit some direct-to-production enhancements or bug fixes back to the staging environment? Did the project team deem integrating staging with a new backend system too expensive?

When we talk of staging mirroring production, we do mean an actual mirror image. Not an approximation with compromises. Staging should connect to the same set of systems and services as production. It should also have the high level of monitoring and controls applied to production.

Tip: Could you redirect customer traffic to the staging environment and expect it to hold up? If the mere thought sounds implausible, then your staging doesn’t mirror production.

Staging Environment best practices: Do you have enough data?

Data quality happens to be one of the big reasons that a staging environment sucks. Sure, you can’t have the same volume and diversity in data as in production. But you could put in an effort and set up test data that mimics real customers.

Real case study: While working on a project using staging data to deploy an online banking solution, the testing team only had access to ‘dummy’ test accounts. Which didn’t really have any credit balance. This severely restricted the type of testing they could do.

Tip: Plan ahead of time to secure the right data you need for your staging testing to be effective.

Staging Environment best practices: Make real user data available

More than just test profiles that mimic a user. But also getting a real user to execute real, live transactions through staging brings a whole new dimension. And adds tons of value to the process.

In the previous banking app case study, the project team was releasing code into the staging environment daily and weekly. Everybody on the project, from executive sponsor to developer, was using it.

To tackle the lack of real user data, they used staging as the primary app for banking services. Channeling some real-life transactions through it, rather than the production version. This lets them use the staging environment to try out new features, enhancements, and bug fixes for several weeks prior to production.

With close to 50 users hitting the server regularly, the staging environment may not simulate the load that production usually gets, but it does give you the benefit of having a variety of use cases being constantly triggered in a production mirror image. This makes it easier to identify and report high impact issues.

Staging Environment best practices: Test on staging often

Some teams rush through staging in a matter of days for projects that have run for 6 months. Such a short, rushed test period eventually results in insufficient testing. Thus, significantly diminishing the value of using a staging environment.

Solution:
For teams running Agile and/or Scrum, make sure your code hits the staging environment at the end of every sprint or iteration. The team should push code onto the staging environment in increments every week, every other week or even every day.

You can have real users play around with the staging environment. This gives you the benefit of an incremental yet perpetual staging test while sprints continue.

For believers in Waterfall, the duration of testing in staging environment should reflect the length of your test cycle. As a rule of thumb, staging should be at least half as long as your user testing cycle. If your UAT was 4 weeks, staging testing should run at least 2 weeks.

This solid staging environment can help you

You could obviously go cowboy like the staging-haters, and deploy code straight to production. And this may, in fact, work for you – until suddenly it doesn’t. If you want to protect your customers and your reputation, it’s best to play it safe. Then you’ll need a solid staging setup that prevents you from all that uncertainty. Instead of providing a reliable way to catch those sneaky bugs before live code can embarrass you.

Our fun and curious team mascot's always plugged into the latest trends.
He's here to share his knowledge and help you solve your tech problems.

Staging Environment Best Practices and How to Fix Yours2018-05-212018-11-06https://www.plesk.com/wp-content/themes/plesk/images/plesk_logo_144x144_black.pngPleskhttps://www.plesk.com/wp-content/uploads/2018/05/blog_plesk_post-staging.png200px200px

Leave a Comment

Save my name, email, and website in this browser for the next time I comment.

Search

Generic filters

Exact matches only

Search in title

Search in content

Search in excerpt

Filter by Custom Post Type

We are Plesk

Are you like us? Value simplicity and automation? We help devs, sysadmins, and resellers run, manage and secure via our control panel solutions, extensions and hyperscale opportunites. Currently at +380K servers, +11M sites and +19M mailboxes. There’s room for you too! Discover how you fit with us.

I hereby consent that my personal data (name and email address) will be stored and processed by Plesk International GmbH for the sole purpose of delivering the Plesk Newsletter to me. At any time, you may unsubscribe from the Plesk Newsletter by clicking the unsubscribe option in the footer of each email or contacting [email protected] For more information, check out our Privacy Policy.