simple CI using Drupal 8 config management and Acquia

The new configuration management system in Drupal 8 allows site settings to be exported and imported to and from code. This is great for code driven development and marks the end of managing configuration with features and strongarm. With this change also come a change in the deployment process.

using the configuration management system

Config is exported to directory defined in settings.php.
It is still possible to set environment specific variables as with Drupal 7.
For large amounts of config we recommend adding another config directory, such as “prod” where all production specific config is placed.

$config_directories['sync'] = '../config_sync';
$config_directories['prod'] = '../config_prod';

if (isset($_ENV['AH_SITE_ENVIRONMENT'])) {
  switch (isset($_ENV['AH_SITE_ENVIRONMENT'])) {
    case 'prod':
      $config['system.logging']['error_level'] = 'hide';

avoid exporting unwanted config

There will often be config that is undesirable such as devel settings.
We can add these files to the .gitignore to prevent them from being committed to code. It’s also possible to update the drush configuration files and provide a list of modules that we want to ignore during the export process. This will stop the modules being enabled but the configuration files defined by the modules will still be exported.

Add the following to docroot/drush/drushrc.php

# Skip development modules when exporting config.
$command_specific['config-export']['skip-modules'] = array('devel', 'devel_generate', 'reroute_email');

Because this does not stop Drush exporting the configuration files defined by the modules we also need to update the .gitignore file in order to avoid committing these files.

Common files will be the following:

# Ignore local module settings files.

pulling changes from production

What about configuration changes on the production environment?

We initially looked at using the config override system ( in order to provide a way of allowing specific config to be stored as a state ( This would work for a number of scenarios such as changing the site name or email but it quickly became clear that this wouldn’t work for all config instances, particularly if there are changes or additions to blocks.

One solution to this problem is to introduce an additional step into the development workflow, that is to fold in config changes from the production environment.

This can be done via drush:

drush config-pull @local --label=sync

deployment tasks

There are 2 key Acquia cloud hooks to implement here, a common post-code-deploy hook that is run when deploying releases and release candidates to prod and test respectively. And also a dev post-code-update that is run whenever changes are pushed to the branch that the dev environment is watching.


drush @$site.$target_env cr
drush @$site.$target_env cim sync -y
drush @$site.$target_env updb -y

There may be an additional line to be added when there are environment specific variables exported to config as described above.

drush @$site.$target_env cim prod --partial -y

The use of the partial flag will mean that the config is added to the config that exists already and will not make any deletions.

If you want to take back control of your web sites and applications then get in touch with miggle to see how we can deliver operational freedom for you in Drupal.