Deployment and configuration management are pretty common but very important parts of every project. These processes are too painful in Drupal 7. Drupal 7 stores all configurations in a database together with content. To manage configurations, you probably have worked with a combination of Features, Strongarm, and other related modules. These modules provide a way to package config into the special “features” Drupal modules.
Drupal 8 provides a completely different way of managing configurations.The idea is that almost all configurations can be stored in files rather than in a database. It allows developers to move settings between development and live sites easily.
In this article, we’ll dive into a new Configuration management system and will learn how to move your configurations from a development environment.As a result, we’ll develop a basic workflow which will help to keep your configurations synchronized between environments.
Before we start, we should determine which part of your website can be exported with a help of the new system.
Actually, everything besides content is configuration. Following this idea, it is wrong to think that a new configuration management system can help to move content from a development website to a production one. Using the new system you can manage:
The following things are considered as content and can’t be managed:
To move content from dev to prod you probably have to think about a migration system but this is a completely different story.
Let’s examine the configuration management system in action.
Configuration management functionality is provided by the “Configuration Manager” core module. Make sure it is enabled. After that, a new admin page will be available: /admin/config/development/configuration.
This page allows you:
Out of the box active Drupal 8 website configuration is stored in DB in “config” tables. This is done for performance and security reasons.This new system allows us to export complete website configuration and store it in YAML files.
Before starting working with configuration let’s configure a folder where we’ll store our configuration YAML files. This folder is configured in the setting.php file:
$config_directories['sync'] = 'sites/default/files/config_HASH/sync';
HASH here is a long hash generated at the stage of installation; it helps to protect configuration from web access.
Now we can export active website configurations manually or use Drush: drush config-export (or drush cex). We stick to Drupal way and will use Drush in this article.
Let’s stop at this point and think a bit. Almost all website configs are now available as YAML files. What does it mean? YAY! It means that we can store your configuration YAML files under a version control system!
We are almost sure that your sites/default/files folder is ignored by the version control system. No? Do it ASAP:)
It is recommended to move your config folder to the same level (a sibling of) as your docroot directory (it fully prevents web access to it). That is not always possible and you can move it to the same level as a public files folder (sites/default/files).
Just move the folder and change the setting.php file:
$config_directories['sync'] = 'sites/default/config_HASH/sync';
After running Drush command, YAML files will be created and you can commit them. Let’s get back to admin UI.
At this stage, there are no configuration changes because we just have exported current active configuration. Let’s change something on a website (e.g. a site name) and see what happens.
We can see that one configuration item (file) was changed. Now we can see the changes:
What’s in the picture?
Stage configuration is a configuration which is saved in YAML files.
Active configuration is a current website configuration stored in a DB.
At this point, it is very important to understand differences between export and import.
Export is for taking all of the configuration defined in the DB and saving it as YAML files.
Import does the opposite action: it imports the configurations out of YAML files into the DB.
In our example, if you run import using “import all button” or running drush config-import (drush cim) command, it will wipe out a site name change to a state from YAML files (stage config).
If we want to change our staged config we have to run the export. After that, the appropriate YAML file will be changed and we can commit changes.
To summarize, a basic workflow to move changes from your dev environment to live one is the following:
On a development website:
On a live website:
As a result, our development and live websites get synchronized in a few simple steps.
Drupal 8 strives to make a process of exporting and importing site configuration easier using a new configuration management system. In this article, we have examined a basic workflow which allows to keep your configurations synchronized between development and live environments. I hope that this workflow will help you to improve your deployment process.
Originally posted at the ADCI Solutions website.
Follow us on social networks: Twitter | Facebook | LinkedIn
How to send the JSON data from a Drupal 8 site? - Drupal stories: an insider's view - Medium_Imagine a situation: your mobile application needs to get some information from your site on Drupal 8 using JSON. Why…_clc.la