Previously I did a post regarding what development tools we used in-house for our development work. Well this post continues on somewhat from that and more specifically focuses on one issue in particular, the build up/tear down process of a web project.

Vagrant WordPress Web Development

To begin with I must say we have made the switch to using JetBrains PHPStorm internally and I can’t say enough about how happy we are with it. Coming from a mix of NetBeans and Eclipse environments (nothing inherently wrong with either of those choices per se) I personally find the integration of typically used third party tools and services to be second to none in PHPStorm. It’s quick, rock solid, feature complete and just feels smooth and responsive using it.

Which brings me to the subject of this post. Vagrant. By now most people have well and truly heard of Vagrant and probably given it a go themselves. For those that haven’t Vagrant is simply software for setting up and configuring server environments using virtual machines. In our case specifically for setting up and configuring web development environments. Why is this so useful? Well the configuration/setup files that specify how the development environment is configured can reside right along the source code in your source code repository so that any one working on the project can be 100% sure that they are working in exactly the same environment as everyone else. Taking this a step further you can replicate your production environment in your development environment configuration (save for a few extra things you may want to enable in the dev environment) so that you can rest assured, that if it works in your development environment then it will work in production. And if it doesn’t it certainly removes many possibilities from the check list if something does go wrong. I am also a big believer in tearing down a project environment multiple times during production and building it back up again, this can bring issues to the forefront that may go unnoticed otherwise. Installation of other software/modules that isn’t incorporated into the configuration files is a prime example.

Vagrant configuration files set and configure a box (a virtual machine) which can then be used just like an external server to push files to during development. Vagrant makes this easier by directly setting up shared folders, so you can specify a directory to ‘link’ to the web root on the development box for example. Any changes made in the files within that directory will automatically be reflected on the development environment server.

A Vagrant box can be a simple Ubuntu environment for example or you can bake your own box with a number of features cooked in. I prefer to use a basic box and have any software the project will use to be provisioned when the configuration files are run.

And how easy is it to setup the development environment using Vagrant? Let’s say the base project has already been started (so the Vagrant configuration files have already been created) so that you can simply clone the project repo, run vagrant up and Vagrant will provision the box and setup the development environment as specified in the configuration files. That’s it. Done. When you have finished working on that project for the day, or you need to switch to another, commit your work, run vagrant halt and the dev environment will be shutdown, ready to be started again next time you are ready to work on that project by simply running vagrant up again. Once the project has been completed, you can run vagrant destroy and the virtual development environment will be completely removed from your host machine.

Using virtual machines in this manner for development work creates a lot less clutter on your host machine. No need to have multiple versions of software to ensure each project can be worked on when needed.

So now our overall process for each web dev projects runs something a little like this (just the design and development steps, obviously there are a lot of important client/data related steps missing below):

  1. Wire frames and basic style guides created.
  2. Designs created, mobile first of course (usually targeting mobile, tablet and desktop sizes as the main breakpoints)
  3. Setup basic development environment using Vagrant (using one of our standard templates) and replicating the server environment where possible.
  4. Git repository created for project, initial project push.
  5. We create a separate directory for the Vagrant related files and another for the project config files for dev, staging and production.
  6. Development work continues amongst developers working from same repo and hence identical development environments (Mac and PC).
  7. A number of unscheduled tear downs and build ups to ensure environment/project sanity.
  8. At any time during the development we can share the vagrant environment directly with the stakeholders by using Vagrant Share.
  9. At any stage any introduced third party software or OS additions are added to the development environment configuration scripts.
  10. Once development and testing has been completed we can push directly to our production server knowing the environment is identical to our development one. Alternatively we can spin up a cloud based instance.

If you are interested we have placed our Vagrant files for a typical web development project environment we encounter often in our work.

Download the Vagrant Configuration file for a WordPress Apache PHP MySQL setup here Vagrant WordPress Web Development Configuration Files