A classic problem

In my latest job I’ve been tasked with developing processes and tools for a large-ish development team (30+). I knew within a week of starting that there was one major problem we had to solve quickly, and that was the ‘production mis-match’ issue.

Local development environments were in almost all cases different not only to test and production environments, but also different to each other. It wasn’t very pretty, but eminently solvable.

One to rule them all

We needed to ensure that all developers ran environments that were the same in all practicable ways to production. This meant:

  • The same version of CentOS
  • The same version of PHP
  • The same version of Apache
  • The same version of Memcached
  • The same version of MySQL
  • The same Apache modules
  • The same webroot
  • The same folder permissions
  • The same log directories
  • The same. The same. The same.

One issue we found with matching production was that often in production different functions reside on different machines, e.g. Memcached and MySQL were shared instances on different VMs from the Apache app servers. We accepted that and moved on; we couldn’t split those out for each developer.

Lets take some notes

First we had to audit the live servers, and even that exercise threw up some surprises. When you start asking around you realise that sometimes some VMs are different for all sorts of reasons. We took the software versions to be installed locally after agreeing with Ops how things should look on production.

Next we had to make some decisions on whether we should install mod_ssl on localhost etc. and go to the bother of organising certs. For our first iteration we decided against that.

Using Vagrant

So how do we ensure that every developer (often working on a Windows, Ubuntu or Mac machine) were able to have the same operating system? Step in Vagrant.

Vagrant – a VM configuration and managment system based on VirtualBox – is a way to encapsulate an environment, provision it with the correct versions of all the required software, and then distribute it.

  1. Create environment
  2. Provision
  3. Distribute
  4. Provision
  5. Distribute


Provisioning can be done using Puppet or Chef; both are tools to manage what software and versions should be installed on a particular environment, based on a manifest or recipe.

Or if you prefer you can provision manually. This was actually something we had to deal with as there were custom builds for certain packages from a private repository. It also allowed us to avoid learning Puppet or Chef to begin with, at the obvious cost of having to manually tweak and redistribute builds manually. We are aware of the trade-off and we hope to bring in Puppet in phase two.

It’s important that you have someone from Ops/or a DevOps-type person to help provison the box. It can get tricky, and you need to get your hands dirty at times. Luckly we had Rafał.


We had new machines arriving for a good chunk of the developers, so we targeted that as the optimum time to roll out Vagrant.

It was a success – setup was reduced from days (literally!) to an hour or two. We hope to reduce that further by incorporatng feedback from the first rollout. We now have parity with production and we can scale this as the team grows.

Vagrant is a great project – and I think is a real ambassator for open source and how it can really help a business in a very practical way. It’s also worth nothing that Vagrant is worthwhile for any team size, or indeed a single developer working on many projects.

Next step: let’s get that Puppet server setup!


This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

2 Responses to Vagrant

  1. Pingback: Vagrant – simply great. | My Daily Feeds

  2. Not sure I’d want to develop against a VM due to performance reasons personally. I guess it varies based on the hardware available to each developer, what software is needed, and if you actually need all the DBMS/caching servers local too. I’d be more OK with a little difference in my dev setup, but then having more production like places to test later. For example, one place I worked at had local dev, integrated dev, test, training, and production environments. Each environment was more and more like production.

    This was needed to some degree anyway because local dev had any other changes in that source control branch, integrated dev had any other changes moving toward prod that had graduated from anyone else’s local dev, etc.. So it was needed to a degree to weed out the versions of other modules you were running against.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s