I'm a newbie to Backdrop and I am wondering if there is currently a best practice (or suggestion) on how to work with Backdrop/Pantheon in regards to moving configuration from local -> dev -> test -> live?
I found a document on github, Documentation of Configuration Management, discussing methods of working with configuration but the last comment in that document was from May, 2017. I'm wondering if there has been any movement or lessons learned since then.
Since I am starting out with this I wish to try to develop as few a number of bad habits (which is to easy to do when starting out or reinventing the wheel).
Comments
Hi @Adrianm6254,
I have several sites on Pantheon, and I manage them in two different ways.
For simpler sites I don't keep config in version control.
This is the way backdrop works "out of the box" so I wanted to be sure it would work on Pantheon, so I tried a few sites this way. Though I was initially terrified about not tracking changes these files (and in some cases I started versioning them separately - outside of the Pantheon workflow) I eventually gained confidence in how to do it:
When I'm done making config changes on my local site, I use the config export UI to export the changes. When I'm positive that I only changed a single config file, I export that one file -- like changing a view, for example. But most of the time I make a whole bunch of changes over a day or so, then export all the config.
Then I use the Backdrop Config import UI to import it on the pantheon dev instance, and check that my code changes work as expected with the config.
If that checks out, I use the Pantheon dashboard to deploy the code, and the Backdrop Config import UI to import the config on the pantheon test instance.
If that also checks out, I use the Pantheon dashboard to deploy the code, and the Backdrop Config import UI to import the config on the pantheon live instance.
Then, when I'm ready for my next round of changes, I start by using the Backdrop Config export UI exporting all the config from my pantheon live instance, and importing that (along with a fresh DB) to my local site.
For more complex sites I version only the staging directory.
For sites where I want my config in version control (all projects with more than one developer, for example) I commit the staging config directory. I do this by moving it out of the files directory, and updating settings.php to point at its new location. I usually put it somewhere obscure AND hash the folder name (AND include a .htaccess file if you can). On Pantheon you can only version what's in the document root - meaning these files will be publicly available, so I like to make them hard to find.
When I'm done making config changes on my local site, I manually copy all config files from active to staging. Then I do a `git status` to see what config has been changed. I review each file that's changed, commit what I want to deploy, and checkout things like system.core.json so I don't accidentally disable caching on Pantheon. When all my changes are committed, I push.
Then I use the Config sync UI on the pantheon dev instance to get all my config from staging to active, and check that my code changes work as expected with the config.
If that checks out, I use the Pantheon dashboard to deploy the code (which contains the staging directory), and I use the Backdrop Config sync UI to import the config on the pantheon test instance.
If that also checks out, I use the Pantheon dashboard to deploy the code (which contains the staging directory), and I use the Backdrop Config sync UI to import the config on the pantheon live instance.
Then, when I'm ready for my next round of changes, I start by using the Backdrop Config export UI from my pantheon live instance. I unzip those files, and commit them all to my staging directory on my local site.
If I import a fresh DB from live, I'll also delete what's in my local active config directory, and replace it with those fresh config files (the ones that are also in staging).