Why your engineering team needs Vagrant

One of the first things I told our CEO when I joined as the first engineering hire was to buy every engineer a 15″ Macbook Pro. I wanted to have a consistent development environment for my team. I created a Google Doc and at first I ran through this How-To personally on every new machine for every new hire. The last 3 or 4 hires were given this doc on their first day and their setup time became part of the “How quickly can I setup my dev box” game. The record is 4 hours but he had most of the dependencies setup. The longest was two days.

It’s All Fun and Games Until Someone Upgrades

In the last 18 months, Apple has changed the processors, memory, and countless other aspects of the 15″ Macbook Pro. OSX has gone from Snow Leopard to Lion to Mountain Lion. Ruby has gone from 1.8.7 to 1.9.3, Rails has gone from 2.3 to 3.1, and I can’t keep track of all the versions of gems that have changed. The development world–it changes fast. How bad could it be, really? Well, I include 4 different manual “patches” in that doc of mine to make mysql work. The working patch depends on whether you have 32-bit or 64-bit OSX, your version of Xcode and mysql, whether you used a tarball or a dmg, whether you use mysql or mysql2 gem, etc. Lately, I just tell new hires to try everything until they find something that works. Even for packages installed via macports, certain version of ports don’t install properly. Some of these can be fixed by editing the portfile with information culled from the Interwebs. Other times, people just give up and use the homebrew version. This is us at 10 engineers.

Remove Doubt

Development and debugging can often lead to situations where you try to find what is different about a working scenario and a broken one. If a test passes on my machine but not on yours, I don’t want to say “it could be because you’re using Rails 2.3 vs 3.2 or Ruby 1.8.7 vs 1.9.2” or god-forbid “it could be because you’re using Windows”. Ideally, I would like to say “it’s because you forgot to pull the latest code” or  “your custom configuration file is not consistent with mine”. The more differences between one environment and another means the more variables to consider–follow the rabbit down the hole.

Abstraction FTW

Just as rvm helps engineers manage Ruby versions and bundler, Ruby gems, Vagrant helps engineers manage their entire development environment. With the concept of “boxes”, an engineering team can build Virtual Machine images to suit their every need. Want to onboard a new hire? Give then a computer and have them load your team’s starter box in 5 minutes. Want to roll out security updates to all 500 of your engineers? Script everything up using Chef or Puppet and have everyone download a new box. Want to test how your app would run in Ubuntu rather than Gentoo or OSX? I just did that while writing this post. When do I really need vagrant? For small teams (2-3), you’ll probably live without Vagrant. However, if you want peace of mind or plan to scale, check it out now.

2 thoughts on “Why your engineering team needs Vagrant

  1. Do you have any strong arguments for using Vagrant over something like a shared development server?

    I try explaining the benefit of something like Vagrant, but can never quite seem to sell it to others in my org. I usually go with easy on boarding, pseudo local development w/ shared directories, clean host environments and encouragement of experimenting w/ the environment (testing new toys).

    • I would add security to that list and scalability. You may also want to try adding some data to your arguments. For example, if your on-boarding takes 2 days whereas it could take 1 hour with Vagrant, that can be roughly translated to potentially huge cost-savings for your company. There are other metrics like the amount of time wasted on cross-platform issues, etc. I would suggest you think about the metrics that carry weight in your organization and outline how this approach can boost them.

      For shared development servers, I haven’t tried that yet, but I would imagine there are tradeoffs for that approach…like requiring connectivity.

      Good luck!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s