Improving your local development environment with Vagrant

Recently I held a talk about Vagrant at our regular internal developer conference, "gcXchange". I'd like to share it with our readers, too.

As a web developer, you run into issues with versioning quite quickly, especially in a diverse work place that tends to use many different programming languages for different projects.

Imagine you have three different projects and they all use a different nodejs version, some gems for a few tools and maybe even some pythonic deps. Of course, you could use the variety of version managers and virtual environment hacks that are out there, but this approach has two major issues: You will inevitably get a huge mess of different versions on your machine and run into weird, unreproducable problems because of this; and second it is a PITA for other developers to get on the project.

I'll embellish the second issue further: Imagine you are the sole maintainer for a small project and you will be on holiday for a couple of weeks. While you are at some remote beach without any internet connection, the customer demands an important change. Let's say the change itself would take you only five minutes, but only because you have the environment set up.

Your colleague might not be so lucky and may well spend more than a few minutes trying to get the dependencies installed on their machine, hoping that you documented that process, and if you did, hoping that it isn't outdated.

The very simple solution to this problem: Use Vagrant to build your development environment. Regularly (say, every other week, or at least after you made changes to the packages) tear down (vagrant destroy) your environment and let Vagrant recreate it (vagrant up). Thereby you can be sure that if it works for you, it will also work for your stand-in and other people that need to run your code. And all they have to do is wait for a couple of minutes.

As a bonus, deployment can become easier, too! Due to the way Vagrant works, you will have a "recipe" for all the dependencies required to run your application. You might start with a simple shell script, but as you get more advanced, you might even use Puppet or Chef reciepes to build your environment!

The presentation

For some more details, have a look at the original presentation I held:

Open slides without the iframe