As a continuation of my blog posts regarding continuous delivery, I shall explore the continuous delivery options for WordPress websites since I was recently been involved in such a project.

One changing component of a WordPress website is its templates, which are written in PHP. This PHP source can be version controlled quite easily and integrated with a continuous delivery system.

However, another changing component of a WordPress website is its plugins and their configurations, which are stored in the database. Version control of these configurations will require managing the data.

WordPress Hurdles

Continuous delivery with WordPress is made difficult with the fact that its configuration is done through the database exclusively with the exception of the configuration of connecting to the database itself.

Another hurdle is that the content is not easily manageable.

For continuous delivery, you will rebuild the WordPress website using a specified core version, a specified list of plugins to install, a version-controlled database, and a maintained uploaded content directory.

Version Control

The branching strategy here would be similar to that mentioned in my continuous delivery post with Ruby on Rails and Heroku.

Since the WordPress website is being built from scratch and WordPress is unfortunately configured via database entries, the following should be in version control:

• the MySQL database dump
• list of plugins need
• URL to desired WordPress core to install

The MySQL database dump should also include DROP TABLE statements. Simply run mysqldump with default settings to generate such a dump.

The plugins list is simply a text file containing the URLs to the plugin zip file separated by newlines. Unless a specific version is needed, the plugins need to point to the URL that contains the latest plugin zip file. For example, use “https://downloads.wordpress.org/plugin/some-plugin.zip” instead of “https://downloads.wordpress.org/plugin/some-plugin-1.0.0.zip.”

Continuous Integration

The build server needs the following, which doesn’t necessarily need to be in version control:

• Apache server with mod_rewrite
• MySQL with a database for the project
• PHP with the appropriate Apache modules
• .htaccess file for the web root directory containing:
  • RewriteEngine On
  • RewriteBase /{root}
  • RewriteRule ^index\.php$ - [L]
  • RewriteCond %{REQUEST_FILENAME} !-f
  • RewriteCond %{REQUEST_FILENAME} !-d
  • RewriteRule . /{root}/index.php [L]
• A zip file containing the uploaded content
• wp-config.php containing the necessary database credentials

However, we maintain the following in version control:

• data.sql (the MySQL database dump from above)
• wordpress (single line of WP URL to download and install)
• plugins (multiple lines of plugin URLs to download and install)
• wp-content/ (your work)

And so, the following is a suggested build configuration:

1. Clear out the target test web directory (for websites with large content, you may want to move the contents directory: wp-content/uploads to restore later to speed up the process)
2. Download the latest WordPress core at: https://wordpress.org/latest.tar.gz
3. If the project requires a specific WordPress core version, find what you need here: https://wordpress.org/download/release-archive/
4. Extract the WordPress core to the target test web directory
5. Copy the held wp-config.php to the root of the target test web directory
6. Copy the work to the target test web directory
7. For each entry in the plugins list, download and extract the plugin to the wp-contents/plugins directory
8. Extract the uploaded content and copy it to the wp-content/uploads directory
9. Populate the test database with the database dump in version control
10. Output the URL to access the test WordPress website.

After a successful build, the build server should have a working WordPress website in some web directory. The build configuration should provide the URL for a user to access for testing.

To ease the development and deployment process, consider making use of development and release branches.

Development Branch

The development branch shall attempt to provide the opportunity for developers to sync with production content.

The build configuration is modified to also include the step of downloading the uploads directory and obtain a database dump from the production site. These artifacts are then stored on the build server for retrieval and possible integration with the codebase.

Specifically, regarding the database:

1. The build configuration uses the data dump in version control first to apply any non-WordPress data.
2. Then the build configuration will use the data dump from production to populate the WordPress data.
3. Finally, the build configuration dumps the resulting database from the above and stores it as a build artifact.
4. Developers then use this artifact to synchronize the data dump in version control so that developers working off from the development branch can have access to the latest production data (note that this data does not necessarily include content)

Staging Branch

The staging branch shall include database configuration changes to be deployed to production.

The build configuration is similar to the development branch’s build configuration except that it doesn’t sync with the production database since the staging environment is intended to replace what’s currently in production. Thus, the staging environment is meant to stage the next production iteration.

In lieu of an explicit staging branch, the development branch can be used. In this case, there would be two build configurations: one for development that syncs its database with what’s in production and the other for staging that does not sync with the production database.

Master Branch

Note that the build configuration in the development branch does not affect the volatile data in production. That is, the uploads directory or the database.

However, the release branch is an opportunity for developers to push their changes to production as a deployment even in the database!

The build configuration for the release branch blows away the current instance and builds the site from scratch.

Thus, the flow for a deployment is to synchronize the development branch with production and then trigger the release.

The build configuration shall keep a running backup of current data dumps before running the deployment so that the instance can be rolled back as needed.