What order should the following drush commands be ran?
Also, I see entity-updates fail a lot due to field_delete_data* tables existing. How can I delete them as part of my automated deployment?
hook_update_N()runs first to provide entity updates or delete fields (which can't be done via
cim) or to disable modules programmatically prior to getting the updated config imported. This prevents
cimrunning into errors due to missing config (not knowing for example that a module will be disabled via
core.extension.ymlin the same run).
cimto import the remaining config.
As mentioned in the comments
entup is better to be used only during local development and otherwise should be covered by updates provided via
drush entity-updatesis a developer tool. If you change entity/field definitions in your custom module you can quickly apply this.
In production this should not happen. If you update a module between official releases, then the update code in the module should handle this.
Here is the entire routine I'm happiest with (note: running
cr in the beginning and after config import may prevent subsequent errors):
git pull composer install --no-dev drush cache:rebuild drush -y state:set system.maintenance_mode 1 drush -y updatedb drush -y config:import drush cache:rebuild drush -y core:cron drush -y state:set system.maintenance_mode 0 drush cache:rebuild
This also means to run two releases if you want to remove a contrib module completely. First release to disable the module. Second release to have it removed by Composer.
To make real consecutive releases possible you might want to pass the current release's commit SHA1 to the deployment script and then replace
git pull with a more exact routine (where
$1 is the SHA1):
# If not empty 1st argument passed to the script, do: if [ -n "$1" ]; then git reset --hard "$1" else git pull fi
Otherwise the consecutiveness can not be guaranteed when you push two new releases at once or within a short period. As then the first release's triggered
git pull will simply pull the latest changes (from the second release), where instead it should pull only the changes included in the first release. See the full sample repo
Credit for this
git snippet goes to CircleCI. This is how they are doing it in their containers.