Développement Web

Dans l'écosystème du développement web professionnel, la gestion des configurations est un pilier de la réussite d'un projet. Depuis le lancement de son système de gestion de configuration intégré, Drupal propose une méthode standardisée pour exporter l'ensemble des paramètres du site sous forme de fichiers YAML. Cependant, lorsqu'un projet grandit et implique plusieurs environnements de travail, cette approche globale montre rapidement ses limites. Comment éviter qu'un module destiné au développement ne se retrouve activé en production ? Comment sécuriser les clés d'API d'un environnement de préproduction sans écraser les accès locaux des développeurs ?

Ce guide méthodologique explore les solutions avancées pour segmenter proprement vos configurations et industrialiser vos processus de déploiement.

Le défi de la synchronisation stricte avec la commande native de Drupal

La force historique du système de gestion des configurations de Drupal réside dans sa rigueur : tout le site est représenté dans un dossier unique contenant des centaines de fichiers YAML.

Les limites de la commande drush config-import dans un contexte multi-environnements

La commande native de synchronisation globale part d'un postulat simple : l'état des configurations stockées dans les fichiers doit être strictement identique à celui de la base de données. Si vous exécutez la commande drush config-import, Drupal va tenter d'aligner l'intégralité du site sur le modèle exporté. Cette approche devient problématique dès lors que vos besoins divergent selon les serveurs :

• Un développeur local a besoin de modules d'aide au développement comme Devel ou Kint pour analyser son code.
• Un serveur de test nécessite des configurations d'envoi d'e-mails spécifiques pour rediriger tous les messages vers une boîte de test.
• Un serveur de production exige l'activation de modules de cache agressifs et des passerelles de paiement réelles à la place des modes de test.

Sans outil complémentaire, importer les configurations sur la production désactiverait systématiquement vos modules locaux à chaque déploiement, ou pire, activerait des outils de débogage lourds et non sécurisés sur votre serveur public.

Les risques de dérive de configuration entre le local et la production

Pour contourner ces limites, certains développeurs commettent l'erreur de modifier manuellement des paramètres directement en base de données sur l'environnement de production. Cette pratique crée ce que l'on appelle une dérive de configuration : le code source ne correspond plus à la réalité du serveur de production. Lors du déploiement suivant, l'exécution de la commande d'importation écrasera ces modifications manuelles, provoquant potentiellement des pannes de service ou des pertes de données financières.

Concevoir une stratégie de Configuration Split robuste

Pour résoudre ces conflits, l'usage du module contribué Configuration Split s'est imposé comme le standard industriel pour l'écosystème Drupal. Ce module permet de définir des filtres pour diviser vos configurations en plusieurs ensembles logiques.

Comprendre la différence entre un split complet et un split partiel

Le module propose deux stratégies distinctes pour traiter vos configurations selon leur nature :

• Le split complet : cette méthode extrait complètement une configuration ou un module de l'ensemble principal pour le placer dans un dossier dédié. Le module et toutes ses dépendances ne seront importés que si le filtre spécifique est activé. C'est l'approche idéale pour isoler totalement des modules spécifiques à un environnement.
• Le split partiel : cette approche permet de conserver la configuration dans le dossier principal tout en autorisant des variations de valeurs selon les environnements. Elle est particulièrement utile pour modifier une simple adresse URL de service ou une clé d'API sans dupliquer l'intégralité de la configuration associée.

Structurer l'exclusion des modules de débogage et de développement

Pour un projet de grande envergure, il est recommandé de mettre en place trois niveaux de split :

• Le niveau commun : contenant l'ossature du site, les types de contenu et la structure des blocs.
• Le niveau de développement : contenant les modules d'aide au codage, la désactivation des caches CSS et JavaScript, et l'affichage des erreurs système.
• Le niveau de production : contenant les configurations de sécurité strictes, l'activation des systèmes de paiement réels et l'intégration des outils de suivi statistique.

Isoler les clés d'API et les configurations de services tiers

Il est crucial de ne jamais stocker de données sensibles, telles que des clés d'API privées ou des mots de passe de bases de données, directement dans vos fichiers de configuration YAML exportés sur un dépôt de code public. Le split partiel permet d'isoler ces configurations spécifiques. Combiné avec l'utilisation de variables d'environnement, il garantit que chaque serveur accède uniquement aux données qui lui correspondent sans risque de fuite d'informations.

Implémentation technique étape par étape

La mise en place de cette architecture nécessite une rigueur d'implémentation pour éviter les conflits lors de la génération des fichiers YAML.

Installation et activation des modules requis

La première étape consiste à installer le module via Composer. Ouvrez votre terminal et exécutez la commande suivante :

composer require drupal/config_split

Une fois le téléchargement terminé, vous devez activer le module sur votre environnement local à l'aide de Drush :

drush pm-enable config_split --yes

Configuration des filtres conditionnels via les fichiers de configuration YML

La définition de vos filtres de split se fait à travers l'interface d'administration de Drupal ou directement en créant un fichier de configuration. Voici un exemple de structure pour un fichier nommé config_split.config_split.dev.yml qui permet d'isoler les modules de développement :

uuid: e83b2762-23c3-4f9e-beee-07a82759e661
langcode: fr
status: false
dependencies: {  }
id: dev
label: 'Environnement de développement'
description: 'Filtre de configuration pour le développement local'
folder: ../config/split/dev
module:
  devel: 0
  kint: 0
  dblog: 0
theme: {  }
complete_split: true

Dans cet exemple, le paramètre status: false indique que le filtre n'est pas activé par défaut. C'est l'étape suivante qui va s'occuper d'activer dynamiquement ce filtre selon le serveur cible.

Déclaration des splits dans le fichier de paramètres de l'application

Pour que Drupal sache quel filtre appliquer, vous devez surcharger l'état du filtre directement dans votre fichier settings.php ou settings.local.php. Cette surcharge en mémoire évite d'altérer les fichiers physiques stockés sur le dépôt Git.

Voici le bloc de code PHP à insérer dans votre fichier de configuration pour activer dynamiquement le split de développement sur votre machine locale :

<?php

/**
 * @file
 * Surcharge dynamique des états de Configuration Split.
 */

// Désactivation par défaut de tous les filtres spécifiques.
$config['config_split.config_split.dev']['status'] = FALSE;
$config['config_split.config_split.prod']['status'] = FALSE;

// Détection de l'environnement de travail.
$env = getenv('DRUPAL_ENV');

if ($env === 'development') {
    // Activation du filtre de développement sur l'environnement local.
    $config['config_split.config_split.dev']['status'] = TRUE;
} elseif ($env === 'production') {
    // Activation du filtre de production sur le serveur de production.
    $config['config_split.config_split.prod']['status'] = TRUE;
}

Automatisation et industrialisation dans le pipeline de déploiement continu

Une fois les fichiers configurés, l'étape ultime consiste à automatiser l'importation de ces données lors de vos phases de déploiement continu.

Exploiter les variables d'environnement système sous Debian

Pour que le code PHP présenté ci-dessus fonctionne de manière optimale, vos serveurs Linux Debian doivent déclarer la variable d'environnement appropriée. Vous pouvez configurer cette variable de manière permanente dans la configuration de votre serveur web Apache ou Nginx, ou directement au niveau du système dans le fichier /etc/environment :

# Ajout de la variable d'environnement sur un serveur Debian de production
echo "DRUPAL_ENV=production" >> /etc/environment
source /etc/environment

Pour les configurations de serveurs virtuels Nginx, vous pouvez passer cette variable directement dans le bloc de traitement PHP-FPM :

# Exemple de configuration pour le bloc de serveur Nginx
fastcgi_param DRUPAL_ENV production;

Structurer les commandes Drush dans les scripts de déploiement

Dans votre pipeline de déploiement continu, les commandes doivent être exécutées dans un ordre précis pour garantir que la base de données de production reçoive les bonnes configurations sans interruption de service.

Voici un exemple de script Bash standardisé pour automatiser cette tâche lors de chaque mise en production :

#!/bin/bash

# Arrêt du script en cas d'erreur.
set -e

echo "Début de la phase de déploiement des configurations Drupal..."

# 1. Reconstruction du cache pour s'assurer que les variables d'environnement sont lues.
echo "Reconstruction du cache..."
drush cache-rebuild

# 2. Importation des configurations.
# Le paramètre --yes permet de valider automatiquement les modifications détectées.
echo "Importation des fichiers YAML..."
drush config-import --yes

# 3. Exécution des mises à jour de base de données en attente.
echo "Exécution des mises à jour de schéma..."
drush updatedb --yes

# 4. Nettoyage final du cache pour l'expérience utilisateur.
echo "Nettoyage final du cache..."
drush cache-rebuild

echo "Déploiement terminé avec succès !"

Comparaison des approches de gestion de configuration

Pour vous aider à choisir la meilleure méthode selon la taille de votre structure, voici une analyse comparative des différentes manières de gérer les écarts de configuration :

• L'approche native de Drupal sans module : elle convient uniquement aux projets simples hébergés sur un seul serveur. Ses limites sont l'impossibilité d'exclure des modules de développement et un risque élevé d'erreur humaine lors des déploiements.
• L'approche par exclusion via le fichier de paramètres PHP : elle convient aux projets de taille moyenne avec peu de configurations divergentes. Ses limites résident dans la complexité de maintenance du code PHP lorsque le nombre de modules exclus augmente.
• L'approche par Configuration Split : elle représente la solution industrielle idéale pour les projets d'agence et les architectures complexes. Elle offre une flexibilité totale grâce à la gestion visuelle des filtres, une séparation parfaite des dossiers de configuration et une automatisation native via Drush.

Conclusion sur l'industrialisation des configurations de Drupal

Maîtriser le Configuration Split est indispensable pour toutes les équipes techniques qui souhaitent mettre en place des pratiques DevOps modernes autour de Drupal. En séparant clairement les responsabilités de chaque environnement et en automatisant l'importation des filtres via vos variables d'environnement système, vous éliminez définitivement le risque de dérive des configurations. Vos déploiements deviennent ainsi prédictibles, rapides et parfaitement sécurisés.

Foire aux questions

Qu'est-ce que la dérive de configuration dans Drupal ?

La dérive de configuration désigne l'écart qui se crée au fil du temps entre les configurations stockées sous forme de fichiers YAML dans votre dépôt de code et les configurations réellement actives en base de données sur votre serveur de production.

Le module Configuration Split ralentit-il les performances de Drupal en production ?

Non, car l'évaluation de l'état des filtres est gérée directement en mémoire au moment du chargement de l'application ou lors de l'exécution des commandes d'importation. Les performances de votre site public pour les utilisateurs finaux restent inchangées.

Peut-on faire un split sur un seul bloc de texte ou un seul menu ?

Oui, grâce à l'utilisation des filtres partiels, vous pouvez choisir de ne surcharger que certaines portions de vos configurations, comme le titre d'un bloc ou l'adresse d'un lien dans un menu, sans avoir à extraire la totalité du composant.

Comment réagir si un module de développement se retrouve activé par erreur en production ?

Vérifiez immédiatement la valeur de votre variable d'environnement sur le serveur cible. Si la variable n'est pas correctement détectée comme production par votre fichier settings.php, le split de développement peut s'activer par défaut.