If you develop websites using WordPress professionally (basically, if you make a living out of it or a significant part of your income comes from there), and you haven’t implemented yet an automatic deployment system, you should strongly consider doing it. Being sincere, it’s not the easiest thing in the world. In fact, both the process and the learning curve will take a lot of working hours out of you, all spent in fruitless tests and dealing with communication between servers. The good thing is that you can take advantage of a lot of resources based on the work of people who lost some sleep hours in exchange of putting a complete deployment system in practice before you have to create a totally new one. There even exist some tools specially designed for WordPress that can be really useful to you.
Why Do You Need an Automatic Deployment System?
If you use an FTP client to upload your local modifications to your production website, at some point you surely had those typical problems such as incomplete files or network microcuts that force you to upload the site all over again, thus leaving it broken or inaccessible. There’s also that other issue with some servers not allowing to upload more than a limited number of files simultaneously.
If you use some version control system, such as Git or Mercurial, being those tools not exactly aimed for website deployment, you probably grow tired sometimes because of the number of commands you need to run in order to get a deploy done, and the special care you need to have to not confuse versions.
In both situations, the disadvantages are pretty evident.
Now imagine a system that, with just one shell command, lets you put a new version of your website online in a matter of minutes (even seconds!) and in a totally transparent way for your visitors, who can keep browsing and won’t see any change until the process is finished. Also imagine that, with another command, if you spotted something that doesn’t look good after the deploy, you can go back to the very exact and same previous version without having to touch a single file.
There can be commands for managing databases too, such as processing backups, restorations, and downloads and uploads of your data dumpings.
Interesting, right? Basically, this is the kind of processes that an automatic deployment system can provide. Now imagine how much time and work you could save.
Automatic Deployment with Capistrano
Capistrano is a Ruby-based framework that allows to automatically execute processes between multiple servers, with a special emphasis in processes that have to do with deployment. Today is the weapon of choice of a lot of WordPress professional developers who work with automatic deployment systems, including the guy who writes this words 🙂 There are other options, and some of them are great paid solutions, but I’d recommend to give Capistrano a try, because is the most documented one, the most customizable, and the number of great developers using it (not just myself :).
To install Capistrano, you need to have Ruby Gems running on the system where you’re gonna use it. My personal recommendation is to use it only in UNIX systems. It’s not that Windows won’t do the job, but UNIX is kind of like the standard system that most of professional developers work with, and almost all the documentation and discussions on the topic you’ll find around the Internet assume you’re using UNIX. If you’re already on Windows, and switching operating systems could mean a problem, there are some virtualization tools that are really easy to install and to use, and my choice here is Vagrant. It’s also very recommendable to have your version control system of choice (Git, Mercurial, etc.) installed both in your local system and in your remote staging and production servers.
It’s very important to notice the fact that Capistrano is opinionated sotware. Their developers have very clear statements on how some things should be done, and they are not gonna change their minds about it. Capistrano assumes you already have adopted a certain set of good practices by its standards, such as having the possibility to remotely access all the systems involved in the deployment process via SSH public keys.
Capistrano does not exactly work right out of the box to deploy WordPress-based websites, but instead requires that we create and modify a number of files in order to get our sites automatically uploaded to a remote server. It is not strictly needed to know something about programming with Ruby – it certainly helps, but you’ll see you can use some tools without having to code.
In case you want to get familiar with the internal functionality of Capistrano, since this article is just an introduction to deployment practices and I’m still not gonna get into technical details, I recommend the series of tutorials written by Konstantin Kovshenin (see part 1, part 2 and part 3), which are really complete and easy to understand even for those lacking experience with Ruby. In fact, almost all Konstantin’s work around WordPress is really great, so I think you should follow him aside from this.
But if you don’t want to code, you can make use of some pre-built libraries that are, basically, collections of settings meant to deploy websites made with WordPress.
Introducing WP-Stack and Stage WP
One of the most popular deployment libraries built around Capistrano for WordPress websites is WP-Stack, created by Mark Jaquith, lead developer of WordPress core. Mark is one of the most important developers today in the WordPress world, so his work is by itself a guarantee of quality. WP-Stack uses Capistrano to perform deployments to production and staging environments, and works perfectly by doing just a minimal customization of files without requiring any specific knowledge of Ruby. It also provides a nice set of MU plugins that will improve your workflow and site performance significantly.
However, I found three limitations in WP-Stack that you may need to keep in mind.
- It is not meant to deploy locally. You need to install WP-Stack in your production server and trigger your deployments from there. That shouldn’t be a major problem, but I prefer to deploy from the same system I’m working in, and I know some people who are with me in this point.
- It doesn’t provide an easy way to sync databases and static files between different servers. You can pull files and MySQL dumps from production to staging, but not from staging to production.
- It lacks documentation, specially about the setup. But this is not exactly something we should complain about, since Mark developed WP-Stack for his own needs. Some people who forked WP-Stack in Github have made attemps to improve the documentation, so if you feel a little confused by Mark’s, you maybe need to take a look at some forks.
If you have at least a little knowledge about Ruby and need more features, or if you’re ready to dive into a lot a new things, you could start learning about how Capistrano works and coding your own tasks. I did that myself by forking WP-Stack and working in my own system called Stage WP, which I try to mantain often.
Stage WP is meant to be used to deploy from a local system, and you can add any other stages you may need (I don’t know why you’d need more stages than local, staging and production, but that’s your call). I added some tasks to improve management of database and static files, and ease the process of syncing between different servers. I also tried to present a little more comprehensive documentation about how to use this tool.
Both WP-Stack and Stage WP can be used with any kind of WordPress installation, though their workflow improves a lot by using them beside some Git repo-driven WordPress installation, such as WordPress-Skeleton for WP-Stack and WordPress Bareboner for Stage WP. These projects provide an alternative and well organized way to install WordPress that I will talk about later.
Of course, there are a lot of other Capistrano-based libraries to deploy WordPress, such as Bedrock, which seems to be a great solution, but I feel I can only say something about the tools I tested myself.
Some Final Considerations
As I was saying at the beginning, most likely applying a system like Capistrano + WP-Stack / Stage WP won’t be easy if you don’t have experience in UNIX, VCS or Ruby. The different tests to run, settings to configure and tasks to code are going to depend on the different features and needs of your local and remote servers, and there’s even the possibility of different websites needing different configurations.
You probably will need to implement virtual hosts, if you work with Apache, or server blocks, if you work with NGINX, and change the root folder of your website. Just forget to put all your complete site into a default www or public_html directory, as it is traditionally done. Would making these changes be a lot of work for you?
It’s also possible that you need to modify a number of things in your usual and normal workflow, which can require some period of adaptation. At this point you’re gonna need to evaluate if the amount of time and work that you invest in the implementation of this new system justifies the amount of time and work that you’re gonna save in the future, how much you need to work in modifications for the website later, what is the maintenance and update frecuency, and how willing you are to make changes to the way you already work.
If there’s a project that you’re gonna be working on constantly, this change is gonna be, without a doubt, a great advantage. On the other hand, if it’s not going to require further modifications frequently, you may not save a big deal of time, but you’ll sure save in security (with less chances of your site breaking while being updated) and stability (having standardized and automated processes to manage your modifications).
I think sometimes the amount of hours that one can save are a lesser thing compared to the peace of mind and sense of relief brought by something that you can rely on to do a lot of things for you, so I strongly recommend doing this change either way. I believe that it’s not so important to save hours or work quickly, but making your work well organized, comfortable and better.