Backdrop CMS configuration files and Git: The versioned staging approach

There are lots of different approaches to managing Backdrop CMS configuration files in Git, but this one is my favorite. It works great for projects with multiple developers, and it can also be easily adapted for multiple deployment environments, as on Pantheon.

This versioned staging directory strategy has been adapted from a recommendation from @populist and @davidstrauss based on how the config directory is being managed for Drupal 8/9/10 on Pantheon.

Configuration directory

config/
config/staging <-- track via Git
config/live-active <-- track via Git
config/dev-active <-- DO NOT TRACK

Additional set up

• Move config outside of files (and preferably outside the docroot)
• Update settings.php to point at the new active & staging locations (different active directories for each site instance)

Deploying to prod - moving upstream

1. local: overwrite staging directory with dev-active -- deletions too!
2. local: add, commit, push staging (via Git)
3. production: pull changes (via Git)
4. production: run config sync (via UI, drush, or bee)

Sync local from prod - moving downstream - option 1 (writable web server)

Option 1 is for a web-writable live-active config directory, and one where you have the ability to add, commit, or push via Git.

1. production: add, commit, push live-active (via Git)
2. production: overwrite staging directory with live-active -- deletions too!
3. production: add, commit, push staging (via Git)
4. local: pull changes (via Git)
5. local: run config sync (via UI, drush, or bee)

Sync local from prod - moving downstream - option 2

Option 2 is for a non-writable live-active config directory, or one where you do not have the ability to add, commit, or push via Git.

1. production: export active directory (via UI)
2. local: overwrite staging directory with export -- deletions too!
3. local: add, commit, push staging (via Git)
4. local: run config sync (via UI, drush, or bee)

Because the staging directory is always versioned and deployed, every enviornment

Note: this blog post was adapted from older documentation. It has been adapted fro experience, and updated to account for changes to Backdrop core.