• CM: Configuration Managment
• CMI: Configuration Managment Initiative
• CMS: Configuration Managment System
• CS: Configuration System

Traditionally, there are three seperate but interdependent peices of Drupal:

Code

Database

Filesystem

In order to effectivley manage change in your application, you need a way to control the state of these pieces.

Managing change in code is a problem with a widely accepted solution. Version control systems, such as Git, are very good at this.

Unfortunatley, the same is not true for the database. This is where configuration mangment comes into play.

Configuration managment allows you to control the state of your database by exporting its configuration to code, which can be managed in your version control system of choice.

• You can easily deploy database updates between environments in the same way that you deploy code updates.

• You never loose vital changes to your database because its history is managed by your VCS.

In Drupal 7, configuration management is made possible by contributed modules, namely Features and Strongarm.

• It lives in the contrib space, which means there is no centralized API in core for module developers to expose their configuration. For example, you could use either Entity API Exportables or Ctools Exportables.

• Features was designed to bundle up small chunks of descrete site functionality, not to act as full configuration store for a complex site.

• Configuration can become spread between multiple features modules, which makes it hard to keep track of.

• Features modules can have interlocking dependencies, which can make changes harder down the road.

• Resolving merge conflicts in large features modules is tedious and error prone.

• Features can create things, but it can't really delete them. You have to write an update hook to remove things from the database, and also remove them from the features code.

• There is a centralized configuration API in Drupal 8 core.

• All of you configuration now lives cleanly in your configuration sync directory.

• Resolving merge conflicts is a lot easier because we have a bunch of small files instead of one large one.

• The CS is capable of deleting things.

• The CS is designed to move configuration between different instances of the same site, not between two separate sites.

• What this means is that you should set up new environments from a database dump of an existing enivronment. This ensures the site's UUID's will match.

• Modules and themes can provide default configuration that is imported when they are installed. These configurations are found in a module's config/install or config/optional directory.

• Updates to the files in the config/install or config/optional directories will have no affect on modules that are already installed.

Drupal sites are often complex and have many interlocking dependencies. Dependency calculation tries to prevent you from accidently breaking your site by warning you before you delete or remove a component that's needed somewhere else.

• The active configuration store is the one that is currently in use. When you first install Drupal, this is the database.

• When you export your configuration, you're exporting settings in the database to the file system, or from one store to another.

• The active configuration store is configurable, letting you swap it out as needed for other backends like Redis or MongoDB.

In Drupal 7, all variables were global (think vset and vget), which means that they were loaded into memory on every page load. In Drupal 8, these variables are only loaded into memory when they are needed.

There are four main categories of data in Drupal 8

Information of a temporary nature, generally machine-generated and not human-edited, about the current state of your site.

Examples: the time when cron was last run or whether node access permissions need rebuilding.

• The data is specific to an individual environment.

• You will never want to deploy it between environments.

• When you reset a system, you lose all state, but configuration persists.

Information about individual users' interactions with the site, such as whether they are logged in. This is really "state" information, but it is not stored the same way so it's a separate type.

Information meant to be displayed on your site: articles, basic pages, images, files, custom blocks, etc.

Information about your site that is generally (or at least can be) human-edited, but is not content, and is meant to be relatively permanent.

Examples: the name of your site, the content types and views you have defined.

• Content is created by site authors and configuration is created by site builders.

• Configuration = types of things and content = things. Article content type vs article nodes.

• Blocks are content, but block placement is configuration.

• Menus are configuration, menu items are content.

By default, Drupal sets up a configuration sync folder at a path like sites/default/files/config_really-long-uuid on install, but you can change the location by overriding it in settings.php

							$config_directories = array(CONFIG_SYNC_DIRECTORY => '../config/sync');
						

• By default, your active configuration is overwritten with the data in your file system when you import configuration. This is destructive.

• If you only want to import new configs and not delete untracked ones:

  drush config-import --partial

• To skip exporting configuration from certain modules use:

  drush config-export --skip-modules=devel

• Move configurations that you specify out of your central configuration store (the one shared between all environments) and into split directories.
• Different configurations for different environemnts. For instance, different caching settings on dev and prod.

Or you can use Drush:

							drush config-set "system.site" uuid "d509ae31-254d-47b6-af0d-1d841352a8ff"
						

• Key Concepts of config system
• Config API Overview
• Managing Your Site’s Configuration
• The New Drupal 8 Configuration System
• Configuration API overview page
• Config Management architecture (this is pretty out of date, but still useful)

• Using and abusing the configuration management system
• Config managment vs features session
• Configuration Cheat Sheat
• Simple config api
• Default module configuration