Drupal 10/11 : Gérer les mises à jour avec Drush sans bloquer le déploiement

Partager sur

Introduction

Lors du déploiement d’une mise à jour Drupal, il est courant d’utiliser les commandes suivantes :

set -e
drush updb -y
drush cim -y
drush cr

Cependant, certaines mises à jour nécessitent des services qui ne sont pas encore disponibles, ce qui peut entraîner des erreurs SQL et bloquer le déploiement. Dans cet article, découvrez comment adapter votre script pour éviter ces blocages, avec un cas concret : l’update Drupal system_update_11201 (ajout de la colonne "alias" dans la table "router").

Note: "drush deploy" a le même problème : https://www.drush.org/13.x/deploycommand/ 

Le problème : une erreur SQL bloquante

Lors de l’exécution de "drush cr" avant "drush updb -y", vous pouvez rencontrer l’erreur suivante :

[error] Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'alias' in 'field list': INSERT INTO "router" ("name", "route", "alias") VALUES (:db_insert_placeholder_0, ...

Cette erreur est normale : la colonne "alias" n’existe pas encore, car elle est créée par l’update system_update_11201. Si le script s’arrête à ce stade, le déploiement est bloqué.

La solution : autoriser l’échec du premier "drush cr"

Pour contourner ce problème, modifiez votre script de déploiement comme suit :

#!/bin/bash
# Désactiver l'arrêt sur erreur pour le premier "drush cr"
set +e
drush cr
set -e
# Exécuter les commandes de mise à jour drush
drush updb -y
drush cim -y
drush cr

• "set +e" : Désactive l’arrêt du script en cas d’erreur pour la commande suivante.
• "drush cr" : Tente de vider le cache, mais peut échouer sans bloquer le script.
• "set -e" : Réactive l’arrêt sur erreur pour les commandes suivantes.

Pourquoi cette approche ?

• Flexibilité : Le script continue même si le premier "drush cr" échoue.
• Robustesse : Les mises à jour ("updb") et l’import de configuration ("cim") s’exécutent normalement.
• Finalisation propre : Le dernier "drush cr" garantit que le cache est vidé après la mise à jour.

Cas d’usage : Update Drupal N°11201

L’update system_update_11201 ajoute la colonne "alias" dans la table "router". Sans cette adaptation, le déploiement échouerait systématiquement avant même d’appliquer la mise à jour.

Bonnes pratiques DevOps pour Drupal

1. Testez en local : Simulez le scénario avant de déployer en production.
2. Surveillez les logs : Utilisez "drush ws" pour vérifier les erreurs.
3. Automatisez : Intégrez ce script dans vos pipelines CI/CD (GitLab CI, GitHub Actions, etc.).

Conclusion

En adaptant votre script de déploiement, vous évitez les blocages liés aux dépendances entre les services et les mises à jour SQL. Cette astuce est particulièrement utile pour les mises à jour critiques comme l’update system_update_11201.