twobee - Fotolia
Apply staging environment best practices to an app lifecycle
From the public cloud to blue/green deployment, there are a myriad of ways that IT teams can make the most of their staging environments -- and use resources they already have.
Application lifecycles are complicated. It can be a significant challenge to get new application versions into production -- and nobody wants to encounter surprises. A staging environment can expose these surprises before they affect real users.
Staging, also known as preproduction, replicates a full-sized production environment to test changes before they hit production. Automation and public cloud platforms enable an on-demand approach to staging environments for final testing of production changes. And the blue/green deployment methodology promotes staging environments to production once validation is complete.
Staging vs. dev and test
The central objective of a staging environment is to mirror the production environment without actually being production. Development and test environments are often shadows of production, scaled-down with less redundancy and, typically, only a subset of production data. These environments are designed to cost less than a full-featured production mirror.
A full-sized staging environment facilitates more comprehensive testing because it closely replicates production. Staging is also usually where the external system integration and scalability testing occurs. A staging environment is the final safety check; it provides the highest-fidelity testing before admins deploy changes into production.
Automation drives staging environment best practices
Many staging environments exist only for the duration of a deployment; they're created for final testing and then disposed of after code hits production. For each new application or version test, a new staging environment is created -- for that test exclusively. But automation cuts down on the manual work.
One approach to spin up a staging environment is to clone production, which works well if the production environment is a collection of VMs. If there is a disaster recovery platform for these VMs, then it can also serve as a staging environment, because it already has a copy of production. For organizations that use automation for production deployment already, an alternative is to use that same automation to deploy a staging environment. Whichever automated process is in use creates a staging environment that replicates the current environment so that the staging test results accurately represent the final changes in production.
Something for everyone
Rather than a single test server or a push straight to production, operations staff can use a staging environment to test infrastructure changes, including Windows version upgrades, management product rollouts and even patches to critical systems.
Cut staging costs with the public cloud
Public cloud platforms provide an ideal location for staging environments -- even if the production environment is not in the public cloud. Programmatic control of elastic resources is a central idea on public cloud, as is paying only for resources actively in use. An on-premises staging environment usually involves buying equipment that IT uses only a small portion of the time. But, in the public cloud, an enterprise stops paying for the staging environment when it disposes of it and pays only for the resources required to test. It is far more cost-effective to replicate full-scale production if an enterprise only has to pay for the resources while it uses them.
Combine usage-based billing with the extensive automation available on the public cloud, and you have a recipe for an on-demand staging environment that enables comprehensive testing of more changes before they reach production. As with all public cloud resources, dispose of them and stop payments when they aren't in use.
Blue/green deployment
Admins can also promote a staging environment to production in place of the old production environment. In blue/green deployment, there are two production-level systems: one that runs the current release and one that has the last or next version. The two environments swap roles as new versions are released -- the current active environment is never updated.
Updates are applied to the inactive environment and tested there. During this time, the inactive environment is a staging environment. Once the updates pass all testing, production traffic is slowly transferred to the new environment. The old environment is still available to fail back to if the new version has issues. Once the new version is active, the old -- now inactive -- version is available for updates, and the process begins again.
