Screenshot of configuration management page

Backdrop CMS Config Management

Posted on: Wednesday, August 7, 2019
Posted by: Tim Erickson

On api.backdropcms.org, there is a discussion of the three most widely discussed processes for configuration management with Backdrop CMS. 

  • The figure 8 method
  • Versioned staging directory
  • Versioned extra directory

Triplo is currently working to settle on a config management workflow that is suitable for our multi-developer remote team workflow. Right now, we're leaning towards a variation of the versioned staging directory method. Basically, it's the same as that method, but simply renaming the staging directory to versioned. 

It works like this:

  1. Every project has two config directories
    1. Active (NOT in GIT)
    2. Versioned (in GIT)
  2. The settings.php file for each site is configured to recognize this versioned directory to function as the staging directory for this site. 

    $config_directories['active'] = '../config/active';
    $config_directories['staging'] = '../config/versioned';
     

  3. Every time a developer wants to import config files into their local, dev, or production environment they
    • Do 'git status' to make sure that there are no local changes (in whichever environment they are about to update) to config that they need to capture
    • Check the config files into the versioned directory
    • Watch for any conflicts in GIT and resolve them
    • Run the files through 'admin/config/development/configuration/sync' in the site (the change will be copied into the active directory). 

Most of the time, we need to assume that we are generating content as far upstream as possible - or assume that we will need to copy and paste it into the upstream environment. (IN RARE CASES - If we are confident that we are the only one working on the project, we can copy the database upstream. But, if we plan to do this we MUST make sure that we have the latest database changes before we start and that no one else is making changes while we work. This is always a bit risky). 

Practically, (as an example) this means that if I am developing a new feature with a new content type and generating some real content for theming/development purposes, I have two choices. 

  1. Push Pull Push
    1. Create the content type locally.
    2. Push the content type upstream (DEV) and generate some content on DEV. 
    3. Pull the database (with my new content) back locally for my theming.
    4. Push the CSS/CODE changes upstream (DEV) 
  2. Pull Push
    1. Simply configure the content type and the content on DEV site.
    2. Pull the config AND database locally and commit the config changes to versioned directory. Then do my theming/development locally. 
    3. Push the theme/css back to DEV (and if necessary config changes).

In either scenario any locally generated content should be cut and pasted or recreated in DEV environment. 

We may need to experiment with the process, but in theory we need to keep the following things in mind. 

  1. The active config files should never be in GIT.
  2. We should never be copying the database upstream. Never copy database from LOCAL to DEV or from DEV to PROD
    (exceptions are made carefully and at great risk). 
  3. Always create content as far upstream as possible or be prepared to cut and paste it.