Fixes #1138: Support Config Split for environment-specific Core CMI

[geerlingguy]

This is a feature request, and it's something I'm still working on conceptually—it could also dovetail into a more nuanced approach in general to how BLT handles different Configuration Management scenarios.

Currently the default is to either do:

• Core CMI with --partial (which results in difficulty deleting fields and content types, etc.—you have to use a lot of update hooks and APIs to do cleanup work)
• Features + Core CMI with --partial (same caveats, but often better for multisite-style projects since feature 'packages of configuration' can be enabled or disabled per-site).

I've been building a site using the Configuration Split module for Drupal, and it seems to give me the best of both worlds for many aspects (block content management is still an issue... but that's a separate thing for a separate day):

• Works just like Core CMI (export and import everything. No need to deal with features workflow/creation/management issues, or the rogue drush fra ghost that requires extra drush cc drushes to clear up. Makes managing massive changes (e.g. deleting lots of fields and adding others, same with other config entities) a lot easier).
• Allows 'splits' for different environments (e.g. enable Shield in Dev and Stage, enable Devel and Stage File Proxy in Local only, don't enable certain modules in CI, etc., and have some configuration differences per environment (e.g. different Google Analytics settings per environment without hacking settings.php to kingdom come).

To use Configuration Split, besides the normal setup (documented on the module page), I needed to make a few modifications to a few of BLT's Phing build targets. So far I've done the following:

First, change import inside blt/project.yml to add my custom Phing target overrides:

import: '${repo.root}/blt/build.xml'

Second, create blt/build.xml with said overrides for the setup:update and setup:drupal:install targets (Note: The things I added or changed in these targets are marked by a comment line with Addition):

See this gist: https://gist.github.com/geerlingguy/1499e9e260652447c8b5a936b95440fa

The setup:update customized target basically swaps out config-import --partial for config-split-import --split=[environment-here].

The setup:drupal:install customized target just adds in one line to pass the --config-dir option to Drush, so fresh site installs will handle existing UUIDs properly (this makes it so multisite installs or CI installs still work even with full exported CMI data).

[geerlingguy]

Note that adding the <option name="config-dir">../config/default</option> line to the site install task might actually be an improvement that benefits anyone using BLT, not just those using config split or core CMI with a full export alone. I haven't tested if that option still works fine with a site using Features and/or --partial, but I think it should.

[geerlingguy]

Also a note about Config Split setup—doing something like this requires you to configure a Split for each of your environments, using the environment's machine name as the machine name of the split. So Local = local, Dev = dev, Stage = stage, RA = ra, Prod = prod, and CI = ci.

[geerlingguy]

Also, here's the extent of the documentation I provided our devs to use Configuration Split when working on tickets:

## Configuration Management

After making changes locally, you can export all the configuration changes to the codebase using the command:

    drush @projectname.local csex --split=local

This uses the [Configuration Split](https://www.drupal.org/project/config_split) module to ensure blacklisted configuration that should only apply in the local environment is not stored in the global site configuration directory.

[geerlingguy]

Also, if using Config Split, there's no need to set up a ton of arrays of modules to enable and disable in different environments, since it's all managed in your site's configuration. For our project, we changed the defaults to:

modules:
  local:
    enable: {  }
    uninstall: {  }
  ci:
    enable: {  }
    uninstall: {  }
  dev:
    enable: {  }
    uninstall: {  }
  test:
    enable: {  }
    uninstall: {  }
  prod:
    enable: {  }
    uninstall: {  }
  deploy:
    enable: {  }
    uninstall: {  }

[stooit]

We ended up using this exact same approach (full import + config split) and agree it feels like a sane default for BLT going forwards. Not sure how it'd go on projects using --partial imports though, might cause some interesting issues.

[swichers]

You've got a little extra bit in the config there that is site-specific I believe

      <!-- Addition: Configure admins on non-prod environments. -->
      <if>
        <not><equals arg1="${environment}" arg2="prod" /></not>
        <then>
          <drush command="npadmin" assume="yes" alias="${drush.alias}"/>
        </then>
      </if>

[geerlingguy]

@swichers - Oops, you're right. I've removed that portion. (It was there to run a command to make certain unprivileged users on prod admins in other environments (see Adding a role to a user programmatically in Drupal 8)

[grasmash]

Relates to #854

[geerlingguy]

FYI, I just posted a blog post that goes through the process in detail (I just tested it from scratch on my Acquia Cloud employee site to verify it all works the way I thought it would...): Adding Configuration Split to a Drupal site using BLT and Acquia Cloud

[geerlingguy]

I'm testing the latest version of BLT right now... I'll document the project tweaks required to make use of this when I have something working on my test site.

[geerlingguy]

Configuring a site for Config Split

In your blt/project.yml, make sure you define cm.strategy:

cm:
  strategy: config-split
  core:
    path: ${repo.root}/config
    key: sync
    deploy-key: vcs
    dirs:
      sync:
        path: ${cm.core.path}/default

If you had a custom build.xml override task for setup:update, you can delete that, since BLT ships its own correct task to run the config import.

Also, if you were on Config Split beta4, and had configured splits in your own config.settings.php in your sites/default/settings/ folder, you can nuke that (but compare it to the new one supplied by BLT in the vendor/blt/settings directory—you may need to make additional tweaks).

Test vs. Stage for Acquia Cloud Stage (test) environment

If you had a test config_split set up before (to match the Acquia Cloud test environment—which is labeled as 'Stage'), then you need to make the following changes:

1. On your production site (where Config Split is already installed), add a new 'Stage' split (machine name stage).
2. Copy the prod database back to local (drush sql-sync @project.prod @project.local), and update the config splits in the config store to include this new split.
3. Copy config_split.config_split.test.yml to config_split.config_split.stage.yml (leaving the old test split intact).
4. COPY the contents of the test split directory config/test to config/stage. Leave config/test intact for now.
5. After code has been pushed to prod, you can delete the test split, pull back the database, and remove the files and directory supporting the old test split.

[grasmash]

Closing issue. Please open new issue for any specific changes that need to be made.