Voici comment les développeurs procèdent à la résolution de bugs

Le bug éclate pendant la réunion

On est jeudi, peu avant midi. Pendant une réunion sur notre site de la Mingerstrasse à Berne, où se trouve une partie de notre unité informatique, je reçois un e-mail de Jan. C’est le chef produit, avec qui je travaille en tant qu’ingénieur logiciel en étroite collaboration sur un projet d’innovation. Dans la ligne d’objet de l’e-mail figure: «Re: Pas de données». Le contenu du message est tout aussi bref: sous la citation d’Apollo 13 «Houston, we have a problem!» se trouve un lien vers une évaluation. Absence de données. L’évaluation est vide, ce qui ne devrait pas être le cas et n’est encore jamais arrivé. Et ce dans la version productive (interne) intitulée «brikks». À peine le premier choc passé, le message «Simon, tu viens de déployer l’environnement de production?» s’affiche dans la fenêtre de chat. Non, bien sûr que non.

Ai-je été distrait pendant un moment?

Mon pouls s’accélère, ma tête bouillonne. Ou est-ce que je l’ai fait? Mais, comment cela aurait-il pu se produire? Peut-être un moment d’inattention? Tout cela me paraît bizarre. La version productive est en ligne depuis un mois et fonctionnait jusqu’ici sans problèmes de déploiement majeurs. Et bien sûr, la base de code actuelle contient des migrations de base de données délicates qui suppriment les données obsolètes de la base. Quelque chose a peut-être échoué? Ce serait très ennuyeux.

C’est impossible

Je réponds par chat à Jan que je le rappelle tout de suite, m’éclipse de la réunion, enfourche mon vélo et pédale jusqu’à Engehalde, où se trouve mon poste de travail habituel. Pendant ce temps, je suis déjà au téléphone avec Jan. Il me redemande si j’ai déployé la production ce matin. L’état le plus récent de la branche Master serait en ligne. Je suis maintenant sûr de ne pas avoir fait de modification et réponds: «Non, je n’y comprends rien! Regarde vite dans le journal de déploiement qui en est l’auteur.» Jan l’a déjà fait: «Le journal indique que le dernier déploiement de production a été effectué il y a deux semaines.»

La première supposition

Ils réfléchissent rapidement. Jan m’explique qu’il a reçu ce matin un message d’erreur de la plateforme d’orchestration Kubernetes et demande si cela peut avoir un lien avec le problème. Oh là, je pressens quelque chose et explique à Jan que nous renvoyons toujours au «:latest tag» de notre image Docker dans notre configuration Kubernetes. Jan ajoute: «Et tu penses que Kubernetes a récupéré automatiquement la dernière image Docker suite aux messages d’erreur de ce matin?» Nous supposons tous les deux que cela pourrait être le cas!

«It’s not a bug, it’s a feature» ... ;-)

C’est bien ça. Juste après, de retour au poste de travail, nous nous penchons d’abord sur le problème de l’évaluation vide. A notre surprise, nous pouvons heureusement le corriger directement dans l’interface utilisateur, car il n’a aucun lien direct avec le déploiement. Nous commençons ensuite par publier un avertissement pour nos utilisateurs et indiquons qu’une nouvelle version de brikks a été déployée. Dans l’esprit de la devise «It’s not a bug, it’s a feature» ... ;-)

Contexte du bug et de la résolution

Chez PostFinance, nous utilisons de nouvelles technologies. Kubernetes en fait partie. Comme nous ne voulions pas compliquer inutilement les premières expériences avec cette plateforme d’orchestration, nous avions conçu la configuration du déploiement de la manière la plus simple possible. Et aussi parce que nous voulions passer en production le plus rapidement possible, afin de vite collecter des réactions et feed-backs de clients. Lors de la configuration du déploiement, nous avons sciemment accepté l’avertissement officiel suivant: «Note: You should avoid using the :latest tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.»

Nous avions saisi une amélioration dans le backlog, mais ne lui avions pas donné une priorité suffisante. Conséquence: au lieu de l’amélioration prévue dans le backlog, nous sommes confrontés à un bug critique. Et on s’interroge: «Qu’en est-il du PSP, le Potentially Shippable Product?» C’est vrai, nous avons en principe pour toute modification sur la branche Master un PSP qui peut être déployé. Mais dans ce cas, nous aurions préféré une introduction contrôlée des modifications, car nous avions aussi effectué divers changements dans notre interface utilisateur dont nous aurions aimé informer nos utilisateurs au préalable.

Ce que ce bug nous a appris

Entretemps, nous identifions nos images Docker et avons ainsi pu nous défaire du :latest tag dans la configuration du déploiement. Nous n’avons pas encore déterminé la cause du redémarrage des pods Kubernetes. Peut-être l’œuvre de Chaos Monkey. Il existait effectivement ici une configuration suboptimale que nous avions sciemment acceptée au départ. Heureusement que nous avons pu corriger le problème rapidement.

En tant que développeur ou développeuse chez PostFinance, tu travailles avec une grande autonomie dans un environnement agile et une équipe qui entretient une culture de l’erreur ouverte. Intéressé(e)? Nous nous réjouissons de ta candidature spontanée.

Naviguer dans PostFinance

Saisie du terme recherché

Recherche de résultats en temps réel

Nos domaines

Choix de la langue