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:

  1. 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.
  2. 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.

3 thoughts on “Vagrant & PHP: Our Success Story At The Deseret News

  1. These sorts of issues are why I like having developer sandboxes, run by the same systems team that manages production servers. In our case the sandboxes are just Xen VMs, but from a deployment standpoint they are identical to the production servers. Being able to do development work on the exact same setup that runs on production means that the likelihood of running into “works on my machine” is significantly smaller.


  2. We use Vagrant for developer instance for some months now. A big issue is that the VM becomes slower and slower the more files are in the document root. So we moved cache and log files to other folders directly in the VMs file system. But this only softens the problem but does not solve it. Did you experience the same issue? What did you do about it?


  3. We haven’t had those problems yet. One thing I’ve heard is you could have your vagrant configs use NFS to mount the drives instead of the traditional sharing that VirtualBox does. Let me know if that helps.


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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close