Development without pulling production DB to your local machine

Question

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?

Answer 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.

Answer 2

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. :)