How can I perform high-level database merging for WordPress within continues delivery?

Question

I've a bit of a problem. I'm currently trying to realize a WordPress development process regarding to one of my old question / topic:

https://stackoverflow.com/questions/48890019/wordpress-development-process

So currently I've GitLab installed (which is a free and good solution for small projects). On GitLab I've 3 branches: prod, staging, develop.

Regarding to these 3 branches, I've 3 instances of WordPress running.

Everything works good (Branching, updating files and all the stuff) until I need to make a plugin update. The problem is, that I only want to do updates on my develop instance in the future. So when I do an update, I can push all updates files to git. But there is a huge problem - the database.

I've tried to do some research to find out if there is any tool to make my databases working like GIT but I can't find any Open Source Tool which seems to be good enough to handle this task. There is a plugin for this, but I don't want to use a plugin.

So I hope there is a better solution to perform a continues delivery process like this here in WordPress:

Does anyone have experience with this kind of process within WordPress? If yes, how do you handle this to be 100 % safe with developing and updating WordPress?

I'm thankful for any ideas / help / experiences I can get!

Answer 1

There are open-source solutions out there to migrate database changes and WordPress configuration (WPCFM) in the way you've described, but I'm going to answer this by giving insight into the most common practice in a simple scenario.

Updating plugins

Let's assume all 3 environments are the same except the database on production which has new content. Your dev and stage environment databases might be a bit behind, but it's essentially the same except for the new content.

First, always make sure you back up your database before starting this process.

1. Commit your plugin updates

While these changes are tracked in git, the updates may have associated database updates that need to be made. Good plugins handle this by checking the current database schema before requiring user action to make database changes, if necessary.

2. Copy the production database to staging

Make sure you change urls and protocols in the database during this process, if necessary.

3. Push plugin updates to staging

Now you have a replica of the production database with the file updates from dev and the latest content from prod. This allows you to test the update process on this environment before moving forward.

4. Deploy live

Now that you've tested on a copy of production, you can deploy your changes live and replicate any database changes necessary with low risk.

As an alternative, you could freeze database changes while you're testing on staging. This would allow you to deploy your database and files at the same time. This isn't usually feasible since database changes can occur all the time on busy sites. It's not something I recommend, but it can be necessary in some circumstances.

Other resources

Certainly don't take my word for it. Do some more research to find the method that works best for you. For Example, take a look at Pantheon's deployment process.