# Antipatterns d’un wp-env partagé par toute une équipe sans isolation

> Une équipe entière connectée au même conteneur wp-env accumule des conflits invisibles. Ce que révèle ce montage et pourquoi chacun doit repartir de zéro.

- Auteur : Clément Hadrot
- Publié le : 2024-05-04
- Mis à jour le : 2024-05-04
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/antipatterns-wp-env-partage-equipe-sans-isolation/

## L’essentiel

- Un seul environnement partagé multiplie les faux positifs
- Les migrations de base laissées par un collègue cassent les tests d'un autre
- L'isolation par machine coûte moins cher que les heures perdues à déboguer

`wp-env start` : cette commande, lancée depuis le dépôt d'une extension, démarre en quelques secondes deux conteneurs, un WordPress et une base MySQL, prêts à recevoir du code. C'est l'un des grands mérites de l'environnement officiel proposé par l'équipe des outils de développement de WordPress. Mais un piège guette les équipes pressées : mutualiser une seule instance de ces conteneurs entre plusieurs développeurs, sur un serveur de développement partagé, pour économiser du temps de configuration. Le résultat est presque toujours le même, une accumulation de conflits qui coûte largement plus cher que l'installation individuelle qu'on voulait éviter.

Cet article recense les antipatterns observés sur ce genre de montage, indépendamment de la question réseau (exposition du port, nom de domaine partagé) qui mériterait un traitement à part entière. Il s'agit ici de ce qui se passe à l'intérieur des conteneurs quand plusieurs personnes y travaillent en même temps.

## Ce qu'on voit : des tests qui passent chez l'un et échouent chez l'autre

Le symptôme le plus fréquent d'un `wp-env` mutualisé, c'est le test qui échoue de façon aléatoire sans changement de code apparent. Un développeur exécute la suite de tests PHPUnit fournie par `wp-env run tests-cli` et obtient un échec sur une fonctionnalité qu'il n'a pas touchée. En creusant, on découvre qu'un collègue a laissé une option activée dans `wp_options`, ou qu'un plugin tiers installé pour un autre besoin modifie un comportement global du site de test.

### Pourquoi c'est un problème

La base de données d'un `wp-env` n'est pas réinitialisée entre deux sessions de travail de personnes différentes. Chaque commande `wp` exécutée à l'intérieur, chaque plugin activé pour vérifier un comportement, chaque contenu de démonstration ajouté reste présent pour la personne suivante. L'environnement cesse alors de représenter un état connu et devient un empilement de décisions individuelles, invisibles pour qui n'était pas là au moment où elles ont été prises.

> L'essentiel à retenir : Un seul environnement partagé multiplie les faux positifs ; Les migrations de base laissées par un collègue cassent les tests d'un autre ; L'isolation par machine coûte moins cher que les heures perdues à déboguer

## Ce qu'on voit : des ports qui se battent entre deux projets

Deuxième antipattern classique : deux personnes travaillent sur deux extensions différentes mais partagent le même environnement, pensant simplifier la maintenance. L'une modifie le fichier `.wp-env.json` pour monter un volume supplémentaire nécessaire à son projet, l'autre voit son propre montage de volume disparaître au redémarrage suivant. Le fichier de configuration devient un champ de bataille silencieux, chacun écrasant sans le savoir les réglages du précédent.

- Des mappages de ports incohérents d'un jour à l'autre, sans qu'aucune modification volontaire n'ait été faite.
- Des variables d'environnement PHP (`WP_DEBUG`, limites de mémoire) qui changent silencieusement selon qui a redémarré le conteneur en dernier.
- Des extensions tierces installées pour un test ponctuel, jamais désinstallées, qui polluent les résultats des suivants.
- Une base de données qui grossit indéfiniment, ralentissant les imports et les exports que tout le monde utilise.

## Pourquoi l'isolation individuelle coûte moins cher qu'elle n'y paraît

L'argument en faveur du partage est presque toujours le même : économiser les ressources machine et le temps de configuration initiale. En pratique, `wp-env` repose sur Docker et démarre un environnement complet en une commande à partir d'un simple fichier `.wp-env.json` versionné dans le dépôt. Le coût réel d'une instance individuelle par développeur se limite à quelques centaines de mégaoctets de RAM allouée le temps de la session de travail, largement compensés par les heures non perdues à comprendre pourquoi « ça marche chez moi mais pas chez toi ».

```
{
  "core": "WordPress/WordPress#6.5",
  "plugins": [ "." ],
  "config": {
    "WP_DEBUG": true,
    "WP_DEBUG_LOG": true
  },
  "port": 8888,
  "testsPort": 8889
}
```

Ce fichier, propre à chaque projet et versionné avec lui, permet à n'importe quel membre de l'équipe de reconstruire un environnement identique en local avec `wp-env start`, sans dépendre d'un serveur partagé ni d'un état hérité de la veille.

## Ce qu'il faut mettre en place à la place

La bonne pratique consiste à faire de chaque poste de développement le point de départ d'un `wp-env` propre, réinitialisé à volonté par `wp-env destroy` suivi d'un `wp-env start`. Trois habitudes suffisent à installer cette discipline durablement dans une équipe :

1. Versionner le fichier `.wp-env.json` et le fichier `.wp-env.override.json` pour les réglages personnels, ce dernier étant ignoré par Git.
2. Documenter dans le fichier `README` du dépôt la commande exacte de réinitialisation à exécuter en cas de comportement suspect.
3. Interdire, par convention d'équipe, toute installation manuelle de plugin de test sans passer par la configuration versionnée.

> Sur nos projets, la règle qui a le plus réduit les signalements de bogues fantômes tient en une phrase : un environnement de développement suspect se détruit, il ne se débogue pas.

## Notre verdict

Un `wp-env` partagé donne l'illusion d'un gain de temps à l'installation, mais transfère ce coût vers chaque session de débogage ultérieure, où personne ne sait plus vraiment quel état a produit quel comportement. L'isolation par personne, rendue triviale par la légèreté de Docker et par la simplicité du fichier de configuration officiel, reste la seule approche qui garde l'environnement de développement fidèle à ce qu'il est censé représenter : un état reproductible, identique pour tout le monde, à volonté.