staging environment

What is a staging environment?

A staging environment (stage) is a nearly exact replica of a production environment for software testing. Staging environments are used to test codes, builds and updates to ensure quality under a production-like environment before application deployment. The staging environment requires a copy of the same configurations of hardware, servers, databases and caches. Everything in a staging environment should be as close a copy to the production environment as possible to ensure the software works correctly.

The significance of staging environments

Steps to deploy software include development, integration, testing and quality assurance (QA), staging and production. Users have little patience for poorly performing apps, so finding bugs and software errors is vital for performance. Staging environments test on a near-production level in a nonproduction environment and can lead to further confidence in the software when deployed to production.

Staging takes place late in the software development process. Coding has been added and changed, builds are generated and fundamental testing is completed within a controlled testing environment. However, committing even a tested build to production carries undesirable risk for most organizations -- especially if the application is mission-critical or revenue-producing. By staging the software in a functional, nonproduction environment, the application can undergo a variety of additional quality and user testing.

The goal of staging is to let development teams, project managers and application stakeholders operate the software under some stress and make a final go or no-go decision for deployment. Proper staging typically yields one of the following three outcomes. In two of these scenarios, a staged build might not be committed to production:

1. No go. If the current release candidate exhibits further errors, poor performance or other issues, the software project team can curtail that development cycle and send staging results back to developers for more coding. The development cycle starts anew. Staging provides a fail-safe measure in this case.
2. No go. Current Agile development paradigms don't require every staged build to be deployed. In many cases, a staged build can simply represent the addition of some new features, functionality or fixes that benefit from examination in preproduction staging. However, the build might not be suited for production deployment perhaps because more features need to be added. This is common for continuous integration/continuous delivery (CI/CD), or CD development workflows. Staging provides for additional testing in this case.
3. Go. If the build is slated for release and passes muster within the staging environment, project teams can make the decision to go ahead and deploy the build to production. A new deployment might simply take the place of a prior deployment or use a split deployment for even more real-world testing and validation, such as blue/green or A/B deployment, which can be useful for more extensive user feedback and acceptance. Organizations using continuous deployment development workflows can commit all staged builds to deployment. But such applications are rarely mission-critical, and rollback plans are typically in place.

Types of tests conducted in a staging environment

Smoke tests and user acceptance testing (UAT) can be performed in a staging environment. Smoke tests check for essential service functionalities, and UAT is performed from the perspective of an end user. For example, if a new build undergoes development and integration, a smoke test can confirm the main functions still work properly, and UAT can ensure a good user experience from the user's perspective. Tests are performed on the staging environment because, if there's a major flaw and the system breaks, the production environment doesn't have to shut down.

Although directed testing is normally performed prior to staging, it's also common to repeat basic unit tests and regression testing in a staging environment. Unit testing basically checks individual elements, components or modules of a software system to ensure proper behavior. However, not all units are easily tested in a controlled environment. For example, a function intended to access a database might need to be tested in a staging environment where a fully functioning database with real data is provisioned to the staging environment. Regression testing is intended to recheck features of functions that were working after new or changed code is added. In simpler terms, regression testing is intended to ensure that new features and functions don't accidentally break the old features and functions.

Additionally, chaos engineering tests can be implemented in staging environments. Chaos engineering reinforces confidence in the system by constantly trying to break the code. Chaos engineering normally is implemented in production; however, it's possible to start chaos engineering in a staging environment as practice before testing in production. Chaos engineering can help to identify potential issues software might have in a production system.

Staging environments can be easily created in cloud computing, and they get deployed into production environments. This can help automate paradigms using either continuous delivery or continuous deployment.

Benefits of a staging environment

A staging environment offers several benefits for software developers and businesses, including the following:

• Better testing. Deploying a tested build to a staging environment lets developers perform an array of advanced software testing in an environment with infrastructure, services and data sources that are close to, or even possibly identical to, an actual production environment. This helps to catch performance, integration, reliability and acceptance problems that could escape earlier testing efforts.
• Enhanced quality. Successful results of software in a staging environment can enhance the organization's confidence in the integrity of a release candidate, resulting in fewer defects and better quality upon deployment to production.
• Less liability. Businesses can potentially use staging to improve their regulatory compliance and business governance posture. Because businesses are dependent on software for revenue and everyday business interactions, staging can be seen as a means of improved due diligence in product testing and QA before release – especially for critical software in highly regulated markets, such as finance or healthcare.
• Improved marketing. Staging environments are outside of production but can be opened to any user group. Some businesses might use staging as a means of providing users with sneak peaks, early access or advance demos of impending releases. This can help to improve the strategic marketing of new software releases or important upgrades.

Staging environment limitations

Although staging environments provide an additional layer of confidence in a system, staging still has limitations, including the following:

• Limited simulation. No matter how well a staging environment replicates the production environment, there remain scenarios that can't be imitated. For example, it can be extremely difficult or impractical to replicate high volumes of traffic to test the application under stress.
• Mismatch errors. If a staging environment is built incorrectly or is poorly utilized, then more problems might occur. If the configurations of both staging and production environments don't match, the data gathered from the replicated tests isn't accurate. Defects could potentially get released to the production environment. For example, code should be stored in the same way in the staging environment as it is in the production environment. If that doesn't happen, the latency test results could differ.
• Plan for long term. Testing in staging environments in a limited-time capacity can create other issues. Some complex problems, such as data corruption or memory leaks, might take longer to manifest. To avoid this problem, staging environments should be able to run as long as production environments run.

Alternatives to staging

Some companies choose to skip staging in favor of alternative deployment strategies.

A large amount of data can be pulled from a production environment, including information that couldn't be obtained through staging, such as amounts of user or data traffic. If an organization uses data from the production environment to create and maintain changes, it can save time compared to copying, managing and gathering data from a staging environment. Working within a production environment is faster. There's more upkeep with a staging environment, as new builds and fixes are prepared frequently and must be implemented in staging and then in production. However, the choice to skip staging is done at the risk of less confidence in the system and the possibility of introducing major problems to the production environment. Consequently, the choice to omit staging is often restricted to experimental or noncritical business applications.

Foregoing staging is common in environments that embrace the practices of immutable infrastructure. Rather than pursue upgrades and changes to an existing application, each deployment cycle is released as an entirely independent entity, and users are routed or cut over to the immutable new deployment. Any prior deployment can easily be restored if necessary.

Another alternative to conventional preproduction staging is a parallel deployment, such as an A/B style of deployment, where the old and new software versions temporarily exist together in the environment. This is sometimes referred to as staging in production. The new deployment is gradually opened to systematically expanding groups of users until finally all users are employing the new version, and the old version can then be retired. If the new version encounters unexpected issues, the old version is still running and available, effectively providing a rollback option for the business.