Pipeline de mise à jour du code Drupal 11 (dev → production)

Objectif

Promouvoir le code et la configuration validés depuis l’environnement de développement vers la production avec un processus reproductible, automatisé et réversible, en s’appuyant sur Composer, Git, Drush, GitLab CI/CD et, en option, DRD.

Prérequis techniques

• Projet Drupal 11 basé sur Composer (package drupal/recommended-project).
• PHP 8.3+, base de données supportée par Drupal 11.
• Drush 13+ installé via Composer (dépendance du projet).
• Dépôt Git (GitLab) avec accès par clé SSH.
• GitLab Runner opérationnel (Docker ou shell) avec accès réseau aux serveurs.
• Accès SSH aux serveurs (staging/production), rsync disponible côté runner et serveurs.

Gestion du code et des dépendances

• Versionner le code applicatif, le composer.json et le composer.lock (pas de vendor/ ni de web/core dans Git).
• Standardiser une stratégie de branches (ex. main stable, develop intégration, branches de fonctionnalités, tags pour releases).
• Construire un artefact de déploiement en CI (composer install --no-dev --prefer-dist --optimize-autoloader) pour éviter Composer en production.

Gestion de la configuration Drupal

• Activer la synchronisation de configuration (CMI) : répertoire config/sync versionné.
• Mettre en place config_split pour séparer modules et réglages propres à dev/staging/production.
• Paramétrer des inclusions par environnement dans settings.php (settings.dev.php, settings.prod.php), variables d’environnement pour les secrets.
• Exporter la configuration depuis dev avec drush cex -y; importer en déploiement avec drush cim -y.

Aliases Drush et accès distants

• Définir des aliases dans drush/sites/*.yml pour @dev, @stage, @prod (URI, chemin docroot, utilisateur SSH, hôte).
• Vérifier l’exécution distante : drush @prod status, drush @prod cr.

Schéma de déploiement (atomic releases)

• Arborescence recommandée sur les serveurs :
  • /var/www/app/releases/ (un dossier par release horodatée)
  • /var/www/app/current (symlink vers la release active)
  • /var/www/app/shared/ (éléments partagés : sites/*/files, private/, settings.php, services.yml, caches, logs)
• Rendre le docroot en lecture seule hors répertoires de fichiers publics/privés.
• Permettre un basculement rapide de current pour rollback.

Pipeline GitLab CI/CD

Variables CI à définir

• SSH_PRIVATE_KEY (clé déploiement), PROD_HOST, PROD_USER, PROD_PATH, DRUSH_ALIAS_PROD.
• Jetons Composer privés si nécessaires (COMPOSER_AUTH).

Étapes types

• Build
  • Installer dépendances : composer install --no-dev --prefer-dist --no-interaction --optimize-autoloader.
  • Compiler front si applicable (ex. npm ci && npm run build), placer les assets dans web/.
  • Générer un artefact (archive) contenant web/, vendor/, composer.*, scripts de déploiement.
• Test
  • QA optionnelle : phpcs/phpstan/phpunit, tests fonctionnels, lint YAML/Twig.
• Deploy staging (automatique sur branche d’intégration)
  • Transférer l’artefact vers releases/ (rsync/scp), créer les symlinks vers shared/.
  • Exécuter drush @stage deploy -y (chaîne : updatedb, config:import, cache:rebuild), puis basculer le symlink current.
• Deploy production (manuel, protégé)
  • Pré-déploiement : mise en maintenance via drush @prod state:set system.maintenance_mode 1 -y si nécessaire.
  • Transfert de l’artefact, création de la release, liens partagés, bascule atomique du symlink.
  • Post-déploiement : drush @prod deploy -y, drush @prod cache:tag invalidate render si requis, désactivation maintenance.

Procédure de promotion du code

1. Sur dev
   • Mettre à jour dépendances avec Composer, développer la fonctionnalité.
   • Exécuter les mises à jour locales : drush updb -y.
   • Exporter la configuration : drush cex -y.
   • Valider et pousser les changements (composer.lock inclus), ouvrir la MR.
2. Intégration/recette
   • Fusion sur branche stable, création d’un tag/release.
   • Validation sur staging via pipeline et tests métier.
3. Production
   • Déclenchement du job protégé, déploiement de l’artefact, exécution des tâches Drush (deploy).
   • Vérifications de santé, monitoring et logs.

Option DRD (Drupal Remote Dashboard)

• Installer DRD sur un serveur d’orchestration.
• Enregistrer les sites (dev/stage/prod) avec accès SSH.
• Définir des Jobs DRD pour
  • Récupération/placement d’artefacts ou git pull sur la cible.
  • Exécution séquentielle des commandes Drush (deploy, cr, cron).
  • Planification et contrôle des fenêtres de maintenance.
• Intégrer DRD comme exécuteur dans le pipeline GitLab (webhooks ou API) si centralisation souhaitée.

Sauvegardes et rollback

• Avant déploiement production
  • Sauvegarde base : drush @prod sql:dump --gzip vers un stockage sécurisé.
  • Sauvegarde fichiers modifiables (sites/*/files).
• Conserver N releases (ex. 5 à 10) et permettre un retour rapide en repointant current vers la release précédente, suivi d’un drush @prod cr.

Permissions et sécurité

• Propriété des fichiers partagés par l’utilisateur du serveur web uniquement sur sites/*/files.
• Interdire l’écriture dans le docroot hors répertoires de fichiers.
• Désactiver modules de développement via config_split en production.
• Masquer l’accès non authentifié sur dev/staging (basic auth, IP allowlist).

Bonnes pratiques complémentaires

• Éviter la synchronisation de contenu via CMI (réservé aux configurations); utiliser migrations, scripts dédiés ou contenus de test.
• Documenter la checklist de déploiement et les critères de passage en production.
• Mettre en place des checks de santé après déploiement (HTTP 200, watchdog, New Relic/Prometheus).
• Automatiser le run drush cron post-déploiement si des tâches en dépendent.

Livrables à mettre en place

• Dépôt Git structuré avec composer.json/composer.lock, répertoire config/sync, drush/sites/*.yml.
• Fichiers settings.*.php par environnement et configuration config_split.
• GitLab Runner configuré et .gitlab-ci.yml incluant les jobs Build/Test/Package/Deploy.
• Scripts de déploiement sur le serveur (création release, symlinks, permissions, purge releases anciennes).
• Plan de sauvegarde et de rollback testé.
• Intégration DRD optionnelle pour l’orchestration centralisée.