Configuration Deployment in Drupal 8 – DrupalCamp London 2017
DrupalCamp London 2017 was the best camp I ever attended. “You come for the code, you stay for the community” is the Drupal motto, and this camp lived up to it with great keynotes, talks and an atmosphere which really encouraged collaboration. It also gave me the chance to share my thoughts on configuration deployment in Drupal 8 in a dedicated session.
Configuration Deployment in Drupal 8
This session was an attempt to demystify and counter the idea that deploying configuration in D8 is a nightmare. I made a comparison of tools which help you in the deployment process and ran an exercise on how to improve it.
Here are the slides:
There’s already lots of literature about CMI, and the number of contrib modules and drush extensions which aim to improve configuration management grows every month.
But as Acquia’s JAM said in his keynote, we should stop focusing on the ‘What’: ‘What we do’; ‘What this contrib module does’. We should instead focus on the ‘Why’, by getting out of the developer mindset and thinking about the user experience.
The main problem is that CMI imports/exports a monolithic configuration containing all your website settings. It will overwrite, or even destroy, everything in the destination if it doesn’t exist in the settings being imported/exported.
For a simple website this can be enough, but for medium-large projects you want to tailor the process, selecting what can be deleted, what needs to be overridden and what must remain untouched.
Segmenting Drupal 8 configurations for better configuration deployment
My exercise was to identify common patterns between the contrib modules and what a site builder needs when importing the configuration. I spotted four recurring segments from the original monolithic block:
Primary: this segment comprises the main structure of your website: Content Types, Fields, Core Settings. When imported/exported its settings need to override the destination, and missing ones need to be deleted.
Secondary: this segment contains all the new stuff which needs to remain untouched. It contains client new instances of e.g. Webforms, Views, Page Manager. The settings on this segment do not have to be deleted nor overridden.
Initial: this is the one-time only segment. On import/export we “suggest” its settings. The destination will accept the configuration if it does not already exist. Otherwise it will be skipped. Think about the Site settings’ email value. During development you put yours, but then in Production the client can change it. So we “offer” it the first time, but we won’t overwrite it during following imports.
Devel: this is not a real segment, not an important one at least. It’s more a placeholder for any environment-configuration we require. The name I used refers to a hypothetical ‘Devel’-only configuration settings segment, where we want to keep the configuration of e.g. Devel, Stage File Proxy, Web Profiler contrib modules. But this is just an example. Outside of its context (the environment) this segment doesn’t have any value.
In the slide deck you’ll find the segment details. Below is a matrix (also in the deck) comparing how the most popular config-related contrib modules can (or can NOT) work with the PSI segments.
Continuing the CMI conversation
The audience at my talk seemed to like the approach and the naming convention. As I kept saying “naming things makes them less scary”.
I hope this convention can become the first drop of a waterfall of positive thoughts and improvements on the CMI world. I’ll see you at DrupalDevDays in Seville to continue the discussion, but in the meantime, please add your comments, thoughts and questions below.