La quête du parfait bug tracker

Cela fait un moment que l'on souhaite faire évoluer nos méthodes de développement sur le SdZ. A vrai dire, nous devons passer d'un fonctionnement "à l'arrache" qui s'est créé tout seul naturellement à un fonctionnement plus organisé, plus cohérent lorsqu'on a plusieurs développeurs, et qui nous aide à mieux suivre l'évolution du site.

SVN était la première étape

La première étape a été la mise en place d'un système de versionnement des fichiers (SVN). Non pas que l'idée ne nous ait pas traversé la tête auparavant, mais nous n'avions pas trouvé de façon convaincante de nous en servir (du moins sans remettre en question une partie de notre architecture). Finalement, poussés par Natim et aidé notamment de notre hébergeur, nous avons fini par mettre en place le SVN et à commencer à versionner nos fichiers il y a 6 mois (il était temps !).Nous avons maintenant pris nos repères et trouvé un moyen de nous en servir relativement efficace. Il faut penser que nous travaillons directement sur le serveur pour tester sur une version séparée du site (dite "Version de développement") et que nous n'envoyons les changements sur le SVN qu'une fois que nous sommes satisfaits et que cela fonctionne. C'est donc une procédure assez différente de l'usage que l'on fait classiquement de SVN où l'on récupère tout le code sur sa machine en local, on teste et on réenvoie. Là, tout reste sur le serveur pour des raisons pratiques.

Le bug tracker sera la seconde étape

Avoir un SVN nous a permis d'avoir un meilleur contrôle de l'évolution du code du site. Mais ce n'est pas suffisant et nous souhaitons aller plus loin. Il y a quelques mois, peu après le lancement du SVN, Natim nous a proposé de travailler avec un outil de bug tracking. Nous ne nous étions à vrai dire jamais réellement penchés sur la question.Un bug tracker est un outil, généralement en ligne, qui permet de gérer et de suivre les bugs. Les utilisateurs viennent poster des bugs et les développeurs les confirment, les résolvent, et associent en général le commit correspondant du SVN à ce bug. Cela nous permet de croiser les informations entre le bug tracker et le SVN et de savoir quel bug a engendré précisément quelles modifications pour être résolu.Nous, de notre côté, nous avons dès le début de la v3 mis en place un bug tracker naturel, mais peu efficace : le forum "Rapports de bugs". Naturel parce qu'il suffisait de créer un forum, peu efficace parce qu'il est difficile d'imposer de renseigner tous les champs, de trier les bugs par priorité, de voir quel développeur s'est chargé de quel bug, quels bugs sont liés à ce bug, etc.J'ai entrepris de rechercher une solution efficace pour gérer les bugs. Ca n'a pas été de tout repos, mais je pense aujourd'hui qu'on a trouvé celui qui nous convenait. On a pu voir et tester :

• Bugzilla (utilisé par Mozilla pour Firefox) : très sommaire en apparence, nous avions besoin de quelque chose de plus "sexy" étant donné que nos visiteurs vont être amenés à s'en servir.
• Trac : c'est Natim qui l'avait installé il y a quelques mois. Nous ne l'avons jamais vraiment essayé mais il est populaire en effet. Il s'intègre à SVN, possède un navigateur de code, etc. Toutefois, en voulant creuser un petit peu, je me suis rendu compte qu'il y avait plusieurs problèmes : pas de traduction française à jour (ou en tout cas rien d'inclus) et nécessité d'installer des plugins pour en faire quelque chose de potable (il faut un plugin pour que l'on puisse se créer des comptes utilisateur !). J'ai essayé, installé des plugins, mais je me suis dit que je ne voulais tout simplement pas plus me prendre la tête à ajouter 50 plugins pour en faire quelque chose de potable, sans parler de la configuration à devoir bidouiller en ligne de commande à chaque fois ou presque.
• Jira : payant et priopriétaire, mais considéré par beaucoup comme un des meilleurs. On l'a testé quelques temps, il fallait un plugin pour le lier à SVN, mais sinon ça marchait très bien. La licence était un peu chère toutefois, et nous avons trouvé finalement un autre projet, gratuit et open-source, qui faisait dans l'ensemble aussi bien que Jira.
• Flyspray : sympathique mais assez peu mis à jour, c'était inquiétant. De plus, il ne s'intègre pas à SVN et c'était un des prérequis.
• Mantis : plusieurs personnes me l'ont conseillé. Effectivement il est complet, intégré à SVN et tout, mais... je vois pas comment quelqu'un d'autre qu'un développeur peut accepter travailler là-dedans. On dirait simplement que ceux qui l'ont fait n'ont pas la moindre notion d'ergonomie. Trop de liens et de boutons dans tous les sens, et je ne parle pas de l'esthétique. On l'a essayé, mais par rapport à Jira il n'y avait pas photo. Le seul avantage pour quelqu'un qui n'a pas de serveur dédié, c'est qu'il est codé en PHP et qu'il n'y a donc pas besoin d'installer de logiciels spécifiques pour le faire fonctionner.
• Redmine : et finalement on est tombé sur Redmine, au moment où on commençait à se demander si un bon bug tracker qui nous convienne existait vraiment (à part Jira). Redmine, c'est en gros ce que Trac aurait dû être. C'est son petit frère, mais en globalement bien mieux : déjà, il gère de base les comptes utilisateur, youhou ! \o/

Redmine est codé en Ruby on Rails et gère MySQL, PostgreSQL et SQLite. Il intègre un navigateur de SVN, un éditeur de workflow, des champs personnalisables, un wiki, une roadmap, des stats, un calendrier, un générateur de diagrammes de Gantt, etc. Ergonomiquement c'est juste ce qu'il faut : c'est simple et ça marche bien, on s'y retrouve (ce n'était pas franchement le cas de Mantis). Il ressemble dans l'ensemble pas mal à Trac, mais toute la configuration se fait en ligne. Ah, et j'ai oublié de le mentionner : il est traduit dans de nombreuses langues et la traduction est à jour. ;o)Bref, notre choix est finalement fait. Nous avons commencé à le tester et nous pensons le rendre public et inviter les visiteurs à l'utiliser à partir de la semaine prochaine. Le forum rapports de bugs restera ouvert les premiers temps probablement, le temps d'y déporter les bugs qui doivent l'être.On peut aussi l'utiliser pour les demandes d'améliorations, et on le fera. Toutefois, je pense laisser ouvert le forum des suggestions car c'est un espace d'échange que le bug tracker ne peut pas remplacer. Les améliorations qui sont vraiment souhaitées pourront être envoyées sur Redmine. Libre à nous ensuite de leur assigner une priorité et de les accepter ou pas.Espérons que cette transition ne posera pas de problème et qu'au contraire elle nous aidera à travailler plus efficacement à plusieurs. :)