WordPress Deployment Part 1: Preparing WordPress

Welcome to the first post in a workflow series on deploying WordPress. In this series, we’re going to look at how you can set up automated deployments for your WordPress site in a range of different ways.

But before we get into the “how”, first we’re going to look at why you should consider setting up automated deployments for WordPress and how you can prepare your site for automated deployments.

Why Automated Deployments?

Deploying WordPress, like any CMS or web app, can be a messy affair. Missing files during an upload can cause errors, migrating the database can cause data loss and moving a large library of media files can take a long time. In each of these cases your site may be become unusable for your visitors, potentially for some time, which isn’t ideal in this day and age of “always available” expectations. Anyone who has been around long enough will remember deploying sites manually using an FTP client and phpMyAdmin (nostalgia moment).

Each of these processes normally contain a number of steps and, if you were to do them manually on a regular basis, inevitably you would make a mistake at some point during the deployment. Some mistakes might even mean starting the deployment from scratch which only extends the time that your site is down. So what to do to improve this deployment process?

Enter automated deployments. In its simplest form, creating automated deployments is the process of scripting all of the steps you would normally do manually during a deployment so that they can be run automatically by a computer in sequence. There are several advantages to automating your deployment process:

• Remove the potential for human error during the deployment process
• Make deployments consistent across environments
• Increase the reliability of deployments
• Reduce (or remove) the downtime of your site during a deployment
• Add the potential for catching errors and easily rolling back a deployment
• Allow deployments to be run by anyone, at any time, without any training
• Deploying to a different location (or multiple locations) is simple
• You can deploy more frequently

In short, automated deployments should be consistent, reliable and repeatable.

If you’re interested learning more about how to build and run modern web apps you should check out The Twelve-Factor App, and in particular step V. Build, release, run.

Preparing your WordPress Site

Before we can get into the process of actually deploying your WordPress site there are several important steps we need to take to get your site prepared for automated deployments. To make deployments consistent, reliable and repeatable there a few things we need to take into consideration.

Use Git & Composer

First of all, your site’s codebase needs to be hosted somewhere a deployment script can access. In most modern development workflows teams collaborate on their code using a Version Control System (VCS) such as Git and host their repositories using services such as GitHub or Bitbucket.

I’ve previously written at length about managing your WordPress site with Git and Composer so I’m not going to go over it again here. Suffice to say that your site should be stored in an accessible Git repository, your plugins and themes should be managed using Composer and WordPress should be installed as a dependency (also using Composer).

Deploying Config Files

Normally config files are different for each environment. Also, for security purposes it’s best practice not to store config files in your Git repository. This means that config files can’t be part of your automated deployment process. However, config files generally don’t change very often and so it’s not the end of the world to deploy and maintain them manually.

For deliciousbrains.com we use the following code in our wp-config.php to load the correct config file for the correct environment:

if ( file_exists( dirname( __FILE__ ) . '/live-config.php' ) ) {
    define( 'WP_LOCAL_DEV', false );
    define( 'DBI_STAGING_SITE', false );
    include dirname( __FILE__ ) . '/live-config.php';
}
elseif ( file_exists( dirname( __FILE__ ) . '/staging-config.php' ) ) {
    define( 'WP_LOCAL_DEV', false );
    define( 'DBI_STAGING_SITE', true );
    include dirname( __FILE__ ) . '/staging-config.php';
}
else {
    define( 'WP_LOCAL_DEV', true );
    define( 'DBI_STAGING_SITE', false );
    include dirname( __FILE__ ) . '/local-config.php';
}

You then manually deploy the correct config file (e.g. live-config.php for the production environment) the first time you deploy your site. WordPress only has a single config file so it’s not too much of a maintenance burden to deploy this file manually.

Disable FTP Access & File Editing

As your site is going to be deployed automatically (i.e. files being overwritten on a regular basis) the one thing you can’t do when using automated deployments is edit files in the production environment (as any changes you make will be lost during the next deployment). Any changes you make to any files should be committed to your Git repository and it should act as a “source of truth”. Editing files on production is a terrible idea anyway, so this just helps enforce that rule. Also, an added benefit of this is that it forces you to test your plugins/themes in development first.

You should disable any FTP access for your clients to prevent them from being tempted to log in and edit any files. If you don’t need FTP access to deploy your site (if you’re transferring files using SSH or SFTP for example) you could even disable FTP access entirely. That way no changes can get lost during a deployment.

You should also disable file editing in the WordPress dashboard. This is as simple as adding the following line to your wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

Disable Auto Updates

It’s also worth noting here that as part of using Composer to manage your WordPress site you should disable any auto updates that WordPress does in the background and handle these updates manually. You can disable all auto updates by adding the following line to your wp-config.php:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Deploying the Database & Media Library

Your site should now be in a good condition for deploying any code changes, but what about deploying files that aren’t stored in your Git repository? You’re going to need to have a strategy in place for deploying your database and media files. These are big topics in themselves but thankfully I know of a few products that might be able to help you out 😉

If your site has a strict editing policy or you don’t have to worry about merging database changes then you could include database deployments in your automated deployment script by using mysqldump or a brilliant plugin called WP Migrate DB Pro (probably using the CLI addon).

Using WP Migrate DB Pro also has the added benefit of being able to migrate your media library using the Media Files Addon which makes things really simple and allows you to include this part in your automated deployment script. Another option for the media library is to offload it to an external service so you don’t have to worry about deploying it to your production server at all, and we have a plugin for that too.

Regardless of how you choose to deploy your database and media library, you will need to have a deployment strategy in place before beginning to set up the “automated” part of your deployment. So it’s good to get these things in place now.

Ready Player One

Now that we know your WordPress site is ready for automated deployments, and why those automated deployments are important, we can move on to the exciting part of actually deploying your site. In the next couple of articles in this workflow series, we’re going to be looking at a range of ways to deploy your WordPress site including using the CLI, using Git and using third-party services.

Do you use automated deployments for your WordPress sites? Do you have any WordPress deployment tips or questions you’d like us to cover? Let us know in the comments.