How to set up WordPress CI/CD pipeline

I am planning to create 3 environments for my website i.e. dev, stage, and production. I am using GitHub to manage the code. So for URLs dev.example.com, stage.example.com, and example.com, the branches are dev, stage, and main. My knowledge says dev is for the developer to play around with new codes, tests, and do whatever he wants, the stage is like production-ready where QA personal can test codes, functions, etc.

I have modified wp-config.php to take environmental variables. For example, I have changed

define( 'DB_PASSWORD', 'password' );

to

define( 'DB_PASSWORD', getenv('DB_PASS') );

Questions
Database

• How should I move a database from one environment to another? Should I let the developer do anything from the dashboard in production and later move the database from production to dev/stage if require?

Plugins

• I know I can avoid including plugins inside the wp-content/plugins folder and use wpcli to install the plugins which are free but what about premium plugins? How can I integrate them?

Update

• What should be the update strategies? Should I let the developer update from the dashboard? I think it will make changes in the codes and later will conflict with git merge. what is your thought on this? Also, do you take a backup of all environments or just production?

Tags

• How should we configure the pipeline for new releases in GitHub? Should I manually configure the pipeline to deploy on each release?

For now, I only have these challenges. If I will have more questions then I will add.

• I am planning to run WordPress in the docker container, alpine as a base image. I am thinking of separating Nginx and php-fpm container. Doing so, we need to copy WordPress files in both containers, how can I overcome this? or should I use php-fpm and Nginx in the same container? is it a good idea?

• what about the cronjobs?

It has been a while since I have run a few Wordpress based sites. The database stores some of the content of the site. The file system stores media that is uploaded into the site. More significantly Wordpress is a Content Management System. The intention is that your site users can add content and media to the live site. When someone uses the WYSIWYG editor to add or edit the content you will find that the sites domain name leaks into the database. So if you move the Staging database into Live you would get links appearing on the Live that that point back to the Staging site.

I quick bit of research to see if things have improved since I last used it leads to this article on putting Wordpress into git. Please read the first article in that series that explains the challenges. You will need to understand a little of how Wordpress works to understand the recommendations I make below.

That article talks about turning off automatic updates so that you have to manually security path. I am pretty sure that I remember that updates can write things into the database. I would be very worried about turning off updates as there are a huge amount of attacks against Wordpress as it is so widely deployed. You really should avoid deploying many third party plugins as they might not get security patches in time. This isn't a theoretical problem I had quite a time dealing with Wordpress being used as a spam relay. Yet even if you follow that article you won't have solved the database migrations issue.

My recommendation is that you take a step back and try to figure out what problems you are trying to solve and how to adapt the tools and process:

• What is the developer developing? A custom Theme and/or Plugin? If so then this article covers that. Put the Theme/Plugin into its own repo.

• Who actually writes the site content or uploads media? The general public or members of staff? If it is staff then maybe they need minimal training in a Test environment and can happily edit Live after that.

Given that Wordpress does not let you aim for perfection due to the way that it is built, yet it is hugely successful, carefully pick which of the following you are aiming to optimise:

• A Specific Service Level Agreement

• Meantime to recovery

• Mean time between failures

• Reducing the commercial impact of errors

• Something else?

There are quite a few other specifics that may affect what set of compromises might work best for your situation.

Based on my experiences without actual knowledge of your specifics:

• Give up the idea of promoting changes through Dev, Staging and Live. I would simply have a Test site and a Live site. I would periodically refresh the Test site from the Live site. To do this I would dump out the entire Live database a run a sed -i over it to replace every instance of "www.mysite.com" with "test.mysite.com".

• Give up on using Docker as the software distribution mechanism for the actual site. I would use Docker to supply the PHP+Apache runtime and mount a volume that contained the actual site php+content. This because the disk is a combination of the code and the content of the site so you need to be able to backup and restore it independently of changing the Docker image.

• Try "git checkout vX.Y" to update the live site in a persistent volume mounted into your generic PHP+Apache docker image. I would investigate the ideas in this series of articles.

• Automate the backup of the media content volume every night and keep as many backups as you can. This is why it needs to be a volume mounted into Docker.

• Automate the backup of the database every night and keep as many as you can.

• Automate the restore of the site as a script that restores the database to the last midnight backup then restores the last nightly snapshot of the media content folder.

• Avoid any party plugins that are not commercially supported. They likely won't work at the next major upgrade of Wordpress and will pin you onto a version that will become obsolete.

Then they workflow that I would go for would be the to add "experimental features" into the Test site before applying them to the Live site. This would be based on git checkouts in the best case. Yet I would also consider doing Wordpress security updates via the CLI. Those can update the database and the state on disk underneith Docker hence I do not recommend you try to mange the state of your site as a Docker image.

You then have to worry about the Test site drifting away form the Live site. So I would on a periodic base (at least monthly) overwrite the Test site with the Live site. This would involve:

• Backing up the Lite sites media content on the persistent volume and restoring it over the Test sites media content on its persistent volume.

• Backing up the Lite sites database, doing a sed -i to rewrite any content links pointing at the Live to point at the Test site. Then restoring it over the Test database.

A key part of this approach is that you wou

StackExchange DevOps Q#13062, answer score: 2