What is CMI?
One of the major features of Drupal 8 is the Configuration Management Initiative (CMI). I’ll briefly touch on why CMI is so important, but our own Alex Pott has written extensively on the creation, principles and importance of this feature.
Previous to Drupal 8, it was cumbersome to trade configuration between sites and environments. Moving configuration changes from a developmental environment into production meant either making the changes manually through the UI, or utilizing an advanced option like Features. A third option would be full-database swapping, but that can be quite risky and is generally considered poor-form.
Configuration Management (CMI) allows us to export our site’s configuration settings into files. This means that we are now able to capture configuration changes in code. Pushing configuration through code means we can utilize and take advantage of Git’s features to manage our configuration in our repos! No more database swaps, no more manual checkbox clicking. This is a major win.
While CMI has a UI component, I strongly suggesting using Drush. The UI is a fine option when importing/exporting full-configurations, but the individual or “cherry-picked” changes take quite a bit of navigation. CMI is new to Drupal 8, and while it’s very powerful it’s also undergoing development - this includes the UI.
Database In, Database Out
The basic concept behind CMI is this:
Either you’re spitting out a site’s configuration into YML files from its database, or you’re sucking up YML files into a site’s database. It’s a basic import or export of configuration. You can consider the current database's configuration to be the "Active" configuration, and the exported YML configuration to be considered the "Staged" configuration. These configuration files typically live in the /sites/default/config directory, but this can change from site-to-site depending on what’s configured in settings.php.
You might be wondering “What does CMI capture, exactly?”. CMI is engineered to capture only the configuration aspects of a site. Configuration includes Views, Fields, Content Types, site settings, which Modules are enabled or disabled, individual Module settings, even Block placement. However, it does not capture site content – an important distinction to keep in mind.
You can use this Drush command to export configuration: drush cex
$~ drush cex
Drush will then prompt you with a list of items in your existing configuration YML files that will be overwritten with configuration from your database:
You can use this command to import configuration: drush cim
$~ drush cim
Drush will then prompt you with a list of items in your site’s database that will be overwritten with configuration from the files present in your configuration directory:
Your environment setup might vary, but this is the workflow I typically work with: I’ll make configuration changes locally and run the drush cex command. I’ll then add the resulting changed YML files to Git, and commit those changes to the project’s repository. Once the changes are in pulled into the development environment I’ll run the drush cim command. This imports the new configuration changes I’ve made from the YML files into the Development environment’s database.