in which systems are captured



When working on a project, I try to take care that a dev environment can be brought up with as little fuss as possible. This requires some discipline even with simple programs, but once you get into the realm of systems, more up-front effort is required for repeatability.

We've all been in the position of being the new hire on the team. On some teams you're lucky if you can get to actually running code on your machine in your first week. You think to yourself that it could surely be simplified, but once you're all set up there's not a lot of incentive to come back and make it easy for the next time.

It's easy enough to track language-level dependencies using Leiningen, Rubygems, or whatever is standard for your language, but very few large systems end there. You almost always have further external dependencies that are best handled by the system-level package manager, be they databases, message queues, or even your language runtime itself.

discovery park. no reason.

I've found the best way to make sure this stuff is kept up is to make it the status quo. At work nearly everyone develops in a VM, and when a new dependency is needed, instead of everyone having to hunt down and install it, it just gets added to the setup script. This reduces redundancy as well as helping to eliminate Works on My Machine issues.

Recently I've found Vagrant to be a really helpful tool for streamlining this process even further. Before I was using raw VirtualBox, which was all right for launching fresh VMs, though the interface was always a little awkward. Vagrant streamlines this greatly, making it trivial to configure, suspend, and rebuild VMs. It also helps keep the configuration of the VM alongside the project for which it's meant.

Vagrant allows you to provision new VMs with Chef. While this is pretty handy if you've already got recipes written, it's a bit intimidating as the mental model needed to operate Chef is quite baroque. But it's easy enough to bypass Chef and provide an arbitrary shell script as a provisioner. You need to take a bit of care to ensure the script is idempotent as it's much more useful if you can re-run it whenever the dependencies change, but it's a great way to get started.

There are a few gotchas. Vagrant is rather particular about what version of Virtualbox (and the VBox extension pack) you use, and reinstalling Virtualbox only makes it confused. The OSS edition isn't supported, but thankfully an apt repository is available:

$ sudo apt-add-repository "deb $(lsb_release -cs) contrib"
$ wget -q -O - | sudo apt-key add -
$ sudo apt-get update && sudo apt-get install virtualbox-4.0
$ sudo gem install vagrant

On a related note, I've had had a couple people ask what a good project to get started with Clojure web programming would be. The most widely-used Clojure web app that I know of is Clojars, the community repository. But it's been pretty dormant recently; there are plenty of great features just waiting to be implemented, but getting it set up is hard work given all the moving parts.

Vagrant is perfect for smoothing this over. I've got a vagrant branch of clojars that makes it as simple as vagrant up (modulo a small issue with the nailgun scp server I'm still working out). So this should allow folks to contribute to the codebase more easily.

I've also helped out with Justin Lilly's Clojure/Emacs environment which provides a fully-configured Emacs 24 install intended to help facilitate our Seajure hackfests. Give it a try if you've had trouble configuring Emacs for Clojure hacking. And feel free to crib from these setups for automating your own projects.

« older | 2011-06-29T15:42:38Z | newer »