0

When you push configuration to production, any configuration that has changed in production that has not been exported into code will either be reset to the values in code or be wiped out entirely if they never existed in code. One out of many examples is changing the site name. If that change didn't go into code (i.e. if a content admin changed it, not a developer), the next deploy would reset that change.

Now the solution we have in place is to pull the production DB down and export the configuration against production code. Any differences appearing in the export are configs that have changed on production since last deploy. It's a process that you can easily wrap your head around (prod config - deployed config = changed config -> you check this in) and works pretty well so far.

But there are issues with this approach, one in particular is pulling the production database down. The DB may be huge, well into the hundred megabytes. It may contain sensitive info you don't want on your machines. Or it can only be retrieved indirectly (e.g. last night's cron job) and could already be stale by the time you work on it.

I know D8 config management is not perfect, and some things can't be avoided due to the current design of things. But I still would like to ask:

  • Is there a better way to do the process of resolving configs on deploy?
  • Is there any way to do this without pulling down the production database down?
  • Is there a Drupal/Drush/third-party module feature that already does what I am describing?
  • Is this more of a content workflow issue? i.e. never let content admins touch config?
  • 1
    Ideally you'd want your content editors to not fiddle with anything that goes into the config but its not always possible. You could try this module that allows you to ignore certain items on config import/export drupal.org/project/config_ignore That might work for your site name example you mentioned but wouldn't catch everything like if block positions get changed – Leigh Nov 1 '18 at 15:21
  • Doesn't really answer your specific question, but you can (and should) sanitize the database before pulling it down. There's a drush method to do this about implementing SanitizePluginInterface (not really documented well imho compared to the hook in drush 7). – mradcliffe Nov 2 '18 at 2:14
  • @mradcliffe – Do you have a pointer what command that would be? I think I need exactly that right now. – leymannx Nov 2 '18 at 6:40
  • 1
    The command is sql:sanitize or sql-sanitize in older versions, @leymannx. It looks like I've also written my own custom command when I absolutely didn't want the default sanitization routine to run, which basically invokes a bunch of custom drush_sql_register_post_sync_op commands to truncate or delete from field data/revision and entity tables selectively. – mradcliffe Nov 2 '18 at 14:41
1

Install Config Ignore and configure it to ignore those config objects from which you think they are going to be changed in production.

Ever experienced that your site's configuration was overridden, by the configuration on the filesystem, when doing a drush cim?

Not anymore!

This module is a tool to let you keep the configuration you want, in place.

Lets say that you do would like the system.site configuration (which contains that sites name, slogan, email, etc) to remain untouched, on your live site, no matter what the configuration, in the config folder, says.

Or maybe you are getting tired of having the devel.settings changed every time you import configuration?

Then this module is what you are looking for.

0

We solve this by using the Features module. It's a bit of a pain to set up with a large site but worth it. Basically, it lets you take the hundreds of config yml file and organize them into smaller logical chunks and then manage what changed.

Our organization is generally, a core feature with field storage (so fields can be used across types), general defaults and settings (e.g. translation settings, image styles, vocabs, menu, text formats, and the like).

Then a feature for each entity bundles (e.g. node types, paragraph types, eck bundles, and the like) These generally have the field instances, entity entry/display forms info, translation settings, local overrides. E.g. use the Feature search for node.type or paragraph.type to see what comes up.

Then we have features for general areas of the site. E.g. an "Views: Products" feature that has all the views and block instances used in the products area of the site.

We don't put every config item in features, just the ones that should be under the control of developers.

All these are checked into the code base.

When it's type to deploy, developers need to update the features with any changes / create new features and check them in. These are pushed to our dev site and the changes captured in features are pulled in. Things are verified that everything is good (or often, got back to the local dev environment and fix missing things). Once we have a good deploy, it's pushed up the chain.

On good thing about features is that it quickly lets you see the diffs between small areas of configs. We also double check on deployment to production if something doesn't look quite right. E.g. someone 'patched' a view to fix something on production but didn't update the feature. This can lead to having to do some head scratching and manual "gui merges". But we feel this is a lesser evil that lets the site admins fix problems quickly while not having too many fixes reverted by the devs. :)

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.