Many people overlook Vagrant as a useful foundation for their projects, perhaps because it was previously a Ruby Gem. But from version 1.1 and beyond, it’s opened up for devs of all disciplines, so we recently implemented a unique setup to make it work for our team.

Let’s face it. Every company has a different set of rules, policies, and standards to approach project development. At PRPL, we have the luxury of housing a robust range of skillsets: everything from Zend Framework to Ruby on Rails. This allows us to get very creative with our technology stack. And precisely why I use Vagrant to my advantage.

But wait, what is it?

Vagrant is a virtual machine utility that allows you to quickly set up and configure virtual environments for your project. Formerly packaged as a Ruby Gem, it now offers a fancy graphical package installer for your particular operating system. By placing the “Vagrantfile” configuration file in any directory, you can boot up a pre-constructed virtual environment. Most developers simply place it in their project folders so other developers working on the same project can have the same exact environment running.

How we made it flavorful

Consider typical setup time for a new project using, say, HHVM, Nginx, and Laravel. How long would that take you? It’s a tedious task, especially when you consider having to repeat that same process for each new developer that jumps on the same project.

At PRPL, I started off with a prototype by creating a few foundational boxes that already came setup with HHVM, Nginx, WordPress, Laravel, Symfony, Drupal, and so on—what I refer to as making our own “flavors.” This way, any developer can just grab the flavor and spin it up in VirtualBox, saving the company a lot of configuration time. But I took it a step further by integrating the same idea with Vagrant. Since it already uses VirtualBox as a provider, we can just tell it to package up a virtual machine straight out of VirtualBox. I personally love William Walker’s simple article on how to create your own custom Vagrant box.

After the prototype and idea caught on with the team, I spoke with an array of developers in the company and asked them what common technologies they use (e.g. Fabric, Node.JS, etc.). I compiled a list of all the “need to haves,” and installed them into a base Vagrant box. I can then use the packaging tool to customize more specific flavors, such as HHVM or PHP-FPM. Each time I created a new flavor based off of the base box, I just used the package feature again.

After I had all my Vagrant flavors, I uploaded them to the company’s internal server. From there, all a developer has to do is copy a “Vagrantfile.flavor” file from the internal server into their project, download it, and type the “vagrant up” command to activate their working environment. The Vagrant configuration flavor files are just a file type that I created myself, preconfigured files for my team to drop in any project at anytime.

To the haters…

I know what you’re probably thinking: “But I like to use my own text editor!” Well, that’s not an issue here. In all my Vagrantfile.flavor configuration files, I’m telling Vagrant to share the current folder it’s located in with the virtual environment. Therefore front-end developers don’t get their trousers in a bundle (that’s how the saying goes, right?).

This type of setup will not only require less time up front, but also helps keep developers’ environments identical. If we are using Ubuntu 14.04 on production, then it should be the same exact when developing locally. Making sure development environments are identical can actually save you more time and money than you might think.

Additionally, working locally from your computer can’t offer flexibility of technology. Say your Mac was running Apache2, but your new project needs to run Nginx. It looks like you will need to go through a lot of unneeded hassle to get Nginx set up on your system without messing up your local environment.

Most hardcore developers out there will have their opinions about the rights and wrongs of using this tool, but to me, it’s a fun, unique solution to our projects. Vagrant is often run with provisioning software, like Chef or Puppet, but I’m not a big fan of doing so, seeing that it requires just as much effort to configure than just building the dang environment yourself. But hey, more power to ya!

Getting started

I’m all about saving time and energy, and this unique system has helped us do so. If you’d like to give the Vagrant “flavors” method a try, I’m at your disposal for any questions that arise! Just comment below and I’ll do my best to get you squared away.

Developing With Vagrant Flavors

Need Some Space? Book Ours.