There has been a lot of talk about the benefits of virtualization especially in the field of server consolidation.
VMWare has tried to expand the field with it’s virtual appliances and Parallels has defined a whole new paradigm of usage with it’s Coherence functionality.
Already a lot of web developers use VMs to run different versions of Windows so that they can test with IE 6.0 and IE 7.0. Let’s call it “desktop consolidation”
I have gotten into the habit of creating a VM for each project I participate. For Windows-based development this saves me a lot of time and grief since there are projects that use VS 6.0, VS 2003 and VS 2005 (or Eclipse 3.1, 3.2 or 3.3 – pick your own poison). Installing all three on the same machine produced an unusable behemoth with all sorts of problems.
I also need to mention the fact that I am a mac convert, which means that all my Windows development work is done on a virtual machine.
There are less problems transitioning between projects, which allows me to provide troubleshooting and maintenance services with a minimum of effort and confusion.
Typical problems of the sort “hmm, this bug is not reproducible in my computer. Oh my, I installed the latest XYZ for project X, while the client for project Y still has the old version. Now how do I go back to that version in order to debug the problem?” are no longer an issue.
Since it is very easy to clone a VM, the easiest way to implement a one-VM-per-project scheme is to have a “clean” VM, a bare OS installation, which is then copied and customized for each project. That VM is then cloned for each team member.
This method saves a lot of time in the preparation of development workstations, as well as in troubleshooting potential environment problems. Since the baseline for every VM is the same, most changes in the development environment can be easily tracked and accounted for.
Also (this is just empirical evidence with a not very wide sample number) people tend not to mess as much with a VM since they still have their own environment as the host.
Couple a project VM with a well thought instalation policy out of the project’s repository and you get a very effective upgrade/update method:
The project VM is updated/upgraded and tested while the project team is active with the current version. When all tests are passed, the team discards the old VMs, gets a fresh copy of the upgraded one and continues working with a minimum of disruption.
VMs also come in handy when the need arises to create a more realistic testbed for an application. It is simply the quickest way to setup a test network.
Ofcourse there are always problems, mostly stemming from the thousand different ways people have to do their work, which means that it probably is not that simple to discard a VM and get a new one.
So this method needs to be tightly coupled with the development process and it’s caveats (“don’t keep non-versioned data in the VM” comes first to mind, “always commit everything before changing VM” is a close second) clearly documented.
And the increased cost in hard disk storage and memory is something to think about:
For my 2.33GHz 2GB Core 2 Duo MacBook Pro the limit seems to be two 512MB WinXP SP2 VMs (with Parallels).
Using a 400GB Firewire external disk takes care of any space issues without a noticeable loss in speed.