RMH Config

by

Shibin Das

 

www.drupal.org/u/d34dman

 

s.das.ext@rmh-media.com

What

Configuration Manager

for running

multiple sites from same codebase

Scenario

Multiple sites are run from same codebase (think Drupal multisite), with few variations present between each sites.

A Site is

  • Code (in git)
  • Config (in git)
  • Database
  • Files
  • Server and its configurations

Topic

Config (in git)

Reference

  1. Configuration API
  2. Configuration Override system

Current "Multiple sites"
Config Setup

The Problem (top few)

  • Lack of overview : No information of what is the difference between each site
  • Manual Error: Prone to manual error as the number of sites increases, config import and export can be tricky.
  • Isolated config : Each site becomes an "island" over time. 
  • Increased maintenance : Import and export config to each site has to be done after fetching the relevant database.
  • Exponential complexity : Depending on how the features are shared, re-used, absent between each sites, the complexity becomes a nightmare to maintain.

What if we use
config_split?

It gets complicated...

Re-visiting Drupal

config management

Overriding config

via

settings.php

Using this strategy we can setup instance specific values via environment variables.

Should we use

settings.php

to manage deviations?

maybe... but NO

rmh_config

rmh_config

  • It does what we can do via settings.php but through a module
  • It uses yaml files to store configuration
  • Supports hierarchy
  • Uses a single variable stored in Drupal state to determine active configuration
  • Has an overview page for active overrides

Sample file structure

Solving problems

Lack of overview -> Awesome overview

Solving problems

Manual Error -> Fewer

  • No need for fetching database specific to site for which the feature is developed
  • No need to remember site-specific config import and export commands.

NOTE: There is an added complexity of copying the difference in configuration manually. However this is easier to code review and test.

Solving Problems

​Isolated config -> Identical config

Solved by using same config folder for all sites.

Solving Problems

​Increased maintenance -> Saves time

As a rule of thumb, all features are preset on Blueprint (default site).


So development always happen in Blueprint environment. This means,

  • Fixes need not be back-ported to other sites
  • Developer need not export config to all sites
  • No "I forgot to export config to that one site" problem, And hence need for lesser deployments :)

Solving Problems

Exponential complexity -> Manageable

RMH Config supports,

  • Hierarchy and inheritance
  • Switching active configuration without deployment
  • Hardly any penalty to introduce extra configuration
  • Supports custom `variable_get` implementation, which gives you the setting applicable for current active configuration

Demo Time

Questions

Made with Slides.com