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
- Move
config
outside of files (and preferably outside the docroot) - 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
- local: Manually delete all files in the staging directory.
- local: Manually copy the all the files from the
active
directory into thestaging
directory. - local:
git add
&git commit
all files instaging
. - local:
git push
to get all files into the Git repository. - production:
git pull
to pull all config changes onto the production server. - production: Run the config importer (via Backdrop UI).
When you git pull
on the production server, the staging
directory is copied in its entirety. These files are now ready for import via the Backdrop UI.
Sync local to prod - moving downstream
- production: Manually delete all files in the staging directory.
- production: Manually copy the all the files from the
active
directory into thestaging
directory. - production:
git add
&git commit
all files instaging
. - production:
git push
to get all files into the Git repository. - local:
git pull
to pull all config changes onto the production server. - 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!