Du rapport de bug à la correction validée en un seul processus

La plupart des guides de débogage se concentrent sur une seule fonctionnalité isolée. Ce guide couvre tout le processus.

Le bug : un code de réduction ne s’appliquait plus aux clients ayant un abonnement annuel. Il passait tous les tests existants, fonctionnait pour les comptes mensuels et ne posait problème que pour une partie des vrais clients annuels. Personne n’avait réussi à le reproduire en dehors de l’environnement de production.

Voici comment on est passé du ticket au correctif validé.

Cloner l’environnement

Point clé : commence par une copie isolée de l’environnement de production qui dispose des mêmes services, de la même configuration et d’une copie des données de production.

La première étape, c’est de créer une branche :

upsun branch debug-branch main --resources-init=parent

Ça crée un environnement de test appelé « debug-branch » à partir de la branche « main ». Par défaut, il clone les données du parent, donc les comptes à facturation annuelle où la réduction ne marchait pas sont là aussi. L'option --resources-init=parent donne au nouvel environnement la même puissance CPU et la même mémoire que l'environnement de production. Si tu ne la mets pas, l'environnement de développement démarre avec un minimum de ressources, ce qui est moins cher mais ne correspondra pas à la production pour les bugs sensibles aux performances.

Ensuite, ouvre des tunnels vers les services de l’environnement et exporte leurs informations de connexion :

upsun tunnel:open
export PLATFORM_RELATIONSHIPS="$(upsun tunnel:info --encode)"

tunnel:open crée des tunnels SSH vers tous les services de l’application, base de données comprise. L’exportation permet à une copie locale de l’application, ou à n’importe quel outil local, de s’y connecter comme s’ils tournaient sur ta machine.

Reproduis le bug

Point clé : déclenche l’erreur avec les mêmes données et services que ceux qui l’ont provoquée en production.

Une fois le tunnel ouvert, interroge l’un des comptes annuels défaillants pour vérifier son état de facturation. Ouvre ensuite l’URL de l’environnement de test, applique le même code de réduction à ce compte et observe-le échouer en silence, comme les clients l’ont vu.

La reproduction est généralement la partie la plus longue d’un bug comme celui-ci, car il faut créer des données de test qui se comportent comme le compte qui a planté. Ici, le compte qui a planté se trouve déjà dans l’environnement.

Isoler et corriger

Point clé : écris et teste le correctif en reproduisant les conditions qui ont provoqué le bug.

Une fois que le bug se reproduit de manière fiable, le reste relève du débogage classique : lis les logs, passe en revue la logique de remise, vérifie ce qui a changé. Tu peux connecter un débogueur à distance à l’environnement en cours d’exécution via SSH, avec upsun xdebug pour PHP ou une redirection de port SSH pour Node.js, et parcourir le code en te concentrant sur les comptes précis qui échouent.

La cause : la logique de remise vérifiait un champ lié au cycle de facturation mensuel que les comptes annuels ne remplissent pas de la même manière.

La première correction a résolu ce cas. Après l’avoir poussée sur la branche « debug-branch » et l’avoir testée sur quelques comptes annuels supplémentaires dans le même environnement, un deuxième cas limite est apparu : les abonnements pluriannuels, qui stockent le cycle de facturation dans un tout autre champ. La deuxième correction a été intégrée à la même branche et a été testée sur les deux types de comptes.

Est-ce qu’on peut utiliser des données clients réelles ici sans risque ?

Point clé : les environnements de test peuvent conserver les données dont dépend un bug et effacer celles dont il n’a pas besoin.

Le débogage sur des copies isolées de comptes réels soulève une question légitime. Upsun te permet d’ajouter un script de nettoyage à ton hook de déploiement qui anonymise les données personnelles dans les environnements de test. Tu écris le script adapté à ton schéma, par exemple en remplaçant les noms, les e-mails et les détails de paiement, et tu le configures pour qu’il ne s’exécute que sur les environnements hors production. Une fois qu’il est fusionné en production, chaque nouvel environnement de test est nettoyé lors de sa création et de son premier déploiement.

Pour ce bug, le script ne touche pas à l’état de facturation, car c’est de ça que dépend le bug. Les noms des clients, leurs e-mails et leurs informations de paiement sont anonymisés.

Configure ça avant d’en avoir besoin. La documentation sur le nettoyage des bases de données propose des exemples concrets pour MariaDB avec Drupal, PostgreSQL avec Django et PostgreSQL avec Symfony.

Valide avant la fusion

Point clé : valide dans le même environnement que celui où tu as diagnostiqué le bug, pour que le résultat te donne une idée précise de ce qui se passe en production.

Avant la fusion, le correctif a été validé par rapport au compte annuel d’origine et au cas pluriannuel, dans le même environnement où le bug a été diagnostiqué.

Cet environnement utilise les mêmes services et la même configuration que la production, avec les données de production moins les champs qui ont été nettoyés, et (avec l’option --resources-init=parent) les mêmes ressources. Un correctif qui passe ce test a été testé dans les conditions réelles qui ont causé l’échec, et non dans une simulation de celles-ci. À partir de là :

upsun merge debug-branch

Prêt à essayer ça sur ton propre bug ? Commence un essai gratuit de 15 jours et clone ton premier environnement.

Foire aux questions (FAQ)

Est-ce que ça nécessite des outils différents à chaque étape ? 
Tu utilises toujours tes outils habituels : la CLI, ton IDE, ton débogueur. Ce qui reste identique, c’est l’environnement. La création de branches, le tunneling, le débogage et la validation s’effectuent tous sur un seul environnement cloné, tu n’as donc pas besoin de reconstruire les données de test ni de recréer les services entre les étapes.

Les données utilisées pour la reproduction sont-elles représentatives de la production ? 
Oui, pour ce qui concerne le bug en question. L’environnement est cloné à partir de la production, il dispose donc des mêmes services, de la même configuration et des mêmes données. Si tu utilises un script de nettoyage, les données personnelles sont anonymisées, et le reste des données reste tel quel, comme en production. Crée une branche avec l’option --resources-init=parent si tu as également besoin de ressources correspondantes.

Que devient l’environnement de débogage une fois le correctif déployé ? 
Fusionne-le, puis supprime-le avec la commande « upsun environment:delete debug-branch ». Tu peux aussi le laisser en cours d’exécution si tu as encore besoin de mener des investigations. Il utilise des ressources jusqu’à ce que tu le supprimes ou le désactives.