Per Environment Config in Drupal 8
One of the biggest improvements in Drupal 8 is the new configuration management system. Config is now decoupled from code and the database. Unlike Drupal 6 and 7, developers no longer have to rely on the features module for moving configuration around.
Most large Drupal sites, and some smaller ones, require per environment configuration. Prior to Drupal 8 this was usually achieved using a combination of hard coding config variables and features. Drupal 8 still allows users to put config variables in the settings.php file, but putting config in code feels like a backward step given D8 emphasis on separating concerns.
For example we may have a custom module which calls a RESTful API of a backend service. There are dev, stage and production endpoints that we need to configure. We also keep our config out of docroot and use drush to import the config at deployment time. We have the following structure in our git repo:
/
+- .git/
|
+- .gitignore
|
+- README.md
|
+- config/
| |
| +- README.md
| |
| +- base/
| |
| +- dev/
| |
| +- prod/
| |
| +- stage/
|
+- docroot/
|
+- scripts/
|
+- and-so-on/
When a developer needs to export the config for the site they run drush config-export --destination=/path/to/project/config/base
. This exports all of the configuration to the specified path. To override the API endpoint for the dev environment, the developer would make the config change and then export just that piece of configuration. That can be done by runing drush config-get mymodule.endpoint > /path/to/project/config/dev/mymodule.endpoint.yml
.
Drupal 8 and drush don't allow you to import the 2 config sets at the same time, so we need to run 2 drush commands to import our config. drush config-import --partial --source=/path/to/project/config/base && drush config-import --partial --source=/path/to/project/config/dev
. The first command imports the base config and the second applies any per environment overrides. The --partial
flag prevents drush deleting any missing config. In most cases this is ok, but watch out if you delete a view or block placement.
Best practices are still emerging for managing configuration in Drupal 8. While I have this method working, I'm sure others have different approaches. Please leave a comment if you have an alternative method.