WordPress is legacy software, and is not DevOps friendly by default.
There is a lot of smoke out there about how to handle WordPress in an organization that is embracing DevOps. There are some very dangerous assumptions that pertain to tools geared for DevOps that has C-Level headcount thinking that you can squeeze WordPress into a development pipeline and gain all the benefits from rapid release cycles.
We as an organization embraced DevOps as it was starting to become the hot new thing. In the process, we got absolutely eviscerated, and it is because the expectations of management do not reflect the technical realities on the ground as it pertains to WordPress as a platform.
What does that mean? In modern cloud ready applications, the individual components on both the software level all the way down to the infrastructure layer are treated as cattle, not as pets. The raw data that you store for your application (both object level as well as database level) are parted out in a modularly. Your database layer is a separate entity, as is where you store your files. So, in a perfect world, your application resides on a server or container, your database is in a RDBMS like Amazon’s RDS, and your images and other file based assets are stored in object storage like S3. You can do this with WordPress, but this functionality does not exist out of the box.
By default, when you upload images, they get stored in wordpress’s local filesystem. You need a 3rd party plugin to automate and handle offloading to object storage. Some plugins write to the local filesystem as well. These can be a royal pain to deal with when you are trying to factor out a WordPress install to be resilient and scalable. There is a lot of extra work, and most WordPress developers seem to be lacking in the true understanding of running WP at scale.
One of the things that can’t be factored out easily without making some tradeoff’s is the WordPress filesystem at large. Amazon has a way to handle this – called EFS. It’s basically a global scalable NFS filesystem. You bake your code into some EC2 images, Docker images, however you keep your base running configuration, then the /wp-content/uploads folder (or anything user changeable) is mounted like any other linux filesystem. This can be done easily without having to jerk around with WordPress, but the performance penalty at the individual file level can be steep if your I/O numbers are low. You can pay for more speed, but provisioned throughput on EFS is expensive, and running your own NFS cluster with better performance needs dedicated knowledge to keep things running correctly.
This is why deploying WordPress at the agency level can be extremely frustrating and can lead to downtime and revenue loss…
Plugins, themes and WordPress core all have their own updates that you have to be constantly looking out for. You basically have to spin WordPress up in a dev environment, make the updates, test, ensure that there is no database involvement with the updates, then roll it into production in a way that doesn’t kill a production site.
Have you ever tried telling a customer they cant update a plugin without first consulting with you? While, it might work for some clients, it will not work for others. Some will outright accuse you of money-grabbing, while others will just go and update or add plugins without telling you, then when there is a scaling event to you have to push something into production, they broke the loop, and now you just overwrote some premium plugin they bought, or screwed up their newsletter.
Some plugins and such related things talk to the database, some store configuration in other ways. Since there is no unity, expect having to put in extra work to keep end users from breaking the loop by doing stuff on their own.
Best practices development for WordPress dictate that you ignore the core files and user generated files when storing stuff in source control. The result of this is simple – you have this CI/CD pipeline, with all the overhead in both culture and tooling, just for WordPress themes. Read that as diminishing returns. Executives want DevOps, but have no idea what it actually entails on a platform basis
When you have a hammer, everything is a nail. Some organizations make the move to adopt DevOps, and fail to consider the reality on the ground. Executives and managers are often ignorant to the massive culture shift alone that needs to happen to make sure everyone is on the same bus, let alone the critical technical deficits of platforms that they are trying to ‘DevOps’.
As it stands, there are few actual WordPress focused CI/CD tools, which is a huge piece to DevOps. In wordpress, you have to manage files and database, and database level change management is difficult and expensive. WordPress was not really designed with huge enterprises in mind, and while it runs some of the largest sites on the internet, there are a lot of companies that quickly drift away from WordPress’s core competencies as a platform and need to consider replatforming to something that is easily rapidly iterated.
So, when your boss comes down the hall and asks why your shop is not doing DevOps, send them this article, please.
While you can get WordPress to scale and factor out in large environments, and you can put part of WordPress on a DevOps pipeline, the rest of the platform requires some special handling, and lots of gotchas that are not readily evident until you get into the weeds. Additionally, many WordPress developers are more designers than they are actual developers, and when such people are put into a shop that is going through the DevOps transition process, you can expect the learning curve to be steep for that individual.
DevOps is the siren cry that has wrecked many ships, the vast majority of captains too proud to admit it. Make sure you understand what goes into adopting DevOps with WordPress as your prime technical asset before drinking the DevOps kool-aid.