You may ask why use an Oracle (formerly Sun) VirtualBox (VBox) Virtual Machine (VM) for a development environment when coding? From the perspective of a developer on your team, the answer is, for several reasons:

  • We can have the same development environment regardless of our desktop environment.
  • We set the VM to 512mb memory to start, which is like the remote VPS server environment. This is nice because you can scale memory and/or cpus up or down at will, and instantly with a few clicks. A great way to test your application under various loads.
  • By starting the hardware resource limits low (mem and cpu), we limit how greedy the stack can get. If the vm freezes, the rest of your system does not.
  • Starting with constraints forces us to build efficient code from the start, instead of refactoring for efficiency later (which realistically never happens). The same is true for bugs affected by the environment, which previously you would only encounter once you attempted to deploy to a remote development or production server. When you are deploying to production, that is too late to be finding out you have bugs related to environment differences.
  • With VMs you can take snapshots of the hard drive at any given point in time. Snapshots taken thereafter are similar to version control in that only the differences are actually saved. So it’s efficient, quick, which means less expensive. When you mess something up with the install or environment you can just roll back to a time when everything was working.
  • The use of snapshots can become like a form of unit testing. You can make copies of working environments to start new projects. You can test source code (e.g. from outside the VM over a mounted vboxsf or nfs share) in different points of the snapshotted environments.
  • Also, consider your other projects not in a VM. When you need to switch gears, you just start or stop another VM. It takes a few seconds, and you can be running several different versions of Apache, PostgreSQL, Ruby, PHP, and all other sorts of programming tools. This gives you precision in developing. No longer do you have to hold back to the old verisons of software in order to stay compatible with all projects. You can develop your applications on the bleeding edge of technology. And save resources by only running the tools you need when you need them.
  • Once you get the vm setup correctly, you can quickly send the entire environment to your peers. For teams on a gigabit LAN, the time to transfer a typical 1GB virtual disk image (*.vdi) is trivial. For teams across the planet, preparing instructions like the ones below are often faster and take on average 1-2 hours to complete. Not to mention if you put it on a USB drive you can take it with you anywhere you go.

There are more benefits as you will see through using it, but you’ll need memory; at least 1.5-2gb is preferable. Less is technically possible but you’ll see performance hit depending on the size of your VM.

Ultimately, the result for those using the vm image is an instant development environment, with no dependency conflicts, configuration quirks, or hardware differences. On average with this I have new development team members able to join the team brand new and start contributing meaningful code in as little as 6 hours on average, versus 24-32 hours for the non-vm approach. But with the non-vm approach you have to consider all the problems you face down the road that end up being  environment differences.

Below is a pseudo bash script outlining how to prepare one of these virtual machine images (*.vdi) using Ubuntu 10.04 (Lucid Lynx) 64-bit.

UPDATE: I haven’t used this script in a few months now; I found it easier to make a base image and use the `VBoxManage clonehd` cli command to copy and modify. There are numerous reasons for this but among them: its faster, its easier, it has all the latest updates including any quirky setup preferences you may have at the time. But the script below is still good for getting your first few images started.

(more…)