Configuration Deployment Best Practices in Drupal 8

Until version 7, Drupal was a careless entity which always had a tendency to ignore developer’s plea and patience. But now with an innovative touch of Symphony, Drupal has started taking care of the pitiful developers. This care and concern comes with the advent of a solution called Configuration Management. Drupal developers always had problems managing config settings from Dev to Live environment. They had one problem solving tool called Features. This was addressed at a sesson on Configuration Deployment Best Practices at DrupalCon Barcelona.

The Features module, as we can see in large successful sites implements configuration management, but the problem is that it’s not setup to be a management solution for a large system like Drupal CMS. It was always designed to work like a tool, and had a number of issues.

• Since its a contrib module, it only manages to create a workaround solution because it cannot change the code at Drupal core.
• It has to work with and support different contrib modules like Views, Rules and others, and has to constantly keep a check on these contrib modules so that they remain compatible.

Drupal 8 to the Rescue

Drupal 8 is definitely going to get better. It gives a simple solution called ‘Export config’. With this, all the configuration settings of the website is put in the code itself and can be kept in the version control system, most popular of them being GIT. A very good advantage that it brings with itself is that it has to be used by all, and will make life easier for developers. It is possible to take any piece of data and put in a YAML file (structured data file like an XML, readable, pretty clean).

In Features, there may be some cases where there are conflicts, or an Overridden state, but in D8 config management system there is only one place where everything is kept.

Advantage of .yml config files over database is that we can deploy these values between different setup and environments, and can have versioning over them.

What about the database then?

Database in D8 is used as a run-time data store. Not every time the data values can be stored into files because it is an expensive process. It's only when you use import/export operations will these values be copied into the file system. The path where these settings will live is defined in the settings.php like ‘sites/default/config’. By default, it is in files/ folder.

Features also has a D8 version but it only uses Configuration Update Manager module that will only update the .tml files living in the file system. There are certain Drush commands that have been introduced in Drush v8 for configuration management.

A DEMO was organised by @weitzman on his local machine that showed how config settings can be moved from one Drupal 8 setup to another (dev to test environment)

Advantages of config management solution in D8:

• Rollback to a prior config is possible using GIT
• Accountability and Auditability
• Continuous integration is possible - config settings can be pushed along with development work.
• It's better to go with the workflow rather than changing the config settings manually on a live environment. For this, there is one module called config_readonly that forces the changes through dev only and no one can edit .yml files in your Live environment.