I have been fighting with the Magento deployment workflow and configuration properties for a while
1. It can be painful!
app:config:dump creates the
config.php files dumping all the database config in them. They then "lock" these fields in the admin
A change to
config.php files will instantly create an error 500 until it is read into the database. So put maintenance before you change things.
For one little change use the command line instead. (more later)
app:config:import first wipes all settings in the database
if a setting is not in the files, that particular option will be back to default. (whereas in #3 they are left as is)
I didn't expect that the first time!
The idea is that it is for a deployment in a stable deployment workflow where you clone everything eg deploying containers at installation
setup:upgrade will update settings from file only
Settings not in the file will be left as they are (whereas in #2 they are reset to default)
This allows you to set some settings locked in file while leaving others editable in admin.
BUT: running setup:upgrade it also clears generated files and caches, so you have to compile and deploy static again each time, not great if you just want to change a few small settings. (But in a magento workflow you can just copy the compiled and static files over from the build machine orrepository again which is quick)
UPDATE: @john-hall reports quite rightly that
setup:upgrade --keep-generated will preserve the generated files to minimise disruption
4. config:set (saves to env or config) and config:sensitive:set (saves to environment) are the least disruptive way to change things
They update both the file and the database.
They do not wipe cache, generated files or anything - as a matter of fact for some things you might have to clear config cache manually to see an effect.
It can be complicated to figure out the path and options but but it beats having to go either of the previous two ways
bin/magento --scope=store --scope-code=default config:set web/unsecure/base_url
bin/magento config:set -c msp_securitysuite_recaptcha/frontend/enabled_login 0
There is a ridiculously long list to figure out, name wise, so I do
bin/magento config:show > configlist
so i have a file i can search through.
5. anything in these files is locked in admin
You can lock easily from command line or by putting it in the file and then importing/upgrading
6. the only unlock is remove-from-file and 'setup:upgrade'
there is no way to "unlock" via bin/magento config:set that I could find. There really should be.
You have to leave it out of the files and then it will get unlocked. Note that you can then change it in admin, but you can't use config:import then
To use in a deployment/rollout system
Note: I am still not 100% there
A bit of work needs to be done on this approach because a lot of modules are sloppy and write into the config file settings which could be different from instance to instance, for example different between the dev, build and production instances. Theoretically they can mark variables in the module xml definition as "env" versus "config" or mark them as sensitive, but they don't.
1. sensitive settings go in environment variable, or env.php
these are not put into source control. I've stuck with env.php for now
2. setting that are going to be the same between all stay in config.php
This can be put in source control and copied from machine to machine.
I am using a partial config.php that leaves "open" things i want to allow changing from the admin interface so I have to use setup:upgrade not the config import. But then often this is rolled out with other changes so that would run anyway.
3. Things that are machine/environment specific go in env.php
You can move entire config sections out of config.php into env.php so that you have one env.php per machine/instance and a shared config.php
So whether something is in test mode or not, alternative email addresses etc.
This is one that will take time to decide.
I hope this helps
I have spent quite a few hours comparing, merging and producing my config.php and env.php that lock everything I want to speed up but leaves open things we want to be able to modify. It's not there yet, and just today I wiped entire sections trying to make something editable in admin again...