One-way DB Migration Workflow

Question

I'm loving the proposed WordPress workflow shown below. However, since I am new to WordPress, I want to know how realistic it is.

DATABASES MOVE DOWN, CODE MOVES UP

This idea is presented both in a WPEngine support article for WordPress and in another article called "No More Cowboy Coding." The idea is that a tool like "WP Migrate DB" is used to pull a production database into a dev environment, but the opposite is never true.

Problems?

I'm concerned about plugins that I add in my dev environment that might make changes to the DB structure. Indeed, WPEngine has another article stating:

There are sometimes circumstances where changes you make on your development instances involve both code and database changes. In these specific cases, you can still deploy your code changes “up.” However, you will also need to download an export of the specific tables you wish to import to your production environment using phpMyAdmin. Most commonly, you will want to specifically export the wp_options table, as well as any other tables specific to the changes you made in development. Did you add a plugin that added database tables?

I'd like to understand how commonly a 3rd party installed/activated plugins will make (structural) DB changes? If perhaps 50% of plugins have this behavior, then this workflow is almost useless. If instead only 1% of plugins have this behavior, then I'm hardly worried.

Does anyone have a sense of this?

Again, I'm trying to assess how realistic this workflow is. I'd also like to know how others are dealing with the (rare?) occasion when a plugin does modify the database.

To clarify, I do not expect I will be developing any of my own plugins or themes. I anticipate only integrating 3rd party plugins and themes on my local dev environment, which I would then push to staging or directly to production.

Answer 1

I'd like to understand how commonly a 3rd party installed/activated plugins will make (structural) DB changes?

All the time for non bug fix releases. No matter what the plugin does, there are very few features that do not require some settings.

One way around this is to minimize the use of plugins. The other way is to "intercept" the plugin's requests to get the configuration from the DB and override it in your code. If foe example the plugin stores the relevant values in an option, IIRC you can use the pre_option_{option_name} filter.

You might need to add some plugin version check to return different versions of data between what is on production and dev.

To clarify, I do not expect I will be developing any of my own plugins or themes

Well, calling something 3rd party is not an excuse to not obtaining full control on what it does, as in the end you will need to solve any bug that happens on your site. Use only plugins which provide enough hooks so you will not have to run with them into a DB synchronization issues.