Release issues happen. Maybe it’s a new regression you didn’t catch in QA. Sometimes it’s a failed deploy. Or, it might even be an unexpected hardware conflict.
How do you catch them in advance?
One popular strategy is a staging server. With a staging server, you push your code to a replica of production and test it there before you perform your final release. So, you have a better chance of catching common issues before they crop up in front of clients and cost you downtime and money.
In this post, we’ll look at what a staging server is. We’ll cover how you use them, how they differ from QA and UAT, and what the best practices are for staging servers and environments.
What is a Staging Server?
Staging servers are systems you use to test software in an environment that mimics production as closely as possible. For many companies, staging is the last step a new release takes before they deploy it to production.
A staging server is usually part of a larger staging environment. This environment mimics production as closely as space, time, and budgets, permit. Some staging environments duplicate every aspect of production: networking, database servers, storage systems, and data. Others may only have one or more staging servers.
What is a Staging Server Used For?
A staging server’s primary purpose is to act as a perfect copy of production. By testing your new releases on the same hardware, with the same configuration, connected to the same monitoring, networking and databases, etc. you can verify that the new release won’t break or fail in production.
In a typical scenario, your DevOps team deploys a release to staging with the same tools and processes they use for production. Then, operations and QA execute their acceptance tests to verify that the release works as expected. These tests include regressions, monitoring, and performance testing. So, staging helps give you an idea of how the new code will perform in all aspects of the production environment. When you push a release to staging, you’re testing everything, not just the new code.
That’s what a staging server is for. Now, let’s cover what it’s not for.
A staging server is not a development or debugging resource. Installing development tools on a staging server breaks the model, since you (hopefully) don’t have these tools installed on your production systems. If your development teams commandeer staging, you’ve lost a valuable way to verify releases before they go to production.
Staging isn’t a disaster recovery resource, either. Its sole responsibility is to act as a mirror of production for testing.
Why Do I Need a Staging Server?
Why not just rely on development or QA systems for testing?
Development and QA are good places to start your testing, but they don’t give you the complete picture. By acting as a replica of your production systems, staging serves an important role in helping you test all aspects of your release.
When you use staging as intended, you deploy your code there using the same systems and tools as production. Then, your operations staff takes part in the testing.
So, staging tests:
- Hardware – does the new release work on the production hardware?
- Packaging – does the new package install correctly? Can you easily revert the release with your package tools?
- Process – does the release process work?
- Monitoring – does monitoring still work? Will you need to make adjustments based on the new code?
- Software -finally, does the new release work as expected?
What’s the Difference Between Staging and UAT?
When you look at them from a distance, user acceptance testing (UAT) and staging environments look alike. Both are meant to mimic production, and you use both for pre-production testing. What’s the difference?
A UAT environment is for testing new features. But, it’s not the final check, staging is before releasing them to production. It’s where users verify that the new functionality works as expected, and doesn’t break their systems.
For example, imagine an online data provider that sells data via API connections. They would use a UAT service to test new API versions. Their clients connect to it and test the new APIs against their internal systems to insure everything works well together. This testing may go through a few rounds before the clients bless the new features and the code is ready for release. Then, the final release would pass through staging on the way to production, where operations ensure the new functionality didn’t create any new issues, and that they can monitor the new features.
So, the biggest difference between UAT and staging is who’s doing the testing and verification.
Staging is for testing by the operations team: the people who run the system. They’re testing their processes, and how the software performs. UAT is for testing by users. They’re testing new features and functionality. There’s obvious overlap there, but the differences in audience make it worth having two distinct systems.
Staging Server Best Practices
1. Replicate Production
Let’s start with the obvious one: staging needs to be a replica of production. But what does that mean, exactly?
If a staging server is supposed to mimic production, then it needs to be running on the same hardware, with the same operating system, patch versions, etc. That part is simple to understand, if not actually accomplish.
If you’re working in the cloud, this part should be easy, though. Build staging with the same templates as you do production. If you’re worried about costs, shut down or destroy staging when you’re not using it. If your systems are on-premises, building an accurate replica of production is more difficult, but still worth it.
But does replicating production end with hardware and software configurations?
No. You need to replicate your processes, too.
- Deploy the software using the same packages you would to production, using the same tools. So, if you’re pushing code built in Jenkins via a Yum server, that’s how you deploy to staging.
- Perform the same verification procedures you use when you deploy to production.
- Use the same tools as production to monitor it.
- Follow the same security model, with the same login and account restrictions.
Staging is a replica of production, and your teams must treat it as they do production.
2. Use Production Data
Regardless of how closely your staging processes and system mirror production, they’ll fail if the data they have isn’t a close match, too. You must supply your staging systems with real data. They need to be run with the same volume of data, and with items that match production as closely as possible.
Of course, this means you need to obfuscate or anonymize user data so you can protect your customer’s privacy and stay on the right side of regulations. But, like replicating production’s hardware, this is worth the effort.
3. Use Your Staging!
All this work building an accurate replica of production won’t do you any good if you don’t use it, cannot keep it up to date, or save it for big releases.
Make staging a part of your release process. If you’re using agile, release code to staging for every sprint. If you’re using continuous deployment, deploy code to staging.
After you deploy to staging, test it. Staging isn’t a rubber stamp, it’s an important stop on the way to production.
Staging Success
We’ve discussed what staging servers are, and how they help you release better code. Staging servers replicate production and act as a place for you to verify that your code will work when you promote them. After defining what staging and staging servers are, we compared them to UAT and went over a list of best practices.
If you want to take your environments and environment management to the next level, sign up for Free Kick Start of Enov8’s Environment and Test Data management tool. Contact us now to get started!
