Better Developer Environments With Vagrant and Dotfiles
Flite Company Value #5 says, “Iterate. Iterate Again.” I recently tried applying our team’s agile philosophy to something that I’d been reluctant to change since I set it up over a year ago: my development environment.
Developer environments are fragile. As the number of tools, servers, and source repositories grows on your laptop, writing code and testing it inevitably becomes more challenging as you switch between projects. Using vagrant, an open-source tool for creating virtualized developer environments, and a customized dotfiles repository, I created a portable, easier-to-work-with developer toolbox.
Separating Servers from Tools using Vagrant
Virtualized developer environments aren’t a new idea. Vagrant, however, has gotten a lot of attention from the Rails community in the past few years for its extremely easy setup and promise of “virtualization for the masses.”
After installing vagrant and VirtualBox, here’s all I did in order to login into a new Ubuntu server running on my machine:
1 2 3 4
A few dozen
sudo apt-get install commands later, and I had an Ubuntu server running Tomcat, memcached, Node.js, Redis, and MySQL.
The final step was setting up some folders to share between my host machine (Mac OS X Lion) and my new vagrant box so I could deploy code. Vagrant automatically created NFS shares on my host machine after some small changes to my vagrant configuration file:
1 2 3 4 5 6 7 8
Vagrant also allows you to provision and share boxes among teams, not to mention built-in Chef and Puppet support.
With vagrant configured, I started working on some dotfiles to make all of my Mac OS X and application settings portable across all the machines I use.
dotfiles, or everything that makes a computer yours
Dotfiles are all of the hidden files starting with a
. in a user’s home directory. There’s been a popular movement (see @octodots and dotfiles.github.com)
to share, fork, and contribute developer dotfiles on github in the past few months. The large number and variety of dotfiles on github benefits everyone.
It’s possible (and encouraged) to pick and choose dotfiles that suit your own taste and developer workflow. In my case, I just forked Zach Holman’s dotfiles and blended in Mathias Bynens “legendary” configuration for OS X.
There’s some great stuff in the dotfiles that automate almost all of the mundane configuration tasks you go through when you switch computers. For instance, if you’ve ever wanted to automatically enable the Safari developer toolbar:
Or, how about prompt that gives you a color-coded status of the git repository you’re currently in?
Dotfiles provide consistency, and once I was happy with mine I installed them on every computer (and virtual machine) that I use regularly. My work and home laptops now behave the same way, making context switching much easier.
Getting to Iterative Development Environments
Vagrant and dotfiles allow software engineers to continually iterate and optimize their workspaces. Vagrant, particularly in conjunction with Chef cookbooks, provides teams and individuals a sandbox that encourages trying new tools. If you break your personal development server, it’s two commands to roll things back to normal (
vagrant destroy; vagrant up).
Dotfiles spur developers to find the configuration, shell aliases, and tricked out command prompt that makes them the most productive. Dotfiles shared on github are inherently collaborative, and it’s fascinating to look at the network graph and observe the evolution of one person’s configuration into 300+ forked repositories.
Vagrant and dotfiles help software engineers make resilient developer environments that are easy to change and share with others. In other words, it brings agile to developer system configuration.