Customers benefit from a Dev/Test by being able to quickly launch new VMs within minutes, perform testing of an application, and turn off the Dev/Test service when it is no longer needed. Because all the servers are hosted with VMs in the cloud, the consuming organization does not need to pre purchase and deploy a dedicated server farm, sitting idly when an application development team has finished their work, or between application releases. Dev/Test teams often utilize numerous VMs residing in on-premises private cloud facilities or in a public cloud. Then, there are multiple work streams, multiple development teams, testing and quality assurance teams, and multiple versions of each application being developed simultaneously—all of this benefiting from the elasticity and pay-as- you-go features of a private or public cloud.
A good example scenario is when the application development team needs a new 10-computer environment deployed. With one purchase via the cloud management portal, 10 new VMs are provisioned with two clustered SQL servers, two frontend web servers, two middleware application servers, and four QA workstations (to be used by the development team for testing). Upon launch, the application team can load its custom application code and begin further programming or testing. It can add or remove additional VMs as needed or take a “snapshot” of the environment, test the system, and roll back the entire 10-system environment to the snapshot state, retrying its test each time based on the snapshot image.
There are often many versions of the environment held on the storage system so the development team can roll backward or forward to various software versions. The development team can also operate multiple sets of the 10-system environment so that the operations team can do routine testing or troubleshooting against a copy of the production code while the development team works to develop the next release. This requires multiple sets of the 10-VM environment, but this is economical because everything is based on VMs that can be brought up and down, paying only for actual usage to the cloud provider.
Specific features of a Dev/Test environment are detailed in the list that follows (the basic offering and systems architecture is the same as IaaS, which means there is a pool of physical servers, each running a hypervisor system providing capacity for hundreds of thousands of VMs on-demand).
Many organizations have strict policies and procedures that must be followed whenever a new VM or application is installed in the production network. In a Dev/Test environment, the application developers need to have the ability to quickly bring VMs up, reconfigure them, install application code, test the code, and then shut the systems down. All of this is performed regularly during the time a development team is creating its application for production release, and can last for months. For the developers to have this freedom without being restrained by paperwork, isolating the Dev/Test network from the production network using a firewall is a common technique.
Even if both the production and Dev/Test networks are hosted by a cloud provider, organizations want to protect their production network from untested or new application code. Some Dev/Test systems provide a separate subnetwork for each application project, so that one application development team cannot interfere with others. This protects other development teams from such possibilities as an untested, “run-away” application clogging the network with traffic.
The ability of the application development team to make a backup or snap- shot of a VM is important. This snapshot saves a copy to disk and makes it possible for the development team to run numerous copies of its system. It can perform testing against a copy of its environment rather than on a single instance, and avoid potentially messing it up. If testing is successful, a rollback of the environment is not necessary, and this set of VMs would become the new baseline release. This feature is a very significant benefit of using VM/ hypervisor technology, and by paying only for the usage of VMs and storage, the consuming organization truly benefits from on-demand just-in-time provisioning and shutdown in developing its application projects. Creating numerous copies of VMs with many different versions can consume a great deal of storage space; thus a great deal of storage space can be required by the system. To keep costs low, delete older copies that are no longer needed.
Many application development teams use ALM tools to help coordinate and facilitate the development process. You can install these tools on one or more VMs within the cloud, alongside the application VMs and database systems. The application development team uses the ALM tools to track its project milestones, maintain a code repository, perform QA checks, per- form load testing, and promote application revisions from Dev/Test into production. Popular ALM suites in the industry include offerings from Microsoft, IBM, and Hewlett-Packard. There are also smaller tools, and even open source tools, that an application team can use. Additionally, some cloud service providers that offer Dev/Test will offer the ALM suites as an option—this is a nice benefit, because the ALM suite will already be configured and ready for use upon ordering, and the licensing costs the cloud provider charges might be less than a single customer would pay for its own copy.
Promotion into staging and production
Some Dev/Test offerings provide the application development team with the ability to promote individual or multiple VMs to the next phase of the application lifecycle. For example, when all testing of an application release is completed in the Dev/Test environment, clicking a “promote” button would automatically copy or move the VMs to a staging or production network within the cloud provider’s datacenter, facilitating an Agile software delivery and continuous application delivery automation. An additional benefit to the customer is the ability to launch a new release of its application into production while maintaining the availability of its Dev/Test environment for the next release. If the Dev/Test VMs are no longer needed, they can be de-provisioned and the customer stops paying for them.
