Command deploy:export-remote-config #33
Conversation
There was a problem hiding this comment.
I think this does a little too much or not enough... depending on how you look at it.
If your code is updated on your local, then you have to be careful that when you export that you don't blow away the changes that were implemented by it.
When exporting configuration, we really should treat it like a hotfix. Typically this means that you need to find out what code is deployed to production... pull that down.... pull in your database, and then export the configuration. Clearly if you do this, there would be no need for drush updb as your production and local code would match. After the export, of config, you make a commit and MERGE it back into master. If master is ahead of Production, and it includes module/core upgrades that include configuration changes via update hooks, this becomes more complicated... You have to rerun the upgrades for the new configuration.
If you have new features you are merging in at the same time as a module upgrade it becomes even more complicated...
So I guess the question I have to you is do we try to work that into this tool, or into workflow. I think it would be easier as workflow.
| } | ||
| $tasks->addTask($this->taskExec('fire local:get-db')); | ||
| $tasks->addTask($this->taskExec('fire local:import-db')); | ||
| $tasks->addTask($this->taskExec('fire drush updb -- -y')); |
There was a problem hiding this comment.
Running drush updb is not necessary here. If you are exporting configuration, you are likely trying to get configuration into the master branch. I suspect that you need to remove both drush updb and drush cr. If the plan is to "upgrade" the configuration usin gthe latest code, this this also doesn't do a great job because what ever branch you are on is going to have it's configuration blown away.
There was a problem hiding this comment.
No description provided.