There are many points in the SDLC outside of the pure software development process in which virtualization delivers important productivity benefits.

by Andrew Binstock

The software development lifecycle (SDLC) provides many opportunities in which virtualization can deliver key benefits. In almost all these situations, the advantages conferred by virtualization would be very difficult to duplicate with other technologies. For this reason, virtualization is finding significant adoption in software-development departments of enterprise IT. This article looks at innovative use cases in the extended SDLC and discusses ways in which virtualization can bring new, and perhaps unexpected, benefits.

In the scenarios I am about to discuss, two key attributes of virtualization will play a central role: virtual machines (VMs) are easy to copy and cheap to discard. Virtual machines exist as simple files. They generally comprise two files: a small configuration file and a very large file that mimics the VM’s disk drive. When the VM boots, it checks the configuration file and then reads from the simulated disk drive, which contains a simulated filesystem holding all the VM’s operating system software and applications. When the VM is running, any data it writes to a local hard disk are written to this file (networked drives are obviously not included, as they are not considered local). Therefore, any time the VM is not running, someone can clone the VM by simply copying the configuration and disk files, and thereby have a complete copy of the state of the VM.

To run the cloned version, a few points need to be borne in mind. The first is that the cloned version cannot be run simultaneously with the original VM on the same network, without some intervention. The reason is that the original and the clone have the same IP addresses and the same MAC addresses, which will cause havoc when the second VM is run. This problem can be resolved using lab manager software (such as VMware Lab Manager from VMware or VQMS from Surgient) or by modifying the values manually. A second issue is that the configuration file might need to be changed if the cloned VM is run on a different system. This file tells the VM where the hard disk file is located, and so if the latter file is relocated, the configuration must be updated. Other than these two items, however, it is trivially easy to save, clone, and run multiple instances of a VM. (Licensing constraints for operating systems and applications still apply in most cases.)

Today, it is increasingly difficult to do research for a project without spending a considerable amount of time on the Web. Web-based research can be used in requirements gathering, tool evaluation, design, and in resource location (such as open-source products or code snippets), and the like. The trouble with this research—especially if spidering is involved—is that malicious sites can lurk among sites that appear useful. Malicious sites today attempt to infect a system that simply visits a home page, so there is danger in automating searches of any kind.

One way to protect the site from malware is to do Web searching from inside a VM. If a VM becomes infected, you simply throw it away, pull over a copy of the original, uninfected VM and continue searching. Because all writes in a Web se arch should be done to the VM’s local disk, all viruses, rootkits, and other maleficent packets will be written to the VM’s single virtualized hard disk, and so infection is contained to that single file. If you run the virus from within the VM, of course, you run the risk of spreading it to other systems on the network. But even this can be controlled, by allowing only certain traffic in and out of the VM. Cookie and password management provides a few administrative issues for this protection, but these are fairly straightforward to solve and they are far, far easier to handle than rebuild a developer’s workstation from scratch because of an (avoidable) infection during a Web crawl.

Many large projects involve some evaluation: be it of developer tools, competing solutions, components for possible use, and open-source solutions. I discuss using virtualization in evaluating developer tools in a companion article on this site. Examining competing products, especially if your firm is an ISV, is a critical step in requirements gathering. To evaluate your competitor’s alternative, you want to make heavy use of VMs. The first reason is that you want to install their software on a clean system, so that you can make sure you’re examining it in a standard, vanilla environment. In some ways, this VM is a control environment. Once you have the software loaded and running in a VM, make sure to make a copy of the VM. This clone permits you to re-create a new copy of the fresh install at anytime. This is a backup option of sorts that leaves you free to manipulate configurations and options on the existing evaluation VM to your heart’s content.

If you discover a bug or problem that you want to share with the team, you can save the VM in which it occurs and email team members to run the saved VM and look at the problem. To avoid them changing the error condition while looking at the VM, you can make a separate copy of it before you alert them to the problem.

In this manner, you should be able to build up a series of VMs that highlight various difficulties of competing products (as well as their strengths). These snapshots should be stored in a library of sorts for subsequent examination and as linkable artifact for anchoring specific product requirements. If used in this way, the VM library also suggests functional test information that QA engineers can write to duplicate competitor’s limitations and make sure they do not appear in your current product.

While VMs take up a lot of space, this library should be kept even after a product release. It represents useful field work that teams in other departments can use. For example, sales teams might be interested in the VMs while designing slide decks that showing defects in the competing products.

Many projects today involve teams with skills in multiple disciplines. Frequently, engineers with one set of skills use tools that are designed for their domains only—this is the logic behind the new role-based tooling that is emerging from application lifecycle management vendors. Some products go beyond role-based definitions and use personalized profiles. A good way of enforcing role-based tooling is to provide developers with a VM within whic h to work. This VM comes with a specific tool configuration that is then loaded onto the developer's workstation. Given the speed of today’s platforms and the low overhead of most virtualization software, a developer working entirely in a VM will quickly lose the awareness that the desktop is virtualized. Meanwhile, the site has been able to limit access to tools with expensive licenses to specific users. Moreover, managers can be assured that developers are using the approved tools, platforms, and configurations.

This feature will seem an odious to some senior developers or those working at small sites, where all developers have universal responsibility. Even in those environments, however, this approach of prescribed environments running in a VM makes sense for two particular constituencies: new hires and interns, and off-shore developers. In the latter case, especially when you don’t have control over the team members, it can be very good policy to use VMs to make sure the correct tools, libraries, and other artifacts are being used.

The article I referred to earlier explains how VMs can also standardize the target platform for which software is being written. At many sites, the developer workstations are generally exceptions to the platform configurations prescribed for user laptops and notebooks. For a development site to make sure it is testing new code on a true instance of the user’s environment, it should keep a library of VMs with all approved user system profiles, and clone a copy of the profile every time user testing is required. Because VMs are cheap to clone and discard, sites should make sure every round of testing starts with fresh VMs, not ones modified by earlier testing.

SDLC definitions frequently include application support as an important part of the final step: maintenance. Regardless of how SDLC methodologies play out at your site, it’s clear that support questions which cannot be fielded by front line staff often make their way back to development staff. So, one way or the other, development is involved if the support staff does not have the needed tools.

An emerging approach is to provide the staff with a library of VMs, in which the software has been preinstalled on the various officially sanctioned platforms. In the event that a call comes in that is not immediately familiar to the support engineers, they can pull down the VMs they need and configure them to imitate the user’s environment. For example, if the user is running a Microsoft Windows 2000 Workstation client that is tapping into a MySQL database running on a version of Linux, via a JBoss instance running on Windows 2003 Server, the helpdesk staff member can pull down these VMs from the library put them into a single configuration on a VM host and have before them the same situation that the user is inquiring about. Because this arrangement can be set-up fairly quickly, (while the user is on the phone), it becomes much easier for both user and helpdesk to discuss the same problem and work together. In many cases, this step avoids unnecessary on-site visits by support staff.

If the user has an unusual problem, the entire set of support VMs should be archived. A link can then be sent to the dev team, so that they can see the problem for themselves and step through it to find the cause and fix the problem.

Likewis e, the helpdesk can reuse the archived VMs in the event the user’s problem is not completely fixed: If the user calls in again, the saved VMs can be downloaded and the conversation can pick up where it left off.

In this article, I have examined use cases that arise from the SDLC, without focusing on the pure software-development activities. Those processes and the benefits they can realize from virtualization are discussed in depth in the companion article I referred to earlier.

I think you will discover what many enterprises have found: that the more you use virtualization in the SDLC and in IT, the more you find new use cases for it. Enjoy!

Andrew Binstock is the principal analyst at Pacific Data Works LLC, a firm that specializes in technology white papers. He will be lecturing at the InfoWorld Virtualization Executive Forum in New York City in September. He can be reached at abinstock@pacificdataworks.com