Vagrant & PHP: Our Success Story At The Deseret News

The simple world of LAMP is fading fast into the distance. When I first started developing websites, you’d just drop your PHP code in a document root, configure it to connect to a mysql database, and that was it.

Now-a-days, you have frameworks that need to be setup, include paths that need to be changed, modules that need to be installed, web servers that need to be configured for your routing, etc. Then you might not just have MySQL, but Redis, Mongo, Couch, Memcached, Postgres, or any other dozen other servers. Then in Production you might have load balancers, multiple web servers, clusters of databases, and the list goes on.

Simply put: web development environments are complex.

So two problems arise for our development teams:

Setting Up Your Development Environment – This task to me three days at my new job. Then, after a few days and I managed to screw something up, I had go re-set everything up again. Then, a few weeks later, I had an odd bug that I couldn’t reproduce in production, but it was happening on my local machine. Oh, looks like I still hadn’t everything set right. Oh, we want to use some new php module? Or change PHP versions? Time to get everyone in the organization to try and update all their environments.
Mismatches Between Development and Production – This can be summarized with the phrase “well it works on my machine.” You might run a simple version of your environment locally, but your production environment might have many more moving pieces. So a new feature might work when stored locally on one machine, but when spread across three servers it might break.

A few months ago I heard about a tool called Vagrant. From their website:

Vagrant lowers development environment setup time, maximizes dev/prod parity, and makes the “works on my machine” excuse a relic of the past.

Developers no longer need to worry about setting up complicated infrastructure components. Projects with conflicting dependencies can each get their own sandbox — keeping a developer’s workstation free of the hacks needed for multiple versions of software to coexist.

Operations engineers can no longer need to worry about developers having a different local setup from production. They can experiment and test their configuration management changes before going live.

So when I had moved to Deseret News, I decided to give Vagrant a shot after hosing my own development environment. It took an extra day or two to get all setup, but now it works great. I changed laptops, and I had my new environment setup in minutes. One of our developers switched from Windows to Mac, and he had was up and running in minutes.

Then, a few weeks ago, we brought on two great new developers. There was one complication though: they were working remote from Ukraine. We hadn’t used remote workers before, and our environment was pretty complex. We also only had about an hour or two of time online at the same time. The beginning of our day was the end of theirs. Aside from one of them having some VirtualBox problems, they both got their environments up and running within a day. It was awesome. If we had to try and explain over email or skype how to setup everything would have been a giant pain and likely would have taken the entire week, if no longer.

If you want to get started with Vagrant, check out their website, as well as this post from Jeff Loiselle, and an example on GitHub.

If you have any questions, don’t hesitate to ask.