Chez Imagile, nous apportons un soin particulier aux processus de test et de déploiement.
Ces aspects de tests, d’environnements et de déploiement sont particulièrement étudiés lors de nos audits techniques dans le cadre de reprise de projet. Valider et optimiser les procédures (pas seulement techniques mais également humaines) de vérification avant mise en production, c’est assurer une maintenance évolutive performante et productive.
Voici, en quelques points, comment nous concevons ce savoir-faire :
Chaque développeur doit pouvoir travailler sur le projet sur sa machine. Cet environnement de développement local est cadré par une machine virtuelle, la plupart du temps Docker, afin de s’assurer qu’aucune configuration spécifique et personnelle n’influe sur le code.
On ne pousse pas le code même dans un environnement de test sur le serveur sans l’avoir testé sur sa propre machine. Ceci nécessite également de pouvoir lancer les tests en local.
Que l’on procède en TDD (Test Driven Development) ou que l’on réalise les tests unitaires une fois le code produit, il est d’abord nécessaire de prendre du recul sur l’application et de déterminer les fonctionnalités dont la fiabilité est essentielle : celles qui ont un impact business (prise de commande, paiement, etc.) ou un impact sur le quotidien des utilisateurs (accès à des ressources utiles…). Il est absurde de tester 100% d’une application. Prioriser les tests est donc un passage obligé, un exercice salutaire.
Tester correctement, c’est aussi ne pas se reposer sur les tests unitaires. Tester l’application en tant qu’utilisateur avec un navigateur, considérer l’expérience client, voilà qui permet de s’assurer que nos développements fonctionnent vraiment. On ne le répètera jamais assez, et surtout aux développeurs back : une application ne se consulte pas qu’en ligne de commande :-).
Échanger avec les utilisateurs finaux, savoir les interroger et entendre ce qui les embêterait si telle ou telle fonctionnalité n’était pas opérationnelle, est aussi le moyen de détecter l’utilité de certains tests.
Évidemment, les suites de tests automatisées sont la règle chez Imagile. Lancer cette suite de tests et s’assurer qu’ils passent tous est un préalable avant de pousser le code en ligne.
Même (surtout) si le collègue ne travaille pas sur le même projet, lui demander de tester l’application, ou certaines parties de l’application, est un excellent moyen de s’assurer que tout est convenable et compréhensible. Au demeurant, il est possible de recueillir des remarques pertinentes. À ce stade, on découvre souvent des améliorations et on épargne au client des aller-retours inutiles.
Nous mettons en place chez Imagile des revues de code régulières afin de faire progresser la qualité des développements, renforcer les liens au sein des équipes et faire grandir en compétences chaque développeur.
Même en ayant vérifié consciencieusement, on n’est jamais à l’abri d’une erreur passée au travers des mailles du filet. Il est donc imoprtant d’être alerté lorsqu’une erreur se produit en production. Il faut de plus obtenir un maximum de renseignements permettant d’identifier l’erreur pour la corriger : environnement de production ou test, ligne du code du fichier concerné, pile d’appels (stacktrace) complète, utilisateur connecté, etc.
Pour cela nous utilisons des outils de monitoring comme Bugsnag que nous branchons à un canal Slack. Nous recevons ainsi une notification dès qu’une erreur apparaît avec tous les éléments pour la corriger. Une personne en charge du projet peut alors s’en occuper. Il nous arrive d’ailleurs de prévenir un client qu’une erreur a eu lieu et a été corrigée avant même qu’il ne l’ait remarquée :-).
Chez Imagile, tout le monde ne connaît pas à fond tous les projets de tous nos clients. Par contre, il est essentiel qu’en cas de non disponibilité d’un développeur (vacances par exemple), chaque membre de l’équipe puisse intervenir facilement. Et ceci pour plusieurs raisons :
- il se peut que l’on se rende compte que bien plus tard, après la mise en production, qu’un bout de code entraîne des effets collatéraux,
- il faut que le client puisse contacter la société et, sans vouloir entamer un gros chantier nécessitant une connaissance profonde du projet, simplement réaliser quelques ajustements, voire revenir en arrière sur certains points,
- la lisibilité des tests et la contextualisation du code permet une reprise sereine par d’autres développeurs.
Il est également important de ne pas se concentrer sur la recherche de coupable mais sur la résolution des problèmes. Il arrive à tous de faire des erreurs et un développeur peut vite avoir tendance à oublier que ce qu’il reproche à un collègue lui est arrivé auparavant.
En cultivant un environnement de prise de responsabilité sur son travail, chaque développeur grandit et peut aider un collègue sur un autre projet sur lequel il a la maîtrise, ou intervenir sereinement sur un projet qu’il connaît moins. Cela permet de transmettre de bonnes pratiques dans toute l’équipe pour entretenir une culture de la qualité.