Support for multiple CM approaches.

[jasonharc]

I want BLT to support multiple CM approaches.

[geerlingguy]

Currently it seems there are a few widely-used approaches that people are using:

1. Core CMI (full config): Use drush cex -y to export everything and drush cim -y to import everything. Works well for single sites, has some difficulties around overrides and environment-specific modules. Things like [Configuration Split|https://www.drupal.org/project/config_split] may help here.
2. Core CMI (partial): Use drush cex -y to export everything and drush cim -y --partial to import everything, but anything you .gitignore (e.g. Contact form config, YAML/Webform config, etc.) is not imported. Drupal also doesn't automatically delete fields/content types/etc. when using --partial. Can work better than full config in multi-site scenarios too.
3. Features and Core CMI (partial): Similar to how D7 works, but with some more configuration thrown into a core CMI export, potentially. Requires more work in architecting features to be installable and not conflict with each other, and roles/permissions can't be managed (sanely) within Feature module exports. Better for multisite since features could be enabled or disabled per site more easily.

This isn't a comprehensive list, but I wanted to sum up what I've seen most often in the wild.

Using #1 means that any config changes made on prod (e.g. block changes, layout changes, contact forms, etc.) would need to be exported back to code or else they'd be overwritten on the next code deploy/config import.

Using #2 or #3 means you have to use the D7-style 'update hooks for everything' approach where you write custom code to do field/other deletions and manage any configuration that's not explicitly defined in the imported configuration.

[bkosborne]

Some thoughts from someone struggling with this as well:

From what I gather, BLT supports the second workflow approach above: exporting everything and then doing a partial config import on production. The documentation for configuration management assumes you're using a Features based workflow (unless I missed another reference somewhere?)

I'm using BLT with Acquia Cloud, which includes the BLT provided acquia cloud hook for performing post-code-deploy actions.

BLT currently hardcodes a the --partial option to drush config-import during the site install process.

I think at the very least this that should be configurable, or at least documented somehow?

I haven't quite settled on an approach for managing different configs between environments, but for now during development of a project, I'm just exporting all config from dev and importing it all into prod. The --partial flag throws me off because it leaves things around on prod that I didn't intend.

[grasmash]

@bkosborne there is now a cm.core.partial variable that can be toggled.

[grasmash]

I'm closing this in favor of the more specific #965, which would be the other config strategy supported.