Tips for a Virtual Development Environment
How long does it take for a new developer in your organization to get their environment set up?
I’ve seen it take anywhere from a couple days to a week depending on the environment.
A few years ago, I joined a project that had an interesting requirement: They would NOT be supplying development workstations for us to use… we must supply our own.
This requirement caused us to go down the path of running our development environments in a virtual machine. Well, I had heard horror stories of companies trying to do this using VMWare locally and Citrix server solutions, but two things were different now… Memory and Solid State Drives. It was no longer unreasonable to purchase a machine with excessive (16 GB+) memory and an SSD.
So, we embarked on the path of virtual development environments and found it to be successful.
Clarification note: I will be discussing localized virtual machines in this article. I’m not an advocate of “cloud-based” development environments (yet). If possible, I prefer to be able to code without requiring a network connection.
You may ask why? What value does setting up a virtual development environment provide?
- Fast Setup for New Developers: On my project, we had a new developer up and coding in a couple hours.
- ~1 hour to get logged in, install the VM software, and download the image.
- ~1 hour to pull down the source code, run the initial build and walk through the environment configuration steps.
- Environment Consistency: No more choices about where to install software or what versions were being used. You can sit down with any developer and things are where they should be. (…for the most part)
- Fast Recovery: As developers, we like to play with stuff. New tools, versions, configurations, etc. With a virtualized environment, there is no risk anymore. You can try out things and easily revert back to a good state, or start with the latest image again.
Since we had minimal investment in our virtual development environment approach (described below), the primary risk was performance. And yes, the native performance was always faster than the virtualized development environment on the same physical machine. But when adequate hardware was used, the difference was not significant enough to cause concern.
Memory Is King!
When you are firing up a “guest” virtual machine instance, you will assign it a certain amount of memory. If you’re talking about development tools, it will likely need to be somewhere around 8 GB. Therefore, the host operating system will need at least 8 + 4 GB to run its own stuff. Thus, 12 GB gets you off the ground, but doesn’t give you much room to move… so max it out. Relative to a developer’s time, memory is cheap, and putting 32 GB in a dev box is not unreasonable.
Windows Swap File Note: You should read this Microsoft Knowledge Base article on swap/page file settings if you want to adjust your swap file size.
One of the biggest performance improvements that you can give to a developer is a solid state drive (SSD). These are now affordable and should be the default choice for any new development box. You can often couple it with a secondary hard drive if additional storage is needed.
For the project I was on, we used VMWare Workstation/Player, but the experience is similar with VirtualBox or Hyper-V.
Install and setup your preferred virtual machine tool. Wikipedia has a comparison of different tools.
Configure your VM and start with a base operating system image. Be sure to run any system updates.
Create a wiki page or some document to track the changes and installation steps.
Publish the Base Image
Make a copy/archive of this base image so it can be used if you need to start over, or configure a new environment. With VMWare and Hyper-V, you can simply copy the virtual machine directory with the configuration and virtual disk. With VirtualBox, you should use the import/export functionality.
Install Initial Software
Go through the process of installing all of the initial software on the VM.
This should include any development tools such as the IDE, plugins, source control, local app servers, database servers, browsers, etc.
Perform any standard configuration of the tools. Remember, the goal is to minimize what a developer has to do to get their environment up and running.
Carefully document all of the software installed and the steps used to install and configure it. This will come in handy if you want to automate the installation later or need to start the process over.
Before “finalizing” the image, document and run through a set of standard “cleanup” operations. These operations should be run every time you update the image and may be refined as the image is modified.
- Run any operating system updates
- Update the browser(s) and clear the cache
- Update other tools (e.g.: Flash Player, Adobe Reader, text editors) that require periodic updates
- Empty the “trash” folder
- Delete the files from the Temp directory
- Delete any downloaded files not needed
Once the image is ready, save a copy of the image and label it with a date or version. Then upload the image to your network or portable disk for distribution.
Load the Image
Find a developer willing to try it out, load the image onto the machine, and start it up. (This might be yourself.)
Go through the process of configuring the virtual development environment to the point where you can perform typical development and testing.
While going through this process, document the steps taken to make it easier for the next developer.
Also, make notes about ways that you could improve the image and set these up as to-do’s for the next revision of the image.
Revise the Image and Republish
Once you have enough items to stamp a new image, load up the original image, and work through your to-do list. Don’t forget to run your cleanup scripts when complete.
While you are updating the image, be sure to document the steps so that anyone with an older version of the image can bring theirs up-to-date without having to switch to the new image.
Document, Document, Document! Keeping a clear record of what you did to your image will help you and other developers down the road. This is especially useful when you have to uninstall/reinstall or reconfigure tools in a later version of the image.
Snapshots in VMWare and Virtualbox allow you to set a “known good state” which you can revert back to if something fails. Hyper-V offers the ability to use differencing disks, which allows you to isolate changes after you’ve built your golden image, and roll those changes back at any time.
For Windows VMs, you should consult with your Microsoft representative to understand your licensing entitlements. You may need to use tools like sysprep or slmgr to reset/update the activation key. Also, Hyper-V may be a better choice to help ease some of this pain.
Just a Starting Point
I’ll be the first to admit, this is not “ideal”. In a perfect world I would use tools like Vagrant or Docker to build images and Chef or Puppet to script the entire virtual development environment configuration, but sometimes you need a starting point.
If this is your first foray into virtualizing your development environment, it can be very daunting when you look at all the tools out there. The process above can help you get started using simple tools and processes that you are already familiar with and then you can evolve over time.
The Return on Investment calculation is very simple. Here is an example.
Without Virtualized Environment
- Dev environment setup time (e.g. 3 days = 24h)
- * hourly cost (e.g. * $75 = $1800)
- + troubleshooting time from current staff (~$200)
- = $2000 / Developer and 3 days of lost productivity
With Virtualized Environment
- Initial Time to configure VM (e.g. 5 days = 40h)
- * hourly cost (e.g. * $75 = $3000)
- Reduced Dev environment setup time (e.g. 4h)
- * hourly cost (e.g. * $75 = $300 / Developer)
- + 32GB of Memory (~$200 / Developer)
- = $3000 initially + $500 / Developer
This doesn’t take into account maintenance time, but it would effectively wash with the extra time performed in the manual setup for each developer.
The quick takeaway is:
- Virtualizing your dev environments can save you time and money… significant time and money over a large team and long term projects.
- Spend money on memory, virtualization will fail without it. The SSD is not essential, but greatly improves the experience.
- Start simple with a manual process. Don’t get bogged down in automating everything initially. If it works and catches on, you can grow it from there.
Want to try it out?
Download and install VirtualBox (it’s free).
Configure a VM, associate the ISO disk image to the Optical Disk, and start the VM.
You are now on your way… Enjoy!