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?
Drupal Answers is a question and answer site for Drupal developers and administrators. It only takes a minute to sign up.Sign up to join this community
drush updatedb --no-cache-clear drush cache:rebuild drush config:import drush cache:rebuild drush deploy:hook
Database updates always come before configuration import! Support for automatic entity updates has been removed from Drupal core (change record) and
entup has been removed from Drush core. Whenever an entity type or field storage definition needs to be created, changed or deleted, it has to be done via
Here is the updated deployment routine I'm happiest with.
drush state:set system.maintenance_mode 1 drush cache:rebuild git pull composer install --no-dev drush cache:rebuild drush deploy drush state:set system.maintenance_mode 0 drush cache:rebuild
This also means you have to run two releases if you want to uninstall and remove a contrib module. First release to deploy the updated config that disables the module. Second release to deploy the updated composer.json and lock file after you removed it with 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.
The sequence of commands should be:
updatedb (which runs update hooks) config-import
You do not want to run entity-updates because it is deprecated, see https://www.drupal.org/node/3034742. Instead, rely on update hooks (hook_update_N) to properly modify any database schema or necessary configurations.
It is imperative that updatedb is the first command run that boots Drupal after code has been changed. You can see https://www.drupal.org/project/commerce/issues/3100553 for some commentary on what issues might arise when that is not done.
Here is an example deployment script that has had a lot of review and discussion behind it, but consider it a starting point. It's likely there will be adjustments you would want to make. It does assume you're deploying an artifact (notice that composer install is not run on deployment).
drush sset system.maintenance_mode TRUE # Create a restore point by taking backups of anything that is not in the code repository: database, media, cache # Checkout the code you are deploying drush updb drush cim sync -y || drush cim sync -y drush cim sync -y drush sset system.maintenance_mode FALSE drush cr
You can see https://www.bounteous.com/insights/2020/03/11/automate-drupal-deployments/ for a deeper explanation behind this. See also https://github.com/drush-ops/drush/pull/4359/ which is a PR to include a deploy command in Drush.
I mentioned the script above is a starting point, I've documented some variations that you might want to apply to that script (or any deploy script you use) that might be helpful: https://www.bounteous.com/insights/2020/03/12/automated-drupal-deployment-and-rollback-recipes/
Here is our CI script, quite the same :)
drush cr git pull composer install # drupal console enforce modules are enabled before any config is installed drupal config:import:single --directory="config/sync" --file="core.extension.yml" drush cr drush -y updb drush cr drush -y cim drush cr
the config:import:single was helpfull when diffrent developers where creating modules without requiring the correct dependencies in their .info.yml
If you need to import custom translations too make sure to run a drush cim afterwards importing as some of the lables are translated in config and some in the po files.
At moment our update job looks like this after a git pull. And make sure if you are on dev to export your changes before pulling with drush cex ;-) :
composer install --no-interaction -d /var/www/html/ drush updatedb -y drush cr -y drush cim -y drush locale:check -y #make sure to switch this to local only in settings.php in production drush locale:update -y drush locale:import de ../translations/custom-translations.de.po --type=customized --override=all -y drush locale:import de ../translations/custom_other_translations.de.po --type=customized --override=all -y drush cr -y drush cim -y drush cr -y