DevOps isn't just about moving new code to production more quickly -- it also demands no surprises when that code arrives.
A four-tier architecture that includes separate environments for development, testing, staging and production is a common strategy to test and release software. Application changes and new features are tested and validated as they move through each environment before being deployed into production.
Staging environments allow DevOps teams to test changes on a preproduction infrastructure deployment that is essentially an exact mirror of the production setup. A staging environment lets teams execute load and performance tests to ensure that the application and supporting infrastructure can handle expected requests in production.
Building a staging environment in the public cloud
A key principle of the DevOps approach is to automate everything, including infrastructure. While it's possible to build static staging environments that never change, it's much more feasible to spin up environments on demand and simply pay for what you use and tear it down when finished.
You may need to fine-tune the exported versions of the templates to support various input parameters, customize network settings, and apply your organization's own naming conventions for certain resources.
Public cloud providers such as Microsoft Azure and Amazon Web Services (AWS) let users define and version infrastructure in declarative JSON-based templates. Engineers can version these templates in source control, just like developers version application code. A single application programming interface call during an automated release will spin up a completely functional staging environment that is an exact clone of production configurations: servers, networking, storage and more.
Cloud platforms provide a mechanism to export production infrastructure definitions to a reusable template. For example, with Microsoft Azure Resource Manager, the staging manager can deploy all production infrastructure into a resource group. This group can include virtual networks, load balancers, servers, storage and anything else the deployment needs. Once the production environment is defined, they simply export all of the resources in the group to a JSON-based template. Teams can then take this template and automatically deploy the staging environment inside a release pipeline. Once the DevOps team is satisfied with the results, they can release the changes into production, and terminate the staging environment. The next version of the application kicks off another release, which spins up a new staging environment for testing and validation. AWS has a similar model with the CloudFormation service, which allows teams to define infrastructure as code within a JSON template. Teams build a production environment on AWS and export that definition using the CloudFormer tool. This requires the user to spin up an instance running the CloudFormer tool and select the resources that are running in production. The tool will export a CloudFormation template to a Simple Storage Service bucket. Teams can automate staging resources deployment from this template within a stage in the release pipeline.
Limitations of templated infrastructure
Infrastructure templates are great for deploying a staging environment with the exact same resources and architecture that you're using in production. However, you may need to fine-tune the exported versions of the templates to support various input parameters, customize network settings, and apply your organization's own naming conventions for certain resources.
Additionally, exporting infrastructure to a reusable template does not capture the configuration of IT systems from an operating system perspective. It takes some time to craft bootstrapping scripts that can configure the servers in the staging environment when it's launched. Either bootstrap the servers to install prerequisites and applications using standard shell scripts, or deploy a more robust configuration management system, such as Chef, Puppet or Ansible. You can build custom server images with software and configurations baked in and ready to go.
Cloning application environments
If you're not using infrastructure as a service and instead use platform as a service (PaaS) offerings for your application, Azure and AWS cloning options may help with staging.
For example, if you're running web applications on Azure App Service, you can clone your existing Azure Web Apps. The Azure App Service allows you to run web applications as a managed service. However, the cloning functionality in App Service is in preview at the time of this writing and has a few limitations, as it can't clone network or auto scale settings or database content. It is also restricted to premium-tier app service plans.
AWS has several cloning options depending on your managed service. Amazon Elastic Beanstalk, a PaaS product, allows developers to focus on developing code while the service deploys and monitors the infrastructure on their behalf. Applications run in the context of a Beanstalk environment, which can be cloned to a new environment. You can also clone stacks within AWS OpsWorks, which is a configuration management as a service platform that uses Chef. In both these cases, content in managed databases are not cloned, so the operations manager must come up with their own process to replicate the data.
Because managed services can be deployed through Azure Resource Manager and CloudFormation templates, you may not need to clone an environment. You might simply deploy an App Service with a web app, or a Beanstalk environment within your templates.
Staging environments on private cloud and virtualized infrastructure
Cloning your production environment on premises can be a bit more challenging than deployments on public cloud, but as long as you're working with a virtualized environment, it is possible to automate the process. Most virtualization platforms have command-line tools and APIs that can be used to programmatically provision infrastructure.
An on-premises private cloud may have native support for exporting virtualized environment settings, depending on the platform. If not, automate staging environment deployments with scripts that deploy virtual machines, networks, storage and other configurations in ways to match production resources. Popular configuration management tools interact with common virtualization platforms, such as VMware vSphere and Microsoft Hyper-V. In these cases, you can use Chef, Puppet or another tool to automate the infrastructure, along with operating system configurations for VMs.
Some private cloud frameworks also support infrastructure as code. For example, OpenStack's Heat orchestration tool is similar to AWS CloudFormation. You can use Heat templates to define and version infrastructure and automate the deployment of a staging environment within a release pipeline.
The satisfaction of self-reliance
Self-service is a key benefit for automated deployments in the cloud, virtualized on-premises data center or PaaS deployment. Choose a cloud platform with fine-grained access controls. The identity and access management features from companies such as Microsoft and Amazon allow IT managers to be explicit about who can deploy resources and where they can be deployed. With security controls in place, giving team members the ability to spin up staging environments on their own can accelerate the testing process, which ultimately increases the application's stability and gets changes into production at a much faster pace.
