In this blog series, we’re going to talk about how to efficiently bring modern DevOps practices to WordPress.
WordPress is a fantastic ecosystem but it has been around forever and the technology stack is getting pretty old. This makes it rather incompatible with modern DevOps deployment practices and we need to find ways to circumvent its natural limitations in order to apply modern, efficient and fast methods for deployment. The development of plugins has seen some modernization in the past years with the adoption of React for constructing admin and user-facing interfaces. This is a big step forward, but we’re still uploading a new version of that plugin by clicking on “Add New Plugin”.
There are a number of existing ways to deploy WordPress automatically, or within CI/CD pipelines, but those methods are all more or less limited to the initial deployment. You can use Bedrock and setup a deployment pipeline that will use Composer to manage the versioning of WordPress’ core, themes and plugins. But after that initial deployment, there comes a phase when WordPress is installed and it is to be considered a “pet”. A pet is an instance of something that has a name and is being taken care of and nurtured from its creation until its death (think of a server that has a name and receives regular patching). “Cattle”, on the other hand, are cows that have little plastic tags in their ears with numbers on them and when one gets sick, it is simply shot and replaced (yes, it’s not a nice analogy, but hey, that’s life on the dairy farm).
So in this series we want to look at turning WordPress into cattle. The idea is to automatically deploy it, and then never again log into it:
- No backups, because the contents are actually stored in Git.
- No upgrades because these are done upstream and tested in staging environments before being applied to production.
- No fine-tuning, because any change in configuration is also first tested in another environment, then committed upstream and then deployed automatically because someone committed it.
- No changes in page or post contents because these are done in a development environment and then committed and then pulled into production.
- Your WordPress has been defaced or hacked into and turned into a video sharing server ? No worries, just redeploy. Problem solved.
- Huge crash when deploying an upgrade ? No problem, just redeploy the previous commit.
- And these are only some of the advantages of DevOps that we want to bring to WordPress. Others include: multiple releases per day, no more waiting for infrastructure to deploy your change request, etc.
In this first chapter we’re going to see how we can use Bedrock to create a WordPress container that uses Composer to manage versioning of WordPress core, our themes and our plugins.
