Continuous Delivery with WordPress

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.

Copy the held wp-config.php to the root of the target test web directory

Copy the work to the target test web directory

For each entry in the plugins list, download and extract the plugin to the wp-contents/plugins directory

Extract the uploaded content and copy it to the wp-content/uploads directory

Populate the test database with the database dump in version control

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:

The build configuration uses the data dump in version control first to apply any non-WordPress data.

Then the build configuration will use the data dump from production to populate the WordPress data.

Finally, the build configuration dumps the resulting database from the above and stores it as a build artifact.

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.