Erik Erskine

CMI masterclass

Yesterday I was fortunate to attend a masterclass on Drupal 8’s configuration management initiative, led by Alex Pott.

The configuration management initiative (CMI) is one of the largest changes from Drupal 7 to 8. Many of the techniques and workarounds that we as Drupal developers and site builders had established for Drupal 7 don’t apply or are very different, and the Drupal community is still figuring much of this out.

Alex Pott is one of the core maintainers of Drupal and the CMI lead, so it was great to be able to pick his brains!

In the morning Alex gave an overview of CMI, what it is and isn’t, and why it has been developed.

“Configuration” is anything on a Drupal site that is specific to that site, but not to a particular instance. It isn’t content, state or cache. An image quality setting would be a good example - you want this to be consistent across dev/stage and production instances, to be able to audit any changes, and to be able to deploy these changes predictably.

CMI allows you to move configuration from one instance of a site to another. It also gives you a means to store configuration in version control, with all the benefits that gives you for source code now extended to your configuration.

CMI prevents configuration changes being applied to a site in such a way as to conflict with any other changes made on that site. Nothing gets silently merged, and you won’t end up with a production site with an untested configuration.

In the afternoon, we grappled with some of the thorny practical issues we’ve been facing.

For me, one potentially disruptive aspect of Drupal 8 configuration is coping with changes that are legitimately made on a production site. Often, it’s practical to delegate some configuration to a site administrator, to make changes without needing a new deployment every time. Arranging custom blocks seems to crop up often - relatively benign, but still a config change.

There isn’t a straightforward answer for this. In order to have the predictable deployments provided by CMI, you do need to have your configuration in version control. The best course of action is to treat your production environment as if it were another developer, and have a process for exporting the changes made and committing them to the source code repository. You may also choose to use a staging environment for this.

We covered lots of other things too:

Having a full day workshop was really beneficial. I felt I gained a solid grasp of the theory and motivation behind the configuration management initiative, the “why” rather than “how”, so to speak. It’s made me better equipped to evaluate different contrib modules and suggestions, to make sure they not only make tasks easier, but are also really sound.

Thanks to Alex, and to Code Positive for organising the day - I’d recommend their workshops. Also to Happy Ltd in Aldgate, a lovely venue for this sort of thing.