Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
geerlingguy opened this issue Jan 11, 2017 · 12 comments
Closed
Assignees
Labels
Enhancement A feature or feature request

Comments

@geerlingguy
Copy link
Contributor

geerlingguy commented Jan 11, 2017

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link

stooit commented Jan 11, 2017

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
Copy link
Contributor

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
Copy link
Contributor Author

geerlingguy commented Jan 12, 2017

@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
Copy link
Contributor

Relates to #854

@geerlingguy
Copy link
Contributor Author

geerlingguy commented Feb 15, 2017

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

@grasmash grasmash added the Enhancement A feature or feature request label Feb 15, 2017
@grasmash grasmash self-assigned this Mar 20, 2017
@grasmash grasmash changed the title Support Config Split for environment-specific Core CMI Fixes #1138: Support Config Split for environment-specific Core CMI Mar 20, 2017
@geerlingguy
Copy link
Contributor Author

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
Copy link
Contributor Author

geerlingguy commented Mar 21, 2017

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
Copy link
Contributor

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

@grasmash grasmash removed the ready label Mar 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement A feature or feature request
Projects
None yet
Development

No branches or pull requests

4 participants