There needs to be a better way of ensuring the integrity of configuration exports (i.e. config/default/*.yml).
Currently, many projects use a workflow like this to modify configuration:
- Developer makes a change locally and exports configuration to disk (e.g. drush cex to dump configuration to config/default)
- Developer opens pull request with these changes
- Lead developer reviews and merges configuration changes
- Changes are deployed to a remote environment and imported (e.g. drush cim)
The problem is that at step 3 where the lead developer is reviewing the proposed configuration changes, she/he has no practical way of knowing if the configuration changes are complete, consistent, and valid. There's a lot of things that could have gone wrong, here are just a few examples:
Simultaneous changes to configuration files
Recently, we upgraded to Drupal 8.3 around the same time that we were adding a new content type. Note that Drupal 8.3 modifies configuration for content type form displays to include a "region" key. One developer opened a pull request to upgrade Drupal to 8.3, which modified all of the existing config exports to have this new region key. At the same time, a developer opened a pull request to add the new content type, which obviously did not include the region key. When both pull requests were merged, we ended up with invalid (outdated) configuration for the new content type, since it was lacking the region. This particular example seems relatively harmless, but for substantial config schema changes this could be very dangerous, producing insidious problems that only become evident much later.
Applying db updates to configuration exports
When you upgrade a core or contributed module, quite often it will be accompanied by database updates that alter related configuration. When this happens, it's critical to remember to export this changed configuration to disk. Otherwise, even if you run database updates in a production environment, those updates will be clobbered next time you import configuration, and you'll end up with mismatched module and configuration versions. In practice, it's incredibly easy to screw up this process, and it again leads to insidious problems that are hard to correct.
For an existing discussion of this problem in the context of Features, see #2745685: Features and contributed module updates. For an example of how to (very carefully) work around this issue, see this BLT documentation.
Incomplete configuration export
Especially if you're not using an environment-aware solution like Config Split, it's easy to accidentally forget to commit a config file. In a best-case scenario, this produces an immediate fatal error in automated tests due to a missing dependency. Worst-case, it may not be obvious that the configuration is missing for quite some time, leading to obscure bugs and lost development time (entire features often have to be re-developed if just a single config file is missing).
"Cowboy" editing of configuration files
Sometimes for smaller changes, it seems easier to make a manual change to a config file rather than making the change "properly" through the UI. But it's easy to screw up manual edits. Additionally, sometimes changing one "simple" configuration via the UI actually touches several configuration files. These downstream changes are often neglected when manually editing individual config files.
Possible solutions
It might be easy to discount some of these as process or people issues, but the fact that there are so many ways to break configuration (and even the best teams do break it pretty regularly) points to the fact that we need better ways of validating it and ensuring internal consistency.
I'm not sure how to solve all of these issues, but one thing that could help would be for modules to define configuration "versions", or to hash configuration or module versions somehow, in order to ensure that a given configuration export is up to date with all relevant modules on the site, and to ensure that database updates haven't gone uncaptured. More robust use of config schemas could also help. Finally, better separation / compartmentalization of config files would help. Things like third party settings on nodes are notorious for this sort of thing. For instance, if you enable something like Panelizer or Workbench, it modifies existing content types and requires re-exporting dozens of config files that aren't really owned by the module.