I’m taking a break from my Drupal 8 OOP series to help further define something that has not been sufficiently spelled out in all of my D7 -> D8 research: when to use the CMI vs Features.

The configuration management system is meant to facilitate the workflow of development configuration to production, while Features is meant to hold a generic, reusable bundle of functionality.

Our Current Workflow

At Commercial Progression, we make a lot of Drupal websites. We try to make deployment from development to production as seamless as possible: configuration is stored in Features, and whatever we can’t get into Features will go in a hookupdateN() script. After we pull in our code changes from git, we can run the drush commands drush fra -y and drush updatedb -y and voila! Our production site has been updated and we have little to nothing left to manually configure in the UI.

The Old Features

I’ve been working to convert our internal modules to D8, and a few of these are Features modules. For instance, I just finished up compro_paragraphs, which defines 4 paragraph bundles (now “types” in Drupal 8), their fields, and their displays. There’s a bit of custom code in the .module file for display magic, but for the most part this module is all data structures and configuration. Turns out, this is what Features was meant to do. When we force all of our site’s unique configuration into Features, we’re just using a (brittle) shortcut to get things done. There was really no other way to get this done in Drupal 7, so the Features module stepped up.

Configuration Management Initiative

The wonderful group of developers for Drupal 8 heard our cries for help and gave us the CMI. The configuration management system specifically targets the workflow of development configuration -> production configuration. Configuration management relies on a UUID (Universally Unique Identifier) to verify that the export is of the same site. You can try to cheat the system by deleting the uuid line out of your export files so that they’re reusable, but I wouldn’t recommend it.

Now, instead of creating multiple Features to hold our whole site configuration, we can export the entire site through the configuration manager and commit that to our repository. Then we can import it on the production system after pulling our git changes. The CMI offers a diff screen to preview the changes before applying them. You can exclude some settings that you know will be overwritten when copying from development to production (like compressing and caching JS and CSS files). All in all, the system is very similar to what we’re used to in Features, and is working on being very user-friendly.

The New Features

Features for Drupal 8 is a new beast. It’s meant for making modules like compro_paragraphs; a generic module we want to put on multiple sites. Features was rebuilt completely to take back its original niche. They’ve also integrated some interesting new functionality, such as the ability to install a module made with Features without installing Features on the target site, and the ability to create bundles of Features.

This allows us many options for our development workflow: when we use a Features module, we can keep that module up to date when we commit our code. Or, we can integrate that Features module into our whole site configuration export. Either way, it seems like only doing a CMI config-import during production deployment is the simplest way to keep things synced.

Our Future Workflow

Once we have fully practiced the importing and exporting of full site configurations, our team will form a consensus of what gets excluded from our configurations, but for now I feel confident in saying that we will be using both Features and CMI in our Drupal 8 workflow. In any case, the fewer actions to take after a git pull, the better.