Documentation Level: 
Intermediate
Documentation Status: 
No known problems

This an idea from @populist and @davidstrauss based on how the config directory is being managed for on the Pantheon platform.

Configuration directory set-up

config/ 
config/active 
config/staging <-- track via Git

Additional set up

  1. Move config outside of files (and preferably outside the docroot)
  2. Update settings.php to point at the new locations of active & staging

Development site settings.php example:

/**
 * Site configuration files location.
 */
$config_directories['active'] = '../config/active';
$config_directories['staging'] = '../config/staging';

Production site settings.php example:

/**
 * Site configuration files location.
 */
$config_directories['active'] = '../config/active';
$config_directories['staging'] = '../config/staging';

Deploying to prod - moving upstream

  1. local: Manually delete all files in the staging directory.
  2. local: Manually copy the all the files from the active directory into the staging directory.
  3. local: git add & git commit all files in staging.
  4. local: git push to get all files into the Git repository.
  5. production: git pull to pull all config changes onto the production server.
  6. production: Run the config importer (via Backdrop UI).

When you git pull on the production server, the staging directory is copied in it's entirety. These files are now ready for import via the Backdrop UI.

Sync local to prod - moving downstream

  1. production: Manually delete all files in the staging directory.
  2. production: Manually copy the all the files from the active directory into the staging directory.
  3. production: git add & git commit all files in staging.
  4. production: git push to get all files into the Git repository.
  5. local: git pull to pull all config changes onto the production server.
  6. local: Run the config importer (via Backdrop UI).

Upsides:

  • No extra directories needed.
  • No renaming of directories required.
  • Drush works nicely with this approach. Read more about how if you use Drush.

Downsides:

  • Manual copying of directories required for every deployment.
  • Accidental reverts are possible (due to manual copy) - see (1) below
  • Extra steps are added to deployment (due to manual copy)
  • Git reports staging directory as always "out of date" - see (2) below

(1) ACCIDENTAL REVERTS ARE POSSIBLE: If there was ever a config change made to any site that was not manually copied out of the active directory and committed in the staging directory, the next time the config importer is run (via Backdrop UI) that change will be lost.

(2) GIT SHOWS STATUS: OUT OF DATE. Git is tracking and reporting all the deleted config files in the staging directory. Running a Git status check on any environment will show the deleted files. Developers may get used to seeing deleted files in staging, and train themselves to ignore those warnings. When a config file is actually deleted BY MISTAKE this is very likely to be overlooked!