Confused about moving staging to live

When we port a staging site to live, are we sure that just the configuration assets are copied?

Maybe this is a silly question. I just want to make sure that "somehow" the Hosting environment understands the difference between staging data and live data.

Preface: I know that when we push staging to live that we have this step: "What do you want to push? You need select to copy Files Only or Files & Database. If you include your staging database then your production database will be replaced and any database changes made on production since last copying it to staging will be lost. That can include new users, new posts, updated settings, etc."

That's Really scary.

Examples:

– We load a theme and set all Customizer details, then port staging to production. The database details for theming get passed to the live site. But we're sure users and posts aren't also copied to live? It's all in the same database just different tables.

– We add a new plugin to staging, change settings, put a new widget into a sidebar. The software is in the file system but the configs are in the database. We can't push one without the other. Are we sure we're not corrupting the live database, removing details that might have been set while we were developing in the staging side?

– In staging we make changes to a plugin like Defender, which is tracking the IP address of failed logins. We port staging to live. Does the live site now have the IP addresses used in staging? Does the live site lose its live data? How does this process know that we want the Defender config detail but not the IP address detail?

– In staging we add images to the media library and then use one of them as the new homepage banner. Is that image copied to the live site? Does the staging-to-live process only Add media, or does it Add+Overlay?

– We add a new plugin to staging and it gets to execute its hooks for Installation and Activation. That code is executed in the live environment right? I mean, if we just copy and then activate a plugin, it doesn't get a chance to execute its installation hooks.

– We make changes in staging which include changes to wp-config.php. When we migrate staging to live, of course we don't over-write live with the staging details … the name of the database, salts, and other details are unique to each environment. So how does the migration process recognize which parts of the config file should and should not be ported during staging?

– What happens when we set .htaccess details, or file permissions and ownership in the staging side. Is all of that copied to live too? If .htaccess includes IP addresses or other server-specific detail, does that overlay the live site?

Consider another scenario where we stage an environment and then in the live side someone adds a plugin. OK, that's a big NoNo. For this there is an option in staging to "reset staging environment", where live is copied back to staging. Awesome!

What's missing, and I don't expect this, is a Merge concept. This is exactly the same as software version control where we need to merge recent updates on Master back into a Dev branch. That's complex. Again, I don't expect this but I see problems in this area if there isn't adequate documentation to explain it. Or – possibly an option to lock configuration details in production sites when they are backed by a staging site.

Adding a plugin to the live site violates a new protocol to do everything in staging, but there are many scenarios where we want to change a config setting based on new live information. Consider the above example with Defender: While the site is being modified in staging the site admin is blocking specific IP addresses that are known abusers. If the developer ports staging to live do we lose that data? Does the admin need to pass that info to the developer to set it in staging so that it's ported back to live? There are some details where auto saved data like this can't be manually entered. This becomes a huge procedural hassle in even the smallest public site.

OK, so let's consider getting everything right in staging, and then, rather than taking a chance of messing up the live database, we just "remember" all of the changes in staging, and then repeat them in the live environment after porting the file system. Further, it means a period of downtime while all of those details are manually entered. That sort of eliminates any benefit of this staging-to-live function.

So… I'm really confused. I'd like to see a detailed definition of exactly what we are expected to do when we port from staging to live. That should include a list of details that are Not moved in this process so that we know exactly what we Do need to do following this event.

What I'm getting from this thought process is that the staging environment is just a conveniently located system, and that copying live to staging is now easier. But given the details currently available I would never copy from staging to live. There are innumerable places where this could go wrong, and we might not know about it until something really bad happens. To me, the auto-copy of staging to live is much more dangerous and not better when compared to other practices that we already follow to try to ensure that we don't corrupt live systems with transient development changes.

Honestly, the more I think about this the more terrified I get of this. I would strongly recommend that WPMU DEV deactivate this until it's thoroughly documented and tested, and all of these considerations are adequately addressed.

Thanks.