How do I manage core and module updates along with config management between environments?

Question

I've set up a dev site, a test site, and a public site. Dev and Test are in two separate virtual machines (VLAD) and Public is on a shared Dreamhost account. I've successfully used the Configuration management tool to get all three of these environments in sync by installing it once, then copying the files (git) from one to the other environments, and exporting/importing the database information. Now it is time for me to update something like Drupal core from 8.0.3 to 8.0.4 and I am unsure exactly how that should happen with relation to getting that update on the other two environments. So, the main question is: how should I migrate/deploy/manage the upgrade between environments taking into consideration the need for UUID and CMI to stay intact?

Should I update one environment, lets say dev, using whatever chosen tool I have handy (like drush up --security-only or download the new version, and hit update.php in the browser, etc.) then copy those files from dev to test and re-export/import the database info? Or, should I update each of them individually? I suppose the thing I'm most worried about is will that break configuration management? Maybe I don't need to export/import database files and instead just export/import config changes after updating drupal or some contrib module into the dev site.

I've read what feels like 50 different posts about CMI and how to use it and how Drupal 8 makes some of this so much better and I totally agree about the information that actually gets managed by that tool but I can't seem to find information about how to deal with upgrading core and modules between these different environments. If I'm just not reading the right doc or blog post correctly and you can point me to one that is great. If you can answer directly here that is great too. And, maybe I'm just not "getting it" so please feel free to set me straight.

My question may be similar to the one posed here but it isn't exactly worded the same, so, again, I may just be missing the easy answer here.

Answer 1

Yes, the referenced issue is related but I think this deserves a separate answer.

I agree this situation isn't fully satisfactory, but it's not too much of a problem.

In most environments, it won't be possibly to avoid manual configuration changes on production entirely. For example, contact forms are configuration (and not just a single file but 3 + 2 * number_of_fields) and users will likely create new ones without going through staging.

That basically means that you have to live with the situation that there can always be changes on production that are different from what happened on staging/dev. And that you have to treat the configuration on production as the master, unless you're deploying specific changes.

My process for deploying configuration changes usually looks like this:

1. Do the changes, commit them to a feature branch.
2. Export the configuration from production and commit it to whatever branch you use for that (for me, that's usually a branch called "production")
3. Merge your changes into that. Resolve conflicts if necessary.
4. Deploy the code to production.
5. Verify the configuration changes, make sure that ther are only known changes that know you prepared for deployment.
6. Import the configuration.

Module updates add the additional problem of update functions. If you have those, you need to run them between steps 4 and 5. Usually, those aren't a big problem unless they create new configuration with new UUID's. Then you have a problem if you want to import the same configuration entities from the staging config since those would have different UUID's and it would lead to deleting and re-creating them. You have to merge back the changed configuration from production before you can do that.

In general, I'd recommend to not mix module updates with feature/configuration deployments. Do module updates first, export the configuration again, then deploy again with new configuration.

Note that enabling new modules isn't affected by this, unless the module is installed by an update function. But if you deploy new modules through an updated core.extension module list, the config system supports that explicitly by taking the new configuration from your configuration export and not the module's clean default installation. So it's perfectly supported to enable a module on staging, customize its default config (not just simple configuration but also views and so on) and then deploy it to production.