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.
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.
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 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.”
The build server needs the following, which doesn’t necessarily need to be in version control:
However, we maintain the following in version control:
And so, the following is a suggested build configuration:
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.
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 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.
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.