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.
Plesk offers a reliable solution for setting up a staging environment and applying those changes. You can also deploy easily to synchronize your data. We’re talking about the WP Toolkit (pictured above). One of the main features being a coding playground where you can code risk-free. Find out more about risk-free coding by clicking below.
with
3 Comments
There’s one staging environment best practice missing: it’s preventing it from getting crawled and indexed (you don’t want your production environment to compete with your staging environment ;)).
I think there’s value in adding a section about that. I’ve written an extensive guide on this very matter, explaining each methods with pros and cons: https://www.contentkingapp.com/academy/protect-staging-environment.
Feel free to reach out if you have any questions, or need a quote!
Also, if your system send emails, be careful on the testing data to not have real customer emails or at least apply some of redirection on the emails to a testing email.
That’s a good one Murilo