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.
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.
- Create environment
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!