Problem/Motivation
We want to add a mechanism to have different modules installed in different environments.
Core currently does not support this at all, but there is a contrib solution with config split.
The issue #3028179: Config Environment module (original issue) is where the work around this is happening. For most of the challenges we already have solutions implemented or planned. But there is one major issue for which we have to find a solution for this to work on real sites. This issue here is to discuss and find solutions for it so that the other issue can focus on implementing it.
A regular workflow looks like this:
In the development environment:
- update the code base with new versions of modules. (composer update)
- run update hooks
- export configuration
deploy code and config
in the production environment:
- update code base (composer install)
- run update hooks
- import config
The problem arises with update hooks of modules that are only installed in certain environments (most notably the production environment). This is because the update hooks of the production-only modules only run on production and thus may have effects on configuration that is then only modified in the active store in production. This of course then creates the challenge with the next step of the deployment which is the configuration import that would revert the changes the update hook has made. (and could possibly fail)
With config split one can overcome this by exporting only the production splits configuration with the special drush command just after the update hooks have run and before the config import.
Proposed resolution
TBD
Remaining tasks
find solutions
agree on what is best
Implement chosen solution in #3028179: Config Environment module (original issue)
User interface changes
n/a
API changes
n/a
Data model changes
n/a
Release notes snippet
n/a
Comments
Comment #3
bircherTogether with the other issues in this space this is the focus of 9.1. The issue can of course still be discussed now.
Comment #5
bircherpossible solutions that came to my mind over the last half year:
1) before running update hooks, snapshot the active config, and after the post update hook dispatch an event with the config names that changed as part of the update.
2) add schema versions to the configuration when exporting the environment configuration. Then ignore (import the active config) of the active environment if the exported version is too old. Or don't allow the import.