Configuration Management with Environment-Specific Settings
A development team uses Drupal 10 with configuration management. They have three environments: dev, staging, and production. They use a Git repository to track configuration. The team reports that after exporting configuration from dev and importing to staging, the staging site's contact form recipients are overwritten with dev's email addresses. They also have a custom module that provides a block, but the block's visibility settings are different in each environment. The team wants to keep environment-specific settings out of configuration export. They currently use the 'Config Ignore' module but are unsure how to configure it properly. The site has 200 configuration objects. The team also wants to ensure that configuration changes are tested before deployment.
1. How can the team prevent environment-specific settings like contact form recipients from being overwritten during configuration import?
Read the worked answer
The team can use the 'Config Ignore' module to ignore specific configuration objects during import. For the contact form recipients, the configuration object is likely 'contact.form.feedback' (or similar). They can add that config name to the 'Config Ignore' settings. However, ignoring the entire contact form means that other changes to the form (like fields) won't be imported. A better approach is to use the 'Config Split' module to split environment-specific configuration into a separate directory that is only active in certain environments. For example, create a 'dev' split that contains the contact form with dev recipients, and a 'prod' split with production recipients. Then, in each environment, enable the appropriate split. This way, the base configuration is shared, and environment-specific overrides are applied. Alternatively, use the 'Environment Indicator' module and settings.php overrides for simple settings. For the contact form, you can also use the 'Contact Storage' module and set recipients in settings.php using a configuration override. The recommended approach is Config Split for complex scenarios.
2. How can the team manage the block's visibility settings that differ per environment?
Read the worked answer
The block's visibility settings are part of the block configuration. If the block is provided by a custom module, its configuration may be in the module's config/install directory. To have different visibility per environment, the team can use Config Split to override the block configuration in each environment. Create a split for each environment that contains the block configuration with the appropriate visibility settings. Alternatively, if the block is a custom block entity, its visibility settings are stored in the block's configuration entity. They can use the 'Config Ignore' module to ignore the block configuration entirely, but then they must manually manage it. A better approach is to use the 'Config Split' module with conditional splits based on the environment. For example, in settings.php, detect the environment and enable the corresponding split. Then, export the block configuration into each split. This way, the base configuration does not include the block's visibility, and each environment applies its own. Also, ensure that the block's configuration is not exported in the base config by excluding it via Config Split's 'complete split' or 'conditional split' settings.
3. What steps should the team take to ensure configuration changes are tested before deployment?
Read the worked answer
To test configuration changes before deployment, the team should implement a continuous integration (CI) pipeline that runs automated tests. They can use Drupal's built-in testing framework (PHPUnit) to test configuration. Additionally, they can use the 'Config Inspector' module or 'Drush config:status' to check for differences. A common practice is to have a staging environment that mirrors production, where configuration is imported and tested manually. They can also use the 'Configuration Read-only' mode in production to prevent accidental changes. For automated testing, they can write tests that verify that specific configuration objects have the expected values. They can also use the 'Config Export' and 'Config Import' commands in a test environment to ensure that the configuration imports without errors. Another tool is the 'Config Diff' module to compare configuration between environments. The team should also use a version control system and code reviews for configuration changes. Finally, they can use the 'Deploy' module or hooks to run post-import tasks.