Give Your Projects Separate VM's (Go Vagrant)

April 10, 2013

Sorry, this is long.
I've been experimenting with Vagrant (www.vagrantup.com) over the past week couple weeks in preparation for a couple of group coding projects at the University of Notre Dame.

It's been interesting as I've talked (ok, preached) about Vagrant to some of my colleagues to see how many of them have some level resistance to the idea of using a virtual machine to encapsulate a project.

It seems to some folks feel that creating a VM for a project is:

1. overkill and/or
2. slows down the development process. Let's explore these objections.

Objection 1: Creating Development VM's for Projects is Overkill

One of the two great powers of Vagrant and tools like it is that it creates a uniform environment/configuration on which teams of developers can build a product together while preserving their ability to edit the files on the VM using their preferred tools from the Host machine.

It is, in the mid-to-long view, a great advantage to have anyone, on any host platform (Windows, Mac, Linux Variants) be able to simply work on building features rather than on managing the minutia of server/system configuration such as the following example:

1. Correctly installing the Oracle Instant Client on their particular platform (real pain in the a** if you use a debian flavor of linux - thanks Oracle).

2. Obtaining the necessary configuration files / settings from the DBAs, putting them in the right folder structure, and setting up the environment variables.

3. Wasting hours to discover that 'pip install cxOracle' works with Django but 'pip install cxoracle' doesn't.

With Vagrant, one developer simple gives another (probably via Git or some other source control system) a few configuration files and BAM, you've both got the same environment (which has all the configuration crap done) and you're ready to code. Without Vagrant, the 2nd developer has to repeat all the configuration steps as the 1st developer did. Let's just hope their both using the same OS.

In an environment where there is generally a 1-1 correspondence between developers and projects, this great power seems less important, because the developer is going to have to do all of the server/system configuration anyway. But as soon as you want to start working together with others, this power is of great value - even if it takes a while to learn how to use Vagrant to configure your development VM's.

Objection 2: Creating Development VM's Slows Down the Development Process

Yes, In the beginning it does.
But, It will save you alot of time later.

In my case, I was setting up a VM for some Python/Django experimentation, and yeah, it took longer than it would have to just get things setup on my local machine (because I already had a lot of it there from previous work).

We've already covered how using Vagrant will save you time when doing team based development, but there is another great power of Vagrant (i.e. development VM's) that will save you time. That great power compounds with each new project you work on. Simply put, it is the power of encapsulation, or of 'keeping all the things clean'.

Virtualenv made having multiple python projects on the same system much more feasible by allowing the intelligent management and separation of python environments (interpreters + 3rd party modules). But the problem was that it only separated the python environment, not the entire project environments (databases, operatings systems, etc).

Vagrant allows us to create truly self-contained projects in a clean and efficient way that can reside on a single host machine. If you've ever found yourself trying to deal with the bloat of having installed MySQL, Oracle, PostgresSQL, Apache, Gunicorn, Unicorn, etc. on your system while at the same trying to keep their relationships to your various projects I'm sure you'll see the value here.