This is an idea from @populist and @davidstrauss based on how the config directory is being managed for on the Pantheon platform.
- Drush works nicely with this approach. Read more about how if you use Drush.
- Bee also works nicely with this approach. There are Bee versions of the Drush commands used with this approach.
Configuration directory set-up
config/
config/active
config/staging <-- track via Git
- Move
configoutside of files (and preferably outside the docroot) - Update settings.php to point at the new locations of
active&staging
A good arrangement for your repositories (both local and production) is
repo <-- track via Git
config/
config/active <-- untracked, e.g., Git ignore
config/staging
webroot <-- Backdrop distribution files (except config) go in here
core
...
files <-- Untracked directory or symlink to directory outside of docroot
settings.php
settings.local.php <-- Untracked, e.g., Git ignore
Additional set up
- In
settings.php, uncomment the line
$config['system.core']['config_sync_clear_staging'] = 0;
This will ensure that staging is not cleared after a configuration sync.
Local 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: Replace the contents of the
stagingdirectory with the contents of theactivedirectory, by one of:- Manually delete all files in the
stagingdirectory. - Manually copy the all the files from the
activedirectory into thestagingdirectory.
OR
Run
drush bcexon the local system.OR
Run
bee bcexon the local system.- Manually delete all files in the
local:
git add&git commitall files instaging.- local:
git pushto get all files into the Git repository. - production:
git pullto pull all config changes intostagingon the production server. production: Import from
staging, via one of:Run the config importer (via Backdrop UI at
admin/config/development/configuration/sync).OR
Run
drush bcimon the production system.OR
Run
bee bcimon the production system.
Syncing local to prod - moving downstream
production: Replace the contents of the
stagingdirectory with the contents of theactivedirectory, by either:- Manually delete all files in the
stagingdirectory. - Manually copy the all the files from the
activedirectory into thestagingdirectory.
OR
Run
drush bcexon the production system.OR
Run
bee bcexon the production system.- Manually delete all files in the
production:
git add&git commitall files instaging.- production:
git pushto get all files into the Git repository. - local:
git pullto pull all config changes intostagingon the local system. local: Import from staging, via one of:
Run the config importer (via Backdrop UI at
admin/config/development/configuration/sync).OR
Run
drush bcimon the local system.OR
Run
bee bcimon the local system.
Upsides:
- No extra directories needed.
- No renaming of directories required.
activeandstagingdirectories behave the same for both local and production.
Downsides:
- Manual copying of directories required for every config deployment (although
drush bcexsimplifies this process). - Accidental reverts are possible: If there was ever a config change made to any site that was not copied out of the
activedirectory and committed in thestagingdirectory, the next time the config importer is run (via Backdrop UI) that change will be lost.
Before starting the process of deployment to production from the local machine, since you will be replacing the contents of the current staging directory on your local machine, it is a good idea to check two things on the local machine:
- Check the config importer at
/admin/config/development/configuration/syncto see current differences betweenstagingandactive; - Run
git statusto see any currently uncommitted changes tostaging.
Any differences you see in either place should be due to the config changes you intend to deploy; if you see any difference that you don't recognize, then it's worth looking into further before proceeding.