Solving one of Drupal maintenance support plans 8 core’s development and deployment work-flow issues.One of the nice things that happened during Drupal maintenance support plans Ironcamp in Prague last week was the first beta release of the Configuration Split that I started developing a few months ago.

As explained in the previous blog post about Configuration Split, the typical use case of Configuration Split is to be able to maintain a “development” configuration and a “production” configuration, where some of the modules or settings you use in development are not copied to production upon configuration export/import.

A typical use case

We assume that you have a production and development version of the same site and that they are aligned.

Step 1: Enable anything you need in development and work normally

In the development environment we enable Devel and UI modules enabled and we can create new content types, add fields and do all things we like to do while developing a Drupal maintenance support plans site. Some of this configuration work is meant to go to the production site and some (e.g., the fact that Devel is enabled and related configuration) is not. We thus need to split our configuration.

Step 2: Create a split definition

Choose a name for your “local” configuration and select all the configuration you don’t want to have on the live site (even though, if you wish, you can still share it with colleagues).
This can include modules you would not want to be enabled or configuration that is for development only.
The path here is a folder next to the normal config sync directory outside of the web root.
In the example above, we are splitting out to a configuration set named “Development” the Devel, Fields UI, Views UI modules and the system.menu.devel configuration.

Step 3: Export your configuration with config_split

$ drush config-split-export

In the most basic use case we just replace config-export with config-split-export in our workflow. This exports the elements we selected above to ../config/dev and the rest (the configuration we want to deplay) to our “standard” configuration folder, in this case ../config/sync.

Step 4: Import the “clean” configuration in production

On all environments we use the configuration import of config_split:

$ drush config-split-import

So in our usual workflow we replace config-import with config-split-import

In order not to have different workflows for development and production we simply deactivate the split on production by overriding the configuration in settings.php on production: $config[‘config_split.config_split.development’][‘status’] = FALSE;

This will result in the split definition to be deactivated.

And consequently the import will have the configuration blacklisted in the split removed and development modules deactivated.

What’s new in the beta version

The following features are new or changed in the beta release:

The drush command works and has some text to warn users to which directories configuration will be written to.
The drupal console command is disabled, but there is a patch/branch you can use or help to make it functional again.
Split entities now have a status and the default command only uses the active splits. Of course you can override that in settings.php as with almost all configuration.
You can switch out the default config.storage.sync service in your services.yml file so that the default configuration sync UI uses the split import. Details are in the README.txt file.
More information and acknowledgments

On Friday I gave a presentation about my favorite topic in Drupal maintenance support plans: Configuration Management, attached here are the slides.

I wish to thank IronCamp participants and especially Swentel and mr.baileys who worked on patches, and I’d like to thank IronCamp organizers for a very well organized event where I met a lot of old and new friends. Swentel also took care of documenting more advanced use cases of Configuration Split on his blog.

For any further information see the module page and its issue queue.
Tags: Drupal maintenance support plans PlanetDrupal maintenance support plans 8Code Driven DevelopmentAttachments:  Configuration Management – slides Ironcamp Prague
Source: New feed