tl;dr: Something like Configuration Split... but in core.

Problem/Motivation

Drupal 8's core configuration management allows me to export all configuration (or single files) and import all configuration (or single files), which is great. But one use case I run into quite often relates to how I develop Drupal sites.

I often have at least a local development environment in addition to production.

And sometimes I have a local, dev, stage, and production environment (4 total) that I manage.

The main problem I've encountered relates to my ability to have certain modules enabled in production, and other ones in other environments. As a simple use case:

  • Production uses Google Analytics
  • Local disables Google Analytics
  • Local enables Devel and XHProf for debugging, and I configure them specially for local

With Core CMI alone and a full export of configuration, it's impossible for me to export all my local configuration then deploy it to production, without manually deleting some files and editing a file like core.extension.yml to remove those local-development-only modules.

In the contrib space, the best solution to this problem that still allows a full, not --partial, configuration export/import, is to install and use the Configuration Split module.

As a user story:

As a Drupal developer, I want to have certain modules and related configuration differ between multiple instances of a single Drupal site, so I don't have to have all the exact same configuration in all my environments.

Proposed resolution

Have something like Configuration Split as part of core CMI.

Basically, give me the ability to have a 'split' of my configuration for each environment, and in each split, give me the ability to manage a list of installed modules and configuration that should only be used in that environment.

So when I export configuration locally, it preserves the configuration for Devel and XHProf, and also indicates I have the Google Analytics module disabled. But when I deploy the configuration to production, it knows that Google Analytics needs to be enabled but doesn't care about Devel and XHProf.

Remaining tasks

  • Figure out the best solution to this problem.
  • Do some coding magic.
  • Make this problem solvable in core.

User interface changes

TBD.

API changes

TBD.

Data model changes

TBD.

Comments

geerlingguy created an issue. See original summary.

cilefen’s picture

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

moshe weitzman’s picture

My first thought is that Contrib has not really solved this robustly yet. I think we should keep experimenting in Contrib and then move to core? Note that Drush and config_split are actively working on this so it shouldn't be too much longer until we have a better solution.

geerlingguy’s picture

@moshe - Indeed, this definitely needs to simmer a bit longer before anything is fully pulled into core. It's taken over a year just to get to a point where three or four main CM techniques are being adopted; I remember last time I looked outside what I was familiar with, there were probably 12 or so different tools and techniques people were using to hack around this problem!

To add to the mix, I identified the four features I really want out of CM:

  1. As easy (or almost as easy) as plain old drush cex -y to export and drush cim -y to import.
  2. Allows a full config export/import (so you don't have to use update hooks to do things like enable modules, delete fields, etc.).
  3. Allows environment-specific configuration and modules (so you don't have to have some sort of build system to tweak things post-config-import—Drupal should manage its own config).
  4. Allows certain configurations to be ignored/not overwritten on production (so content admins could, for example, manage Webforms or Contact Forms on prod, but not have to have a developer pull the database back and re-export config just to account for a new form).

(From Adding Configuration Split to a Drupal site using BLT and Acquia Cloud.)

Config Split hits 1, 2, and 3, but #4 is still a gaping hole, and a major turnoff to a lot of Drupal traditionalists who aren't used to giving up control over some things in Prod.

scott_euser’s picture

In the case of 4) we have been using drush cmi tools from PreviousNext to allow webform, contact forms, etc to be considered as client content and not part of the export / import.

The same config-ignore has helped us solve 1, 2, and 3 combined with - -skip-modules on export; however it doesn't allow a development setup to be shared between multiple local copies (without repeating steps) like config split does.

marcaddeo’s picture

@geerlingguy, the author of this article seems to have a solution for your 4th point of allowing administrators to use webforms.

They've created an "Excluded" split that ignores webform configuration and gets exported on production deploy, and then the configuration is reimported to ensure the webform configuration is not blown away. At least that's my understanding after reading the article, haven't actually tried that setup.

geerlingguy’s picture

@marcaddeo - It seems another option is to use Config Ignore, which may or may not be a cleaner approach than creating an 'exclude' config split and managing it in the deploy process.

Grayside’s picture

Doesn't this imply a first step of making core somehow environment-aware? Configuration isn't the only thing this applies to, for example, Environment Indicator.