Cross-posted with permission from Drupalize.Me
One thing in Drupal 7 that people have a love-hate relationship with is the Features module. Features gives you the means to export database-stored site settings in code that you can put into version-control and move from server to server. In Drupal 7, when using Features to make a change to your Drupal site configuration settings, you need to update the feature or make sure the settings are in a feature and (re)create them. When deploying, you revert your features so your site settings match what is in code.
If only things were that straight-forward! Frequent "gotchas" are had because nobody really knows what the best practices are for using Features until some really painful and time-consuming mistakes are made! It's a hard way to learn. But Drupal 7 site settings are stored in the same database as regular ole' content, so relying on database backups to deploy settings and update the live site isn't ideal either. User-generated material can be lost. With no UI-based alternatives, many of us adopt a Features-based deployment workflow, but we kick and scream along the way.
That is...until Drupal 8 ships.
The Configuration Management Initiative (CMI) was created to fix this headache. Although it's still a work-in-progress, a foundation exists and the basics are working. As you point and click around a Drupal 8 site, configuration settings are no longer being stored in the database, but rather in configuration files. Looking at a fresh install of the Drupal 8 file structure, check out sites/default/files and you will see a folder called config_ (note the hash). Out of the box, Drupal 8 stores all configuration settings inside many ".yml" files (pronounced yah-mull). The reason for the hash at the end of the folder name is because the folder must be web server readable. This originally caused security concerns because prying eyes could potentially view information stored in these files, but the CMI team now includes an .htaccess file to mitigate any risk. Along with the hash to stop someone from just attempting to find the directory itself, this security concern is now addressed. This is how things work out of the box because not all servers can handle all methods of security. The final measure is the ability to move this folder out of the docroot via the settings.php which is 100% recommended for everyone.
How does this work with modules?
It is actually quite cool. A module will ship with its own config folder and default configuration settings. When a module is enabled, the system will copy the default settings to the master config_ folder. When the configuration settings are modified, the new settings are stored with the rest of your site's configuration settings under the same security measures just described.
Now that we have an understanding of how deployment will work in Drupal 8, let me walk you through the process as it stands currently. I have set up two Drupal 8 sites locally. I will make a change to the site name on one and move the setting to the other. Let's take a look:
This is a very basic demo of a very complex feature. I just want to show how deployment has progressed from Drupal 7 to Drupal 8 when it comes to configuration settings.
Note: The config_ folder does contain two sub-folders, active and staging. The active folder contains the current site configurations. Staging is for what will become the configurations. This system is in place for more advanced deployments using version control. I did not cover this because CMI is still a work-in-progress.
