For the longest time, I was a Vagrant holdout at work. All projects we worked on would have getting a Vagrantfile and Chef cookbook set up as a first step, but I avoided using them. It seemed like something was always broken with any given app’s Vagrant setup. vagrant up rarely just worked for me, which was supposedly the promise of using Vagrant + Chef: a consistent development environment that put all developers on a level playing field with each other as well as with the production server environment.

Instead, I’d get errors along the way at any given step of the process: vagrant up, vagrant provision, or some plugin couldn’t be installed. When Vagrant did work for me, it was slower to develop in a VM than directly on my MacBook. Running RSpec would take seconds longer to start and to run. It was faster just to have PostgreSQL, ImageMagick, and other dependencies installed and set up on my host machine than to depend on Vagrant to get it right.

Recently, however, for a Rails project with a lot of dependencies, including other Rails apps, Node.js apps, and Sidekiq workers, I got tired of having multiple terminals open to run each different dependent service. The promise of running vagrant up, vagrant ssh, and foreman start to get everything configured and running at once was too much of a draw. While I’d been avoiding Vagrant in my day-to-day development, the rest of the team was using it, fixing whatever individual issues came up on their own machines as they hit them. I decided to join the crowd since ChefDK was the new hotness and it was supposed to make working with Vagrant and Berkshelf easier.

The combination of ChefDK and replacing my old spinny-disk hard drive with a new SSD seems to have fixed my Vagrant experience. I feel like we’ve also gotten better as a company at setting up our development environment with the tools we’ve chosen, and ChefDK seems to make using those tools in tandem easier.

That’s not to say using Vagrant is completely painless. I hit a weird problem recently where running bundle was failing in my Rails app, and I could only solve it by reprovisioning the VM. A coworker was getting segmentation faults running vagrant up; turns out he had to run chef exec vagrant up and things were fine. I get errors about Rails failing to write the log file if I vagrant suspend my box and later resume it, so I only use vagrant halt now. Another coworker couldn’t get any of his changed files in a synced folder between his host machine and VM to actually update his Rails app when running in development; turns out his VM was some number of minutes off from his host machine’s time. He set the VM time and the same problem came up the next day, only with a different time offset; he now is resigned to setting the VM’s time manually daily so that he doesn’t have to keep restarting his Rails app while developing it.

When Vagrant+Chef+Berkshelf work, they work really well. But when they don’t… Well, they can be a real pain to debug. At least for now, the occasional hiccoughs are worth it to get more complicated projects up and running.