each upgrade come generally with some DB updates, this may change some table schema as well as some configurations..
in the deployment process, the steps I use (after upgrading using composer and push the composer files) as follow:
-
drush updb -
drush cim -
drush cr
there is also drush deploy we can use witch is doing almost the same in the same order.
so, if drush updb can change some configs, then I assume that they will be rolled-back in the next step (drush cim) witch lead to wrong configuration..
Should we only do DB updates in the deployment and look if there are config to export, then export and push them ? (in this case drush deploy is wrong!)
or these steps are correct, and in this case I want to understand how Drupal knows that those new configs are coming from an upgrade and do not override them in the next drush cim step ?
Comments
You should have already run
You should have already run any updates locally before exporting your config. So when migrating to another server, the update command first brings the DB in line with your local DB (that was already updated), then the configuration is imported into the DB that has the same base. So no, importing the configuration should not revert the update. Unless you are only migrating configuration, and not also the code base, which you should never do, as configuration depends on the codebase it was exported from.
Contact me to contract me for D7 -> D10/11 migrations.
I don't have a local db, only
I don't have a local db, only the project code (I use platform.sh as cloud hosting solution), when pushing changes, the remote environment will detect composer.lock changes and run necessary composer updates, so codebase will be updated of course, then the steps described above.
Then you have no problems, it
Then you have no problems, it is working correctly.
Contact me to contract me for D7 -> D10/11 migrations.