DROP DATABASE IF EXISTS wp_test_pr_142; CREATE DATABASE wp_test_pr_142; — cette paire de commandes, exécutée au tout début de chaque pipeline de test, ne suffisait pas à garantir un environnement propre sur un projet d’extension de gestion de dons pour une fondation culturelle. La base était bien recréée, mais aucun mécanisme ne garantissait sa destruction en fin d’exécution, ni son isolation totale des autres pull requests en cours de test au même moment.
Résultat : trois à cinq tests d’intégration échouaient chaque semaine sans lien avec le code testé, simplement parce qu’une autre pull request, exécutée en parallèle sur le même serveur de base de données partagé, avait laissé des données résiduelles ou verrouillé temporairement une table.
Le problème d’un environnement partagé et persistant
Recréer une base au début de chaque exécution protège contre les données laissées par la pull request précédente sur le même nom de base, mais ne protège pas contre l’exécution simultanée de plusieurs pull requests, chacune avec son propre pipeline concurrent sur la même instance de base de données. Un verrou de table posé par l’une peut ralentir ou faire échouer par timeout l’exécution de l’autre.
Provisionner un environnement réellement isolé
La solution retenue consiste à provisionner, pour chaque pull request, une instance de base de données entièrement dédiée, nommée d’après le numéro de la pull request, et détruite explicitement à la fin du pipeline, qu’il réussisse ou échoue :
Arborescence du pipeline :
.ci/
provisionner-environnement.sh (crée l'instance dédiée à la PR)
detruire-environnement.sh (appelé en étape finale, même en échec)
pipeline.yml
#!/usr/bin/env bash
set -euo pipefail
NOM_INSTANCE="wp_test_pr_${NUMERO_PR}"
mysql -h "$HOTE_MYSQL" -e "CREATE DATABASE IF NOT EXISTS \`${NOM_INSTANCE}\`;"
wp config set DB_NAME "${NOM_INSTANCE}" --path=/tmp/wp-test-${NUMERO_PR}
wp core install --path=/tmp/wp-test-${NUMERO_PR} --url=test-${NUMERO_PR}.local \
--title="Environnement PR ${NUMERO_PR}" --admin_user=admin --admin_password=test --admin_email=test@exemple.test
La destruction, elle, est déclarée comme étape systématique du pipeline, y compris en cas d’échec des tests précédents :
#!/usr/bin/env bash
set -euo pipefail
NOM_INSTANCE="wp_test_pr_${NUMERO_PR}"
mysql -h "$HOTE_MYSQL" -e "DROP DATABASE IF EXISTS \`${NOM_INSTANCE}\`;"
rm -rf "/tmp/wp-test-${NUMERO_PR}"
Ce que cette isolation a changé
Une fois cette isolation en place, plus aucune pull request ne partage de ressource de base de données avec une autre en cours d’exécution, quel que soit le nombre de pipelines lancés simultanément. Les échecs liés à un état partagé imprévisible ont disparu du jour au lendemain, remplacés uniquement par de véritables échecs de test liés au code modifié.
Le point de vigilance : la destruction oubliée
Le principal risque de cette approche n’est pas la création de l’environnement, presque toujours bien exécutée, mais l’oubli de sa destruction en cas d’échec anormal du pipeline (interruption manuelle, panne d’agent CI). Un job de nettoyage périodique, exécuté chaque nuit, supprime les instances dont le nom correspond à une pull request fermée ou fusionnée depuis plus de 24 heures, en filet de sécurité derrière la destruction explicite.
Ce que cette méthode ne couvre pas
Cette approche concerne l’isolation des bases de données entre pull requests concurrentes ; elle ne traite pas de la mise en place d’un environnement de développement local jetable, ni de l’usage d’un outil de prévisualisation spécifique, qui relèvent de besoins différents.
Un environnement de test qui survit à la pull request qui l’a créé finit toujours par interférer avec la suivante.
En résumé
Provisionner une base de données dédiée par pull request, et la détruire systématiquement à la fin du pipeline, élimine les interférences entre équipes travaillant en parallèle sur le même projet. Sur ce projet, les échecs d’origine purement environnementale sont tombés à zéro sur les trois mois suivant la mise en place, sans qu’aucun test n’ait eu besoin d’être modifié.
