Documentation Level: 
Intermediate
Documentation Status: 
No known problems

The simplest way for a single developer to manage config in Git

This approach was recommended by @heyrocker after creating CMI for Drupal 8. It involves defining different active and staging directories for each environment, via the settings.php files.

Visual representation of the figure-8

This approach works best when a project has a single developer and only two copies of the site, for example, a development copy on a personal computer, and a production copy on a remote server.

Configuration directory set-up

config/ <-- track via Git
config/dev-active <-- track via Git
config/prod-active <-- track via Git

Additional set up

  1. Move config outside of files (and preferably outside the docroot).
  2. Rename config/active to something like config/prod-active.
  3. rename config/staging to something like config/dev-active.
  4. On your local site, update settings.php to point at dev-active for active, and prod-active for staging.
  5. On your production site, update settings.php to point at prod-active for active, and dev-active for staging.

Development site settings.php example:

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

Production site settings.php example:

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

Deploying to prod - moving upstream

  1. local: git add & git commit all files in config exactly as they are.
  2. local: git push to get all files into the Git repository.
  3. production: git pull to pull all config changes onto the production server.
  4. production: Run the config importer (via Backdrop UI).

When you git pull on the production server, the config files that were committed into the "active" directory on local are pulled into what is now the "staging" directory on production - (dev-active). These files are now ready for import via the Backdrop UI.

Sync local to prod - moving downstream

  1. production: git add & git commit all files in config exactly as they are.
  2. production: git push to get all files into the Git repository.
  3. local: git pull to pull all config changes onto the local copy of the site.
  4. local: Run the config importer (via Backdrop UI).

When you git pull on the local copy of the site, the config files from what was the "active" directory on production are pulled into what is now the "staging" directory on local - (prod-active). These files are now ready for import via the Backdrop UI.

Upsides:

  • No extra directories needed.
  • Once set up, you never need to think about which directory is which!
  • Commit things as they are, no manual copying of files.
  • Fewer steps to move both upstream & downstream

Downsides:

  • Git reports the (staging) directory as always "out of date" - see (1) below
  • Harder to manage with more than one copy of the website.
  • Very hard to manage with more than one developer.

(1) 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!