3

What order should the following drush commands be ran?

  • config-import
  • updatedb
  • entity-updates

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?

  • 1
    You shouldn't delete those tables yourself unless you're absolutely sure they are not being referenced. Cron should clean them up. See my question I asked about this recently drupal.stackexchange.com/questions/253055/… – Kevin Jan 24 '18 at 16:49
  • The issue is that I cannot wait for cron to do the tidy up, as we do deployments as and when – Paul Canning Jan 24 '18 at 17:15
  • 1
    You should not delete those tables at will - review that question as to the whys. – Kevin Jan 24 '18 at 17:16
  • I've not yet encountered an issue in doing so :/ – Paul Canning Jan 24 '18 at 17:17
13

I'd swap updb and cim.

  1. updb to ensure 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 cim running into errors due to missing config (not knowing for example that a module will be disabled via core.extension.yml in the same run).
  2. cim to 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 hook_update_N().

drush entity-updates is 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.

Source: What is the purpose of drush entity-updates?


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 leymannx/drupal-circleci-behat.

Credit for this git snippet goes to CircleCI. This is how they are doing it in their containers.

  • 4
    I'm strongly against using entup in such a workflow. Modules must provide update functions for their entity type changes, entup is not reliable (there are many changes that it can't do and will fail with an exception) and should only be used when developing a not-yet-released entity type. It's something that non-cli users can not execute. – Berdir Jan 25 '18 at 19:25
  • Since the answer mentions composer: It is recommended to run composer install with autoloader optimization options such as --optimize-autoloader. – marcvangend Feb 11 '18 at 19:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.