Importing/Exporting configuration between Dev and Prod environment

[patrickkaleta]

NOTE: This issue discusses how to migrate configuration (e.g. site configuration like caching, configuration of Views and display & form modes, available fields in content types, ...) but not actual content (node A, Tax. term B). That is adressed in a separate issue (#147).

We're using the Configuration Split module to manage, which configuration will be enabled on the Dev or Prod server only and which will be enabled on both. Configuration will always be imported/exported completely as yaml files, but into different directories (inside /app/config/), which will (depending on the split settings) be used or ignored on the two environments. That way the configuration will always be completely available in our private Git repo.

Managing splits

Splits can be managed at /admin/config/development/configuration/config-split. We will have one split called dev_split. On the Dev server this split needs to be active, while on the Prod server it has to be deactivated. That will be handled in the settings.php by setting
$config['config_split.config_split.dev_split']['status'] either "TRUE" or "FALSE".

The process in general

1. Changes will be made on Dev server (e.g. a new field or a module will be enabled/disabled)
2. View all the changes at /admin/config/development/configuration and:
   2.a) If this change should not take effect on Prod, then the split needs to be configured to exclude the change (see Managing splits above)
   2.b) If this change should take effect on Prod, the split doesn't require any changes.
3. via terminal export the configuration using drush config-split:export (short: drush csex)
   Note: When asked whether to perform a normal (including filters) export, select YES. Confirm export by viewing pending configuration changes (as shown in step 2). This should now be empty.
4. Push configuration to private repository and pull on Prod server
5. Run composer install first if composer.json file changed, otherwise configuration import might fail
6. If there are any new modules added by composer, they now need to be installed in Drupal via the "Extend" page in the Backend UI
7. Import configuration via drush config-split:import (short: drush csim)
8. check if updates in DB are necessary with drush updb
9. clear cache with drush cr

Limitations

Due to the difficult selection possibilities in the UI of this module and unpredictable relationships between individual configuration files, it is not feasible to use this module for short-term differences in the configuration of both servers (like "new field was added but we don't want to yet include it in the upcoming synchronization"). It's difficult to achieve and very error-prone.
This module is meant to be used for permanent differences in the config (like always disabling the Devel module and it sub-modules on the Prod server for security reasons).