Children’s sandboxes are a protected space where kids have complete control and others are only allowed to join by invitation. Children bring their own toys to the sandbox to make whatever they want in the sand. If they don’t like the results, they can just stomp out the project and start again.
Cloud sandboxes serve a similar function as part of DevOps, enabling developers to build and test new applications in cloud sandboxes, then just tear down the virtual sandbox environment when testing is completed. In addition to being a temporary protected space for testing, sandboxes are also self-contained infrastructure environments that can be configured to behave exactly like the final production deployment environment.
Performing testing without a sandbox is tantamount to dropping new software applications into a production environment untested. Sandboxes provide crucial insights for application testing before any new application goes live.
What’s in a Sandbox?
A sandbox is a replica of any target production environment that can be used outside of production for development, testing, or staging. Sandboxes can be designed to include physical, virtual, and cloud infrastructure as well as all of the tools and data needed to re-create a target environment. Putting the applications to be tested in the sandbox is also an important part of creating this kind of an environment.
Sandboxes are created from blueprints on demand. When users (or automated processes) are finished with them, they are automatically torn down. Most sandboxes feature reservation systems that allocate infrastructure resources and deploy all of the virtual and application resources automatically. In this way, teams of developers and testers can share physical and virtual infrastructure on the fly for hours, days, or even weeks at a time. When a project concludes, other testers can access those freed-up resources.
Since sandboxes automate the creation, deployment, and teardown of complete environments, the sandbox environment and infrastructure will always look the same – from the development lab to the test lab, to the production data center and the cloud.
Putting the Power of Sandboxes to Work for DevOps
Sandboxes can help enterprises implement a DevOps strategy for continuous software development. Based on lean manufacturing principals, DevOps methods can help speed up development for any kind of application, regardless of the type of deployment environment.
The biggest benefit of sandboxing involves the capacity to create exact replicas of even the most complex hybrid cloud environments. This includes any mix of data centers, public and private clouds. Managers of data centers and test labs rely on cloud sandboxes in development, testing, and staging of new applications to identify how they will impact the existing production environment before deploying them.
Since sandboxes are fully automated environments, they can be initiated through other DevOps tools, such as continuous integration tools like Jenkins and Travis, or through DevOps pipeline tools like CloudBees Pipeline, Microsoft (News - Alert) TeamCity, and others.
For DevOps to succeed in highly regulated industries such as banking and financial services, security testing should be built directly into the DevOps cycle to enable continuous deployment. Sandboxes provide a stabilizing tool for that process by ensuring that new applications will integrate with the legacy software environment.
Enabling DevOps in Enterprises
Large enterprises struggle with implementing a full DevOps process because they have many applications that are a mix of both legacy and new applications, and they often have complex data center infrastructure or hybrid clouds. Sandboxes can help to rationalize this complexity to enable the implementation of continuous integration or continuous delivery in enterprises. Without sandboxes, it can be difficult to arrive at a common environment across dev labs, test labs, and production environments that will work for a wide range of applications. But with a cloud sandbox, each user can define their own blueprint for the environment that they are developing or testing in. Many groups can use a common tool but use it to meet their diverse needs. Any type of sandbox blueprint can co-exist in the same common DevOps pipeline, enabling legacy software teams and new application teams to share a common process and set of tools.
Getting Started with Sandboxes
The best way to get active with sandboxes is to get one or a few dev and test teams working with them. Team members can gain experience without large costs and allow team members to develop their own blueprints for environments for their own work.
As initial pilots expand into larger, company-wide projects, DevOps teams can be broadened to become more inclusive and cross-functional across the company. At this stage, DevOps program leaders should assess which functional group has achieved the greatest success in rolling out cloud sandbox automation. That group can then be selected to help the other functional groups expand their automation efforts.
To become stronger and more agile, IT organizations can deploy sandboxes for continuous software development. Sandboxes simplify the creation of diverse and complex environments for dev, test, and staging across a wide range of applications – both legacy and new. Yet Sandboxes fit smoothly into DevOps pipelines. This strategy enables users to bring products to market faster, increase IT efficiency, and cut out unnecessary costs.
Joan Wrabetz is the CTO for Quali.
Edited by Alicia Young