Twelve-Factor WordPress App #10: Dev/Prod Parity

Factor #10: Dev/prod parity

Keep development, staging, and production as similar as possible

Historically, there have been substantial gaps between development (a developer making live edits to a local deploy of the app) and production (a running deploy of the app accessed by end users). These gaps manifest in three areas:

• The time gap: A developer may work on code that takes days, weeks, or even months to go into production.
• The personnel gap: Developers write code, ops engineers deploy it.
• The tools gap: Developers may be using a stack like Nginx, SQLite, and OS X, while the production deploy uses Apache, MySQL, and Linux.

This should be really familiar to a lot of WordPress devs. Either what they did in the past (and have learned from it), or what they’re still currently doing (and hopefully feeling guilty about it).

The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small.

This means that your dev/prod environments should be as similar as possible even down the versions of things like MySQL and Nginx.

Backing services, such as the app’s database, queueing system, or cache, is one area where dev/prod parity is important.

Developers sometimes find great appeal in using a lightweight backing service in their local environments, while a more serious and robust backing service will be used in production. For example, using SQLite locally and PostgreSQL in production; or local process memory for caching in development and Memcached in production.

Memcached and Redis are the most applicable to WordPress these days. Most people prefer not to run them in development but this goes against parity and will lead to problems.

In Practice

Dev/prod parity can be accomplished by simply manually installing software with the correct versions, but this doesn’t scale to other team members and you’ll quickly run into problems using your own local OS for development.

Put simply: you don’t want to be developing locally on OS X or Windows and then deploying to a Linux OS like Ubuntu or Debian.

The trick to easier dev/prod parity is to implement proper configuration management and virtual machines.

Virtualbox is free open-source virtualization software. If your production server is Ubuntu 12.04 x64, for example, you can just create a virtual machine with the same OS and run it locally.

Vagrant is a front-end for Virtualbox (or VMWare) that’s specifically made for creating and configuring lightweight, reproducible, and portable development environments. To create a Ubuntu 12.04 x64 VM for example:

$ vagrant box add base http://files.vagrantup.com/precise64.box
$ vagrant init
$ vagrant up

Now that you have a virtual machine with your production OS, you need to automate configuration management so that the software setup is identical. The most popular configuration management systems are:

• Chef
• Puppet
• Ansible

Vagrant offers integration with all the above, and there are tools that exist to make it even easier.

Trellis is a Roots project which uses Ansible to automatically configure servers and deploy WordPress sites.

Another option is PuPHPet which is a website where you select what software you want and it will generate all the config files for you using Puppet.

Setting up configuration management is an investment that pays off whenever you need to add more web servers, move hosts, upgrade to a beefier server, hire another developer etc. It’s all about automating your setup.