Vagrant: Create and configure portable development environments

* If your machine is OS/X, but you deploy to Ubuntu then you aren't developing in a realistic environment. Using Vagrant you get to work with OS/X tools, but run your app on an Ubuntu(or whatever) OS. I use NFS file share, edit on the Mac, run in the VM.

* Keeps your machine clean. If you work on multiple projects, perhaps running different versions of Node, Ruby, MySQL, Reis, PostGres, etc, you keep them isolated to their VM.

* You can experiment. Want to try your app out in Arch, a different version of Ubuntu, etc? Spin up a new VM or clone an existing VM.

* Have a new machine? Copy over your VMs and start working right away.

* The environment it setup as a script. Have a new developer for your application? Just send them the scripts to spin up a new VM. I use Bash scripts to configure my VM's, or you can use Chef or Puppet.

Additionally, everyone I've ever worked with at O'Reilly has been very professional, and they've been doing a great job helping push the book forward. They even rushed the production process (editing, indexing, proofreading, printing, etc.) from their typical timelines down to only a couple weeks so the book would be fully ready for VelocityConf in a couple weeks. And they did it! I'll be at VelocityConf signing books.

:)

It's really nice to be able branch, commit, merge, go back, whatever with your installed infrastructure. This gets even better if you use puppet or chef (or even the shell) for provisioning of infrastructure in concert with vagrant.

Doing the same thing with snapshots and VM clones with VirtualBox alone is similar to zipping your project periodically as a backup strategy. Yeah,, it works, but it has no granularity.

Bottom line though, it feels very liberating at any point to be able to flip the fuckit bit, do a vagrant destroy and vagrant up and just start over. It makes for painless experimentation on your VM, among other things. Once you've got what you want, you can formalize it in your Vagrantfile, puppet manifests or other versioned artifacts of development.

Is good.

Though it caused some kicking & screaming on the development team, the end result is that every developer has the same development environment, which pretty much matches our deployment environment (in Rackspace Cloud). I also just kicked off our summer intern class, and the interns were able to get productive with our codebase in 1 day despite not having much experience with modern Python web development, because pretty much every local setup step was automated.

I consider the tool invaluable. I don't even install any databases or tools directly on my laptop any longer. With its handy port forwarding feature, you can put all your DBs on a VM, yet still connect w/ CLI clients via your host machine. Then when you do "vagrant halt", all your DBs shut down at once and you free all those resources / memory / etc.

Also, one suggestion -- look into the debug logging level that you can set with an environmental variable. The only thing I found frustrating about Vagrant were situations where it would hang/fail but it wouldn't be clear why. It turns out their debug logging is quite good.

As a user, looking at those 289 open issues with only one developer, I don't feel at all encouraged to open a new one or send a pull request, because I just see a huge pile of things that the committer will have to wade through before getting to mine.