La qualité au sein de Leikir Web
Chez Leikir Web, la qualité est une de nos priorités. Ainsi nous avons mis en place des outils et pratiques afin de nous assurer de la qualité, de la fiabilité et de la robustesse de nos réalisations. Cela nous permet de faciliter la maintenance et les évolutions des applications en évitant les régressions et nous permet d’être confiant lors des mises en production.
Petit aperçu des outils et pratiques que nous mettons en oeuvre.
Gestion de projet
La qualité commence dès la rédaction des tickets sur notre outil de gestion de projet. Nous veillons à écrire des descriptions complètes pour que le développeur qui va réaliser le ticket dispose de toutes les informations. Par ailleurs les zones de flou sont réduites au minimum.
Outil utilisé : Jira
Code
On rentre ensuite dans le développement en tant que tel. Nous utilisons des linters afin de mettre en place des conventions de codage fortes que toute l’équipe respecte. Ce faisant, quand un développeur doit reprendre du code qu’il n’a pas écrit, le coût à l’entrée est moindre. Au delà des conventions que tout le monde respecte, les linters nous forcent à respecter les bonnes pratiques propres à chaque langage ou framework et architecturer le code proprement.
Outils utilisés : RuboCop et ESLint
Au sein de Leikir Web nous pratiquons le feature branching. C’est-à-dire que nous créons une branche git pour chaque ticket. Quand le développeur estime que son ticket est terminé, il fait une Pull Request vers la branche de travail. Il demande ensuite à être review par un ou plusieurs membres de son équipe. Cela donne lieu à des questions et discussions sur le code écrit. Cela nous permet aussi d’être dans une démarche d’amélioration continue. Ainsi le code est toujours relu par au moins un autre développeur. Les erreurs grossières et conceptions bancales sont évitées de cette façon. Suivant les projets, il faut une ou deux approbations pour avoir le droit de merger le code dans la branche principale.
Outils utilisés : GitHub et Bitbucket
En fonction des envies des développeurs et des fonctionnalités à réaliser nous faisons régulièrement du pair coding. La plupart du temps nous le faisons sur des fonctionnalités coeur des applications. En plus de faire progresser les développeurs, cela nous assure une bonne qualité car on est toujours meilleurs quand deux cerveaux travaillent sur le même code.
Tests
Vient le sujet des tests. Venant pour ma part du monde Ruby, c’est une pratique que je pousse fortement et qui me tient à coeur. Nous nous imposons des couvertures de tests à plus de 90%. On ne compte plus le nombre de fois où les tests ont détecté une régression à laquelle nous n’avions pas pensé. Le choix des types de tests à réaliser est discuté par l’équipe avant le lancement du projet en fonction de la criticité de chaque partie de l’application. Tests unitaires et d’intégration sont toujours de la partie. Ce sujet est fort vaste et mériterait un billet de blog à lui seul.
Quelques outils utilisés : RSpec, Jest…
Nous utilisons comme beaucoup de l’intégration continue (CI). La CI fait tourner les tests à chaque push sur git afin de nous assurer que nous n’avons pas inclus de régression. Une bonne intégration entre nos outils nous permet de visualiser sur les Pull Request le résultat des tests pour la branche concernée. Nous y ajoutons aussi coté Ruby un scan du code à la recherche de failles éventuelles.
Outils utilisés : Bitbucket Pipelines, CircleCI, brakeman
Pour mesurer la couverture de test et nous assurer que nous sommes au-dessus de 90%, nous utilisons les outils intégrés par les librairies de tests. Pour avoir une vision d’ensemble sur un projet qui contient plusieurs applications, nous agrégeons les différentes couvertures de tests. Ensuite, nous les pondérons en fonction du nombre de lignes de code sur les différentes applications du projet. Par ailleurs nous mesurons aussi la dette technique. Elle est mesurée en fonction de critères tels que le linter choisi, la complexité, le nombre de conditions, de variables… Nous considérons qu’une dette technique acceptable se situe en dessous de 5%. Nous faisons donc le nécessaire pour rester en dessous de cette valeur. Avoir toutes ces informations en un seul et même endroit nous permet d’avoir une vision claire de la santé de la codebase et savoir où diriger nos efforts pour l’améliorer.
Outil utilisé : CodeClimate
Recette
Sur chaque projet que nous réalisons, nous mettons en place un serveur de pré-production. Ce serveur est très proche de la production en terme de configuration et de données (sans données client). C’est sur cet environnement que le Product Owner aura le loisir de tester les nouvelles fonctionnalités en conditions réelles et de valider ou non le passage en production.
Outils utilisés : Docker et Docker Compose
Nous n’avons pas d’équipe QA, c’est donc l’affaire de tous, du Product Owner aux développeurs. Tout le monde est responsabilisé pour produire des applications de qualité.
Comme vous avez pu le voir, chez Leikir Web nous prenons la qualité de nos réalisations très au sérieux. Et vous quelles sont vos b onnes pratiques ?
Originally published at web.leikir.io on October 10, 2018.
