When you push configuration to production, any configuration that has changed in production that has not been exported into code will either be reset to the values in code or be wiped out entirely if they never existed in code. One out of many examples is changing the site name. If that change didn't go into code (i.e. if a content admin changed it, not a developer), the next deploy would reset that change.
Now the solution we have in place is to pull the production DB down and export the configuration against production code. Any differences appearing in the export are configs that have changed on production since last deploy. It's a process that you can easily wrap your head around (
prod config - deployed config = changed config -> you check this in) and works pretty well so far.
But there are issues with this approach, one in particular is pulling the production database down. The DB may be huge, well into the hundred megabytes. It may contain sensitive info you don't want on your machines. Or it can only be retrieved indirectly (e.g. last night's cron job) and could already be stale by the time you work on it.
I know D8 config management is not perfect, and some things can't be avoided due to the current design of things. But I still would like to ask:
- Is there a better way to do the process of resolving configs on deploy?
- Is there any way to do this without pulling down the production database down?
- Is there a Drupal/Drush/third-party module feature that already does what I am describing?
- Is this more of a content workflow issue? i.e. never let content admins touch config?