Dropsolid: Drupal maintenance support plans 8 config management (part 2)

07 Feb

Config management in Drupal maintenance support plans 8: the set-up (part 2/3)

Niels A

Drupal maintenance support plans 8
Drupal maintenance support plans

In the first part of this three-piece blogpost, we explained the existing options for managing your configuration across environments. We also shed some light on grey areas between configuration and content. In this part, I’ll be showing you how to set it all up.
 

Back to part 1     Skip to part 3

 

Setting up configuration management

Configuring the splits

Start by installing the config split module, available here.

We like to keep our splits simple and clear. Currently, have four splits:

Blacklist: A split that doesn’t have a folder configured, so it doesn’t end up in our Git repository. This split usually has the same configuration as the config ignore module. The reason why will be explained in the part about config ignore.
Dev: A split that is used for our development environment-only configuration
Staging: A split that is used for our staging environment-only configuration
Live: A split that is used for our live environment only-configuration
Our blacklist configuration looks like this:
If you don’t fill in the folder name, the Config Split module will export the config to a table in the database. That way, it doesn’t pollute your Git commits. For our other splits we use a folder outside our docroot for security reasons – e.g. for a dev split: ../config/splits/dev

Another important value here is the weight of the split. This weight will be used when multiple splits are active. The weight defines the order in which conflicting settings from splits get resolved. I will explain this in the part about the settings files, a little further down this post.

For the active checkbox you can choose whatever you want, because we’ll overwrite it later using the settings.php file. 

We’ve only been actively using the complete split configuration because it is pretty straightforward in how it handles your configuration. The additional configuration is handy because you can use wildcards. In the case of our blacklist, for example, we wanted to exclude everything from webform by using “webform.*”

We haven’t come across any use cases where we needed the conditional split, because we have a split active on every environment or the environment just needs the configuration from the sync folder.
If you were to use it, the following use case would be perfect for it. For instance, you have some configuration you need on all environments but you want it to be different on one environment. In our example we want a different email to be set in the reroute e-mail settings on the staging environment. You would change it in the interface and then do a “drush csex staging” to export it to the config split staging folder. This will allow the config file to be present in the sync folder and in the split folder. 

Configuring ignore

 

First, install the config ignore module.

The important thing to know about this module is that it only ignores config on import. This is why we have currently set up a blacklist split. A new module called Config Export Ignore (available here) is also at your disposal, but we haven’t used it in our workflow because it doesn’t have a stable release yet. We will look into this in the future though, because the “blacklist” split feels like a hack in some way.

Our default config ignore settings look like this:
As you can see, you can also add some special rules to your ignore settings. The only downside is that config split does not support these special rules. You’ll have to tweak your blacklist split a little bit and make your peace with the added files in your repo, until we find or create a solution for this. 

The settings files

To get this working across all environments, you need to have a settings file that is aware of its environment. This can be done using an environment variable that you check or use different files that get deployed based on the environment. There you set which config should be active on which environment. Sometimes it happens that you need multiple splits to be active on a single environment. You need to consider these splits as layers of config that you want to manage across environments. 

Our settings.php file on our development environment is identical to our local environment. It contains the following lines:

// Set your config directory outside of your docroot for security
$config_directories[CONFIG_SYNC_DIRECTORY] = ‘../config/sync’;

// Configure config split directory
$config[‘config_split.config_split.blacklist’][‘status’] = TRUE;
$config[‘config_split.config_split.dev’][‘status’] = TRUE;
$config[‘config_split.config_split.staging’][‘status’] = TRUE;
$config[‘config_split.config_split.live’][‘status’] = FALSE;

You might think that setting the staging split to true on the dev/local environment might be a mistake, but this is very intentional. As we are mostly using the complete split settings, this means that a config file can only be in one place. So we leverage the weight of the splits to also have certain staging config on our dev/local environment active. 
For instance, if we only want the reroute e-mail module to be active on local/dev/staging environments, we would add it to the complete split settings of the staging split.

Our settings.php for our staging environment will look as follows:

// Set your config directory outside of your docroot for security
$config_directories[CONFIG_SYNC_DIRECTORY] = ‘../config/sync’;

// Configure config split directory
$config[‘config_split.config_split.blacklist’][‘status’] = TRUE;
$config[‘config_split.config_split.dev’][‘status’] = FALSE;
$config[‘config_split.config_split.staging’][‘status’] = TRUE;
$config[‘config_split.config_split.live’][‘status’] = FALSE;

Consequently, the settings.php for our live environment looks like this:

// Set your config directory outside of your docroot for security
$config_directories[CONFIG_SYNC_DIRECTORY] = ‘../config/sync’;

// Configure config split directory
$config[‘config_split.config_split.blacklist’][‘status’] = TRUE;
$config[‘config_split.config_split.dev’][‘status’] = FALSE;
$config[‘config_split.config_split.staging’][‘status’] = FALSE;
$config[‘config_split.config_split.live’][‘status’] = TRUE;

Our Rocketship install profile (blog post in Dutch) has all these things preconfigured, which enables us to create more value for our clients.

Deploying changes

When you want to deploy changes to your environments, the only thing you need to do is make sure the config files that you’ve exported using ‘drush config-export’ are on the environment you want to deploy. Using a versioning system like Git can greatly help you manage those files across environments. 

When you are ready to deploy your changes, just run the “drush config-import” command on that environment. Settings up drush aliases can save you a lot of time when you want to execute drush commands on remote environments. Read more about them here on this Drupal maintenance support plans.org page.

Once you have this in place, you’ll be able to easily manage your configuration across environments. Go check out part 3 if you want to explore a couple of real world use cases and issues we’ve encountered.
 

Revisit part 1     Read part 3


Source: New feed

This article was republished from its original source.
Call Us: 1(800)730-2416

Pixeldust is a 20-year-old web development agency specializing in Drupal and WordPress and working with clients all over the country. With our best in class capabilities, we work with small businesses and fortune 500 companies alike. Give us a call at 1(800)730-2416 and let’s talk about your project.

FREE Drupal SEO Audit

Test your site below to see which issues need to be fixed. We will fix them and optimize your Drupal site 100% for Google and Bing. (Allow 30-60 seconds to gather data.)

Powered by

Dropsolid: Drupal maintenance support plans 8 config management (part 2)

On-Site Drupal SEO Master Setup

We make sure your site is 100% optimized (and stays that way) for the best SEO results.

With Pixeldust On-site (or On-page) SEO we make changes to your site’s structure and performance to make it easier for search engines to see and understand your site’s content. Search engines use algorithms to rank sites by degrees of relevance. Our on-site optimization ensures your site is configured to provide information in a way that meets Google and Bing standards for optimal indexing.

This service includes:

  • Pathauto install and configuration for SEO-friendly URLs.
  • Meta Tags install and configuration with dynamic tokens for meta titles and descriptions for all content types.
  • Install and fix all issues on the SEO checklist module.
  • Install and configure XML sitemap module and submit sitemaps.
  • Install and configure Google Analytics Module.
  • Install and configure Yoast.
  • Install and configure the Advanced Aggregation module to improve performance by minifying and merging CSS and JS.
  • Install and configure Schema.org Metatag.
  • Configure robots.txt.
  • Google Search Console setup snd configuration.
  • Find & Fix H1 tags.
  • Find and fix duplicate/missing meta descriptions.
  • Find and fix duplicate title tags.
  • Improve title, meta tags, and site descriptions.
  • Optimize images for better search engine optimization. Automate where possible.
  • Find and fix the missing alt and title tag for all images. Automate where possible.
  • The project takes 1 week to complete.