Build Machine Virtualization

So hopfully by now you've heard the term 'virtualization'.  There is a definate trend toward running production servers at virtual machines to fully utilize the capabilities of new servers, to help achieve 0 downtime, to reduce the amount of hardware needed, etc.  There's also a trend towards quality testing being performed more and more on virtual machines rather than physical machines where possible to reduce the number of physical test machines required which thus reduces price, to more easily facilitate reproducing problems, saving snapshot of problem environments, to help facilitate automated testing, etc.

So why not go virtual with build environments?

Where I work they have the concept of freezing build boxes with every release.  So at the end of a release, that build box is frozen and a new box is purchased for the next version.  This was a new concept to me.  However due to some events that unfolded when we did not freeze a build box and decided to build that version's two service packs on the same box.  Bad things unfolded.  Suffice to say, I now am all for the freezing of build boxes.  The problem is that process gets expensive and time consuming (setting up and maintaining those boxes and providing disaster recovery for all of them).

So when we got close to the end of our last version, I proposed to our project manager that we go virtual with our build environment.  I recommended buying a beefy server capable of storing multple environments and running a number of them too.  So we got a dual Xeon, 4 GB Dell server with a good amount of storage and a license of VMware GSX Server (only to find out shortly after purchasing the license that VMware is offering its Server software free in Q2 '06 - oh well, we still need a support contract).  Here are the benefits that running a build machine in a virtual environment:

• Multiple machines utilizing the same hardware - the hardware for a good VMware server may be expensive but if you freeze build boxes with each version or have multiple products, the cost can easily be made up.
• The build environment can be run on any VMware Server or Workstation (of compatible version).  This means that you don't need high-end hardware to run a virtual build environment.  Even a simple workstation computer would do.
  
• The build environment can easily be copied - for testing reasons, build machine redundancy, etc.  Obviously you'll need to worry about software licensing on the build machine if you copy it.
• Since the build machine can be run on any VMware Server or Workstation, if the physical machine dies, you can easily transfer it to another machine and be back up and running more quickely.
• Since you can just copy build machines, you can easily set up base build machine images or copy the build machine as a starting point for the next version.
• Here's my favorite: Easily archive the build machine at the end of a version.  Simply burn the image to DVDs (it is highly recommended that you have the virtualization software to span the hard disk files at 2GB - VMware definately has this functionality).  Then if you have a disaster were you lose the build machine somehow, just retrieve the DVDs, find a VMware Server or Workstation (or download VM Player) and you'll be back up in a short time.  No need to wrry about compaitble hardward.  The problem with images (such as Ghost images) is that you have to install on the same hardware or you're going to have major issues.

I highly recommend running a virtual build environment if you can.

Tags: VMware, virtualization