I had a dream

The first post in a series covering how we currently control our development environments at Code For The People.

Back in 2013 I had a dream. I wanted our team at Code For The People to work within a consistent development environment, which we could jointly outfit with tools and functionality to help us do our job better. I wanted us to be able to assemble resources, plugins and themes and code libraries, as we needed them. I wanted us to be able to easily develop and easily deploy. I wanted something which would allow us to engage freelancers, or even clients, and get them started on development without having to go through complex sysadmin procedures. I wanted us to be able to jump in and help each other at short notice.

I think we’re well on the road to meeting these requirements now, and so I’m due to write up the travails which have got us to this point. The development environment we run is a Vagrant machine, running the Varying Vagrant Vagrants (VVV) project. That gives us a virtual machine, running on our physical “host” machines, which is an Ubuntu GNU Linux server running a commonly recognised web server setup: Nginx for the web server, MySQL for the database, Memcached for object caching, and PHP5-FPM. Within a consistent Linux machine, we are developing Bash scripts to handle our common scenarios like setting up projects or deploying projects to commonly used web hosts for our clients.

When I first came to VVV I was looking for a way to dump my MacPorts based development setup. MacPorts sets the web server, database, etc, etc, up within your actual physical machine, and it’s a pain to maintain. of course there are now easier systems for taking care of things like Nginx, MySQL and PHP on your local machine, like Homebrew, but the appeal of having my development environment sandboxed within a virtual machine was that it couldn’t get out of control and start breaking things on my host machine. If things go wrong, or get tangled, I can just restore the virtual machine back to the initial state.

The Vagrant system allows you to define a virtual machine, or even a cluster of virtual machines, and how they behave and are set up. VVV is a configuration built on Vagrant which is focussed on WordPress development, providing the Nginx, MySQL, etc, that I mentioned above. There’s a directory shared from your host machine into the server, so you can edit your code from your real machine using PHPStorm, or Sublime Text, or whatever you prefer to edit code in.

The first issue we ran up against was that there was no way to automate the setup of a project. As luck would have it, Weston Ruter from our competitors (and community collaborators) X-Team had recently started an initiative to add this into VVV. I got stuck in, and helped develop what is now the VVV auto-site setup functionality. It was fun, we had a Pull Request inception and an animated GIF. What auto-site setup boils down to is a series of optional files you can include with your web project that specify the Nginx configuration file, a script which can do whatever you need (like load databases, check out version controlled code, etc), and a file with the names of the domains to be added to your host machine so you can see the development site(s).

So now we have a way to automatically setup a site in our Vagrant development environment. For many of our sites we’ve been deploying by checking out from either SVN, or now mostly Git, directly onto the server. To deploy code, we simply commit it and update (SVN) or pull (Git) on the server to get the code deployed. We refer to this approach as “monolithic repositories”, all the code for the whole site is included in the one repository. Hosting services like WP Engine have more sophisticated versions of this where you can push Git commits to them, and they handle the deployment of files, run checks for obvious stuff like syntax errors, etc, etc.

Until recently, we’ve been using the same version controlled code that we deploy as our development repo. All we need to do is tell our VVV auto-site setup script to check out the code, and we’re good to go, right? Nearly. It turns out that most of our client projects are in private repositories, and the auto-site setup routine is running without user input… meaning it cannot stop to ask the developer for a username and password, and the developer is probably off making tea anyway.

The next post in this series will cover how our machine user solves the problem of checking out from private repositories on services like GitHub and Bitbucket.

In a subsequent post, I’ll cover using Composer to assemble our project requirements (you can also read my colleague Tom’s post on “Theme Composition vs Frameworks“), and how we “build” a Composer based project to deploy it to services like WPEngine and WordPress.com VIP who utilise monolithic repositories for deployment.

If you like spoilers, and want to see the (always evolving) code we use to start off a new project, visit CFTP’s VVV-Init repository.

Photo by Camdiluv ♥, from Flickr (I’ve cropped it a bit).