La question du choix d’un Bug Tracker pour une équipe de développement se pose à un moment ou un autre. L’offre, commerciale ou open source, est plutôt importante, et le choix loin d’être évident… L’utilité d’une telle application de suivi des bugs, elle, est évidente quand l’équipe des développeurs s’étoffe et que le nombre d’applications maintenues par l’entreprise augmente. Sans un outil de suivi performant et pratique, il devient difficile de suivre correctement les remontées utilisateur en cours de développement et même lors des mises à jour…
Nous sommes aujourd’hui 4 développeurs dans l’équipe et nous gérons des dizaines d’applications développées pour nos clients, que ce soient des sites ou des applications web ou encore des systèmes FileMaker Pro. Que ces applications soient en cours de développement ou en exploitation, à l’occasion de leur mise à jour, les phases de tests, internes ou lors des retours utilisateurs, génèrent des dizaines de mails ou de coups de fil qui sont autant d’interventions à noter pour améliorer le code et livrer des logiciels opérationnels.
Depuis quelques temps, l’idée d’avoir un espace commun à l’équipe, une interface dans laquelle les développeurs et les clients pourraient suivre l’évolution des projets, noter les bugs et dysfonctionnements, se faisait sentir chez E SYSTEMES…
Le suivi, finalement anarchique, par email, les notes à droite, à gauche… Un suivi opérationnel correct n’est plus possible de cette façon ! Pour structurer l’organisation, optimiser la production et finalement améliorer encore le service et la qualité des produits nous avons cherché, il y a plusieurs mois, à mettre en place un système de gestion des bugs.
Quelle interface pour centraliser le suivi des bugs et les TODOS ?_
Notre première recherche nous a confronté à des interfaces peu aguichantes et des applications apparament compliquées à mettre en place et je me suis d’abord lancé, dans l’esprit “on n’est jamais mieux servi que par soi-même“ dans le développement d’une solution maison. Et comme notre gestion commerciale est développée dans l’environnement FileMaker pro, la première ébauche de notre outil de suivi sera développée dans ce cadre…
Une interface simple : un bon point ! Un titre, un champ, un sélect pour l’attribution, un autre pour l’état du commentaire…
Une première démarche interessante, mais… Trop simple… De plus, l’équipe n’adhère à l’installation de FileMaker en plus de ses outils. Il nous faut un outil utilisable dans un navigateur, le soft ouvert en permanence sur nos écrans…
Et enfin, pourquoi vouloir ré-inventer la roue quand d’autres ont déjà planché sur le sujet avec talent et expérience ? On voit là tout l’intérêt des projets libres développés par les communautés.
En route pour les trackers du monde de l’open source_
Une simple recherche sur le web permet de cerner rapidement l’offre disponible en matière d’application. On trouvera de nombreux articles sur le sujet, souvent des compilations sous forme de listes comme dans ces articles :
- Sur 4lw.fr (FR) Quand le besoin d’un gestionnaire de bug se fait sentir
- Sur open-libraries.com (EN) List of open source defect tracking systems
- Sur thegeekstuff.com (EN) Top 10 Open Source Bug Tracking System
- Sur wikipedia (EN) Comparison of issue tracking systems
Ces lectures sur le web nous permettent de nous faire rapidement une photo de l’offre dans le domaine.
Apparamment, Bugzilla semble être l’un des plus utilisé dans la communauté open source par les équipes de multiples projets, et non des moindres (Apache, Gnome, RedHat…). Nous l’écartons pour l’instant, pour des questions d’installation et de suivi, car il est développé en Perl. Il faut bien des critères.
Redmine est bien tentant aussi. Ecarté aussi car développé en Ruby On Rails. Le fameux language, dont nous suivons l’évolution par ailleurs, nécessiterait également des efforts de configuration serveur supplémentaires.
Nous concentrerons nos investigations sur des projets “pur” Apache / PHP / mySQL correspondant à la configuration courante de nos serveurs en production.
Le projet est d’avoir une appli de type web, à installer sur un de nos environnements serveur disponible pour la maintenir et la mettre à jour facilement.
TinyIssue, basique… Juste par curiosité.
Hyper basique même, dans l’esprit de notre primo développement sous FileMaker Pro, en version web. Installation simplissime. Tiny issue est opérationnel en 10 minutes.
Une interface zen claire et moderne. On crée des projets, des utilisateurs et des “issues” (ou événements, les fameux “bugs”), un titre, une description… Point barre ./
Pourrait convenir pour centraliser des notes de développement, mais trop basique pour notre organisation… On a besoin d’assigner des états de résolution, créer des versions de développement, poser des deadlines… Sympa, mais la belle interface ne suffit pas…
The Bug Genie : la belle promesse.
Ce bug tracker nous a séduit pour son interface et ses fonctionnalités. On a fini par l’installer sur un mutualisé, et on a commencé à l’utiliser en prod pour le tester plus à fond.
On peut y gérer les versions des projets et des jalons ou dates de remise, un workflow complet grâce auquel on suit l’évolution des bugs de leur création à leur résolution… Une gestion des utilisateurs avancée, avec des profils et leurs droits associés… Un wiki intégré pour la documentation des projets… Une interface localisée en français… Bref, prometeur… Mais…
Dans la version française, certaines fonctionnalités… Ne fonctionnent plus. Et notamment le planning et la feuille de route des projets. En français, impossible de créer un jalon pour le projet. Un bug connu depuis un moment mais non résolu.
Tout en ajax, le logiciel est trop lent à l’usage, le temps d’attente entre les écrans est rédhibitoire entre les clics…
Lorsque nous avons essayé, dans le but d’améliorer les temps de réponse, d’installer The Bug Genie sur un serveur local nous avons été confronté à des problèmes de version de PCRE (Perl Compatible Regular Expressions) sur nos serveurs, un composant logiciel indispensable au bon fonctionnement du soft…
On en arrive finalement à se demander si le développement est toujours suivi par l’équipe du projet… Bref, tous ces élements nous poussent donc à finalement abandonner ce tracker de bug, pourtant prometteur sur pas mal d’aspects.
Mantis BT : le choix final, mais redécoré !
Nous avons finalement choisi Mantis BT. Certains l’ont déjà utilisé dans l’équipe et n’en gardent pas un trop mauvais souvenir. Mantis a tout ce qu’il faut, avec en plus une documentation, certe austère et très technique, mais complète. Les réglages et surtout l’évolution de la configuration sont quasi sans limite, tant qu’on veuille bien tripoter de la variable dans les fichiers de config. Mais après tout, nous sommes développeurs, non ? Cette démarche nous convient. On ira personnaliser les état des bugs, les étapes du workflow pour que Mantis se plie à notre façon de voir les événements et les étapes du développement !
Un système de gestion des plug-in est disponible pour ajouter facilement des fonctions développées par la communauté à l’outil. Comme par exemple la capacité pour l’application d’écouter et de relever une boite mail dédiée, d’analyser les messages reçus et enfin de créer des rapports de bug en envoyant un simple e-mail. une fonction intéressante pour permettre, par exemple, aux clients ou aux utilisateurs finaux de remonter des expériences dans les projets, sans avoir spécialement un accès direct au tracker…
Ce potentiel d’adaptation à l’organisation est prometteur, une fois qu’on a capté l’architecture du développement…
Seul bemol, c’est l’interface de base qui vraiment pas joasse… Mais on a fini par trouver dans la communauté, plutôt vaste et active, un designer qui s’y est attaqué, et plutôt avec bonheur…
Et voilà ! L’essayer, c’est l’adopter. Mantis Bug Tracker est en production depuis quelques semaines chez E SYSTEMES. L’adhésion de l’équipe est très bonne et je crois sincèrement que la sérénité sur le suivi des projets c’est bien améliorée. Non seulement par l’utilisation d’un tel outil de suivi, mais aussi avec le choix de MantisBT !…