Pourquoi ton équipe n'en finit pas d'attendre la mise en production (et comment y remédier)

Le goulot d'étranglement du staging : pourquoi ton framework a besoin d'environnements de test éphémères

Il y a un genre particulier de vendredi après-midi que les développeurs front-end et back-end connaissent bien. Une fonctionnalité est prête à être testée. L’environnement de préproduction est occupé. Quelqu’un d’autre a poussé une migration à moitié terminée vers la base de données partagée mardi dernier et elle est « presque corrigée » depuis. Soit tu attends, soit tu fusionnes à l’aveugle en croisant les doigts.

La plupart des équipes considèrent ça comme un problème de planification. Ce n’en est pas un. C’est un problème d’architecture.

Pourquoi l’environnement de préproduction partagé tombe en panne dès qu’il est soumis à une charge de travail réelle

Point clé : un environnement de préproduction unique et partagé constitue un goulot d’étranglement en termes de sérialisation. Il oblige le développement parallèle à devenir séquentiel, précisément au moment où la rapidité compte le plus.

Un serveur de préproduction partagé a du sens pour un développeur solo ou une toute petite équipe avec un rythme de publication lent. Dès que tu as deux développeurs qui travaillent sur des fonctionnalités distinctes, ou un processus d’assurance qualité qui se déroule en parallèle du développement actif, l’environnement partagé commence à causer des problèmes qui s’accumulent d’une manière qu’on a tendance à sous-estimer.

Le problème évident, c’est le temps d’attente. Le développeur A doit tester un processus de paiement. Le développeur B a une migration en cours. Le développeur A attend.

Le problème moins évident, c’est la contamination. Les environnements de staging accumulent des états. Une base de données qui a subi les tests de six développeurs en deux semaines n’est pas une surface de test fiable. Une fonctionnalité qui passe les tests sur un environnement de staging contaminé peut se comporter de manière totalement différente lorsqu’elle arrive sur une base de données de production propre. Tu as testé quelque chose, mais tu n’as pas testé ce que tu penses avoir testé.

Le problème le moins évident, c’est le ralentissement des revues de code. Quand les tests nécessitent l’accès à une ressource partagée, les relecteurs finissent par valider des éléments qu’ils n’ont pas entièrement vérifiés, car le coût d’accès à l’environnement est suffisamment élevé pour qu’ils préfèrent passer leur tour. Ce goulot d’étranglement ne fait pas que retarder les tests ; il en dégrade la qualité.

L'écart entre le pré-production et la production

Point clé à retenir : chaque différence entre ton environnement de préproduction et de production est un angle mort potentiel. Les bugs qui se cachent dans cet écart restent invisibles jusqu’à ce qu’ils apparaissent en production.

La dérive entre l’environnement de préproduction et celui de production est si courante qu’elle en est devenue une sorte de bruit de fond. Des niveaux de correctifs différents pour les systèmes d’exploitation, des versions de services légèrement différentes et des contenus de bases de données qui divergent d’une semaine à l’autre. La plupart des développeurs ont fini par accepter le principe « ça marche en préproduction, ça plante en production » comme une réalité agaçante plutôt que comme un problème qui peut être résolu.

Mais c’est un problème qui peut être résolu.

Cet écart existe parce que les environnements de préproduction sont gérés manuellement. Quelqu’un met à jour la production mais oublie la préproduction. Une dépendance est fixée à une version différente. Le schéma de la base de données reçoit un correctif qui n’est jamais réintégré dans les scripts de migration. Ce ne sont pas vraiment des erreurs, c’est juste le résultat naturel du fait de traiter ces deux environnements comme des entités distinctes à gérer.

La solution, ce n’est pas d’imposer une discipline plus stricte pour maintenir l’environnement de préproduction à jour. C’est un coût de processus qui augmente à mesure que l’équipe s’agrandit. La solution, c’est de faire en sorte que les deux environnements soient, par nature, identiques.

Ce que font réellement les environnements de test basés sur Git

Point clé : lorsqu’une branche provisionne automatiquement son propre environnement équivalent à celui de production, la file d’attente de staging disparaît et l’écart se comble. Chaque développeur teste sur une surface propre et précise sans toucher au travail des autres.

Le principe est simple. Quand tu pousses une branche, la plateforme met en place un environnement complet pour cette branche : même version d’exécution, mêmes services, même configuration qu’en production. Quand la branche est fusionnée ou fermée, l’environnement est supprimé. Pas de provisionnement manuel, pas d’état partagé, pas de file d’attente.

Upsun est une plateforme d’applications cloud qui gère la couche d’infrastructure de ta pile d’applications pour que ton équipe n’ait pas à s’en occuper. Ça se voit notamment dans le fonctionnement des environnements : chacun est un clone de son parent, jusqu’aux données. Une branche dérivée de la branche principale bénéficie de la même pile, des mêmes versions de services et d’une copie de l’instantané des données de production. Tu ne testes pas sur une approximation de préproduction. Tu testes sur une réplique.

Voici à quoi ressemble la création d’un environnement de branche sur Upsun :

# Branch from main and spin up a full environment automatically
upsun branch feature/new-checkout main

# Your branch environment is live at a unique URL within seconds
# Same runtime, same services, same data as production

L’impact concret sur une équipe de quatre ou cinq développeurs est considérable. Les branches de fonctionnalités peuvent être testées en parallèle. L’équipe d’assurance qualité peut examiner directement un environnement de branche, avec une URL réelle, sans attendre un créneau de déploiement. Un bug signalé sur une branche spécifique peut être reproduit dans l’environnement de cette branche, et non dans un environnement partagé qui a peut-être été modifié par trois autres personnes depuis que le bug a été signalé.

Pour des frameworks comme Drupal ou Django, où le schéma de la base de données et le code de l’application sont étroitement liés, c’est encore plus important. Une migration qui fonctionne sur une copie réelle de la base de données de production est une migration à laquelle tu peux vraiment faire confiance.

Le changement du processus

Point clé : les environnements de test changent ce qui est possible, pas seulement la vitesse d’exécution du processus existant : révision du code avec des environnements en direct, assurance qualité en parallèle du développement, et un goulot d’étranglement au niveau de la mise en production qui n’existe plus.

Ce changement concerne moins la vitesse des tests que ce qui devient possible lorsque l’accès aux environnements cesse d’être une ressource rare.

Les relecteurs de code peuvent ouvrir un environnement de production pour n’importe quelle pull request sans avoir à demander l’accès à qui que ce soit. L’assurance qualité peut exécuter des tests sur une branche avant qu’elle ne soit fusionnée, et non après. Un chef de produit peut prévisualiser une fonctionnalité dans un environnement réel sans attendre un déploiement. Un correctif peut être validé sur une réplique de production avant sa mise en ligne, et non dans un environnement partagé « contaminé » qui n’a pas été nettoyé depuis six semaines.

Plutôt que de devenir plus rapide ou plus performant, l’environnement de préproduction partagé devient tout simplement inutile.

Tu utilises déjà une configuration de préproduction partagée ?

Le passage à des environnements par branche ne nécessite pas de reconstruire ton processus à partir de zéro. Si ton équipe déploie actuellement sur un serveur de préproduction partagé pour révision, le changement est simple : les branches disposent de leurs propres environnements, le serveur partagé cesse d’être le « gardien » de l’assurance qualité, et la file d’attente disparaît. L’essentiel est de prévoir la mise à jour des étapes CI/CD qui supposent une seule cible de préproduction, puisque chaque environnement de branche dispose de sa propre URL.

Foire aux questions (FAQ)

Est-ce que chaque branche dispose vraiment d’un environnement complet, avec des services comme Redis et une base de données ?

Oui. Chaque environnement de test est un clone de son environnement parent, services compris. Si l’environnement de production utilise MariaDB et Redis, l’environnement de la branche utilise les mêmes versions des deux, alimentées à partir d’un instantané des données de production.

Qu’advient-il des données dans un environnement de test ?

Au départ, il s’agit d’une copie des données de l’environnement parent au moment de la création de la branche. Les modifications que tu apportes dans l’environnement de test restent isolées à cet endroit. Lorsque la branche est supprimée, l’environnement et ses données sont supprimés. L’environnement de production n’est jamais affecté.

En quoi est-ce différent de la mise en place manuelle d’un serveur de préproduction ?

La différence principale, c’est que ça se fait automatiquement, que c’est cohérent par nature et que ça n’entraîne aucun coût de maintenance récurrent. Un serveur de test provisionné manuellement finit par diverger de l’environnement de production au fil du temps et nécessite qu’on le maintienne à jour. Un environnement de test géré par la plateforme est créé à chaque fois à partir du même fichier de configuration et des mêmes données.

Les non-développeurs peuvent-ils accéder aux environnements de test ?

Oui. Chaque environnement dispose de sa propre URL. Tu peux partager cette URL avec l’équipe d’assurance qualité, un chef de produit ou un client sans donner à personne l’accès à l’infrastructure sous-jacente.

Que deviennent les environnements de test lorsqu’une branche est fusionnée ?

Ils sont désactivés et supprimés. Tu ne paies pour les environnements que lorsqu’ils sont actifs, ce qui signifie aussi que tu ne fais pas tourner de serveurs inactifs pour des branches livrées il y a trois semaines.