Drupal 8 Configuration Workflows
With our new configuration management system as part of Drupal 8 core we now have a powerful system to manage site configuration between our different environments. This system does not declare a strict workflow for how to use configuration. In this post I’d like to explore some workflows we have been exploring.
First let's define what site configuration is.
There are two types of configuration in a Drupal site. First, simple configuration which stores basic key/value pairs such as integers, strings, and boolean values. Second, configuration entities, which we explored in this post. Basically configuration entities are more complex structures that define the architecture of our site. This would be things such as content types, views, and image styles.
Both types of configuration entities are exportable.
Where does this configuration live?
Site configuration lives in two places depending on its stage in life (no pun intended). There are two stages in a piece of configurations life:
-
Staging
-
Active
Active configuration lives in the database by default. It is the configuration that is currently being used by the site. Staged configuration lives on the file system by default.
When you make changes to the site within the web interface, for example changing the site name, you are changing the active configuration. This active configuration can them be exported and staged on another instance of the same site. The last piece is key:
Configuration is only to be moved between instances of the same site.
For example, I change the site name on our DEV environment and want to move this change to our TEST environment for testing.
Ok, let's talk workflows
There are a few ways we can manage the site configuration. Site configuration, like our code should follow a “flow up” model. That is, configuration will be committed to our git repo and moved up into higher order environments:
LOCAL → DEV → TEST → PROD
In this workflow configuration changes will be made as far down the chain as possible. In this case on a developer's local environment. These configuration changes should be exported and committed to their own branch. This branch can then be pushed for review.
Once pushed these configuration changes will be “staged” on the DEV environment. A site administrator will need to bring these staged changes into the “active” configuration. There are two ways we do that today:
-
Through the sites UI from under ‘admin/config/development/configuration’
-
Using a drush command ‘drush cim’ command to import staged configuration to active.
From what we are seeing this seems to be the defacto workflow at this point.
Further workflow Ideas
I am thinking there could be some interesting workflows that could emerge here. One idea is to have a branch (or tag) that triggers configuration imports using drush and fires off some automated tests. If all passes then merge into another designated branch for movement to a live environment.
Another idea is to use some of the emerging contrib modules to manage different “configuration states”. I believe this was discussed in the config_tools projects issue queue. Using this idea we can tag known “good” configurations and move between different “configuration states” of a given site. I am thinking we could even have the configuration hosted in separate repo then our code, if that makes any sense.
Bottom Line
The new configuration management system offers a powerful tool to move changes on our sites between different instances. It does not however define an exact workflow to follow. I look forward to talking to folks on how they leverage this system to coordinate the efforts of high performing teams!
If you or your team is using this in different ways we would love to hear about it!
