web-dev-qa-db-fra.com

Ordre des commandes drush pour un déploiement automatisé?

Dans quel ordre les commandes drush suivantes doivent-elles être exécutées?

  • config-import
  • mis à jourb
  • mises à jour d'entité

De plus, je vois que les mises à jour d'entités échouent beaucoup en raison des tables field_delete_data * existantes. Comment puis-je les supprimer dans le cadre de mon déploiement automatisé?

8drushdeployment
5
Paul Canning

J'échangerais updb et cim.

  1. updb pour garantir que hook_update_N() s'exécute en premier pour fournir des mises à jour d'entités ou supprimer des champs (ce qui ne peut pas être fait via cim) ou pour désactiver les modules par programme avant de obtenir la configuration mise à jour importée. Cela empêche cim de se heurter à des erreurs en raison d'une configuration manquante (ne sachant pas par exemple qu'un module sera désactivé via core.extension.yml Lors de la même exécution).
  2. cim pour importer la configuration restante.

Comme mentionné dans les commentaires, il est préférable d'utiliser entup uniquement pendant le développement local et sinon, il devrait être couvert par les mises à jour fournies via hook_update_N().

drush entity-updates Est un outil de développement. Si vous modifiez les définitions d'entité/de champ dans votre module personnalisé, vous pouvez l'appliquer rapidement.

En production, cela ne devrait pas se produire. Si vous mettez à jour un module entre les versions officielles, le code de mise à jour du module doit gérer cela.

Source: Quel est le but des mises à jour d'entités drush?

Voici la routine complète dont je suis le plus satisfait (remarque: l'exécution de cr au début et après l'importation de la configuration peut empêcher les erreurs suivantes):

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

Cela signifie également d'exécuter deux versions si vous souhaitez supprimer complètement un module contrib. Première version pour désactiver le module. Deuxième version pour le faire supprimer par Composer.

Pour rendre possible de vraies versions consécutives, vous pouvez passer le commit SHA1 de la version actuelle au script de déploiement, puis remplacer git pull Par une routine plus exacte (où $1 Est le SHA1):

# If not empty 1st argument passed to the script, do:
if [ -n "$1" ]; then
  git reset --hard "$1"
else
  git pull
fi

Sinon, la consécutivité ne peut pas être garantie lorsque vous envoyez deux nouvelles versions en même temps ou dans un court laps de temps. Comme alors, la première version déclenchée git pull Tirera simplement les dernières modifications (à partir de la deuxième version), où elle ne devrait à la place extraire que les modifications incluses dans la première version. Voir le repo échantillon complet leymannx/drupal-circleci-behat .

Le crédit pour cet extrait git va à CircleCI . C'est ainsi qu'ils le font dans leurs conteneurs.

18
leymannx

La séquence de commandes doit être:

updatedb (which runs update hooks)
config-import

Vous ne souhaitez pas exécuter les mises à jour d'entités car elles sont obsolètes, voir https://www.drupal.org/node/3034742 . Utilisez plutôt des hooks de mise à jour (hook_update_N) pour modifier correctement tout schéma de base de données ou configurations nécessaires.

Il est impératif que updatedb soit la première exécution de commande qui démarre Drupal après la modification du code. Vous pouvez voir https://www.drupal.org/project/commerce/issues/310055 pour un commentaire sur les problèmes qui pourraient survenir lorsque cela n'est pas fait.

Exemple de script de déploiement

Voici un exemple de script de déploiement qui a fait l'objet de nombreuses révisions et discussions, mais considérez-le comme un point de départ. Il est probable que vous souhaitiez effectuer des ajustements. Il suppose que vous déployez un artefact (notez que composer n'est pas exécutée lors du déploiement).

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

Vous pouvez voir https://www.bounteous.com/insights/2020/03/11/automate-drupal-deployments/ pour une explication plus approfondie derrière cela. Voir aussi https://github.com/drush-ops/drush/pull/4359/ qui est un PR pour inclure une commande de déploiement dans Drush.

J'ai mentionné que le script ci-dessus est un point de départ, j'ai documenté quelques variantes que vous pourriez vouloir appliquer à ce script (ou à tout script de déploiement que vous utilisez) qui pourraient être utiles: https: //www.bounteous. com/insights/2020/03/12/automatisé-drupal-déploiement-et-rollback-recettes /

0
josephdpurcell