I wanted to give a quick overview on how I tend to use Vagrant and a brief explanation of my thought process, how I learned, and what I would do different next time.
######Always Provision with Chef or Similar Tool
When I first started playing around with Vagrant I searched around for solutions for Django specifically and I ran into a few that provisioned the box in various ways. Some solutions used shell scripts and other similar means of provisioning, but this meant I had to figure out how to script every little change into one large file. I eventually found a few different repos that were setup to configure vagrant using Chef and I jumped at the chance to replicate it. What eventually came of it was my Vagrant Django Project.
Edit (Feb 2014) I’ve since stopped using Chef in favor of Salt, and have updated my boilerplate.
######Project Specific Vagrant Packages
I’ve been playing with this idea for a while. The general concept is taking a base project box and then making it incredibly client or project specific. This entails installing all python packages, setting up the DB, etc. The main reason is to make it as easy as possible for new developers and designers to get started on the project. Although this works, the customized box that you are left with is usually somewhat propreitary (DB) which is unfortunate but also extreamly large. This has been successful in circumstances where non-developers are wanting work on the project.
I’ve been developing soley on VMs for the last few weeks and I can’t see myself going back to the old way anytime soon. My main advantages are being able to completely blow away systems and not to cluter up my MBP with homebrew and other OS level packages.
Overall I’m very happy with the progress and plan to continue updating my base vagrant repo as new technologies are added to my typical Django Stack