URL: https://linuxfr.org/users/goeb/journaux/small-issue-tracker Title: Small Issue Tracker Authors: goeb Date: 2013年11月04日T22:00:41+01:00 License: CC By-SA Tags: Score: 36 Depuis plus d'un an je développe sur mon temps libre un petit programme de suivi de tickets (parfois appelés faits techniques ou bugs), nommé SMIT (SMall Issue Tracker). Voici un petit retour d'expérience sur ce projet open-source, qui n'est pas encore en version stable. ## Contexte ## J'ai initialement eu l'idée de ce projet car je trouvais les bug trackers existants mal adaptés aux besoins des non-informaticiens. Par exemple dans mon entreprise nous avions besoin d'un gestionnaire de suivi des faits techniques, mais les bug trackers envisagés avaient les inconvénients suivants : * Bugzilla, Jira, Mantis, Request Tracker, Eventum : compliqués à mettre en place car adossés à un serveur lourd (Apache, Nginx, serveur de base de données), longs à configurer ou trop lents à l'usage (JIRA par exemple était lent, peut-être car surchargé de javascript) * Roundup : difficile à personnaliser car les erreurs d'adéquation entre les pages HTML et les scripts Python sont difficiles à comprendre (typiquement quand on ajoute un champ dans la structure de la base de données mais qu'on l'oublie dans le HTML). * Fossil : les identifiants de tickets de 40 caractères me rebutaient, mais je trouvais excellent le principe d'un exécutable tout-en-un * Trac : je ne me souviens plus exactement pourquoi je l'avais écarté * GitHub, Google Code : pas disponibles pour une utilisation interne à l'entreprise Plusieurs parmi ceux-là ne supportaient pas les recherches de texte libre (JIRA et Roundup notamment), c'est-à-dire que si je recherchais "toto", alors les tickets contenant "toto32" n'étaient pas remontés. Ils indexaient uniquement des mots complets. Par ailleurs nous n'avons pas beaucoup de temps à consacrer à l'administration de ce bug tracker, et nous avons un fort besoin de personnalisation des propriétés des tickets, ce qui n'est pas vraiment compatible avec ceux évoqués précédemment. En plus de ce constat, je voulais aussi combler quelques désirs personnels : * expérimenter le langage Erlang * fonder un nouveau projet open-source et le mener au bout Je me suis inspiré des bug trackers précédemment cités : * Fossil pour la rapidité et la simplicité de la ligne de commande * Roundup, Bugzilla et Google Code pour la présentation HTML des tickets Je me suis fixé les objectifs suivants : * faire quelque chose de simple, qui ne fait qu'une chose, mais qui la fait bien et de manière sûre * avoir une installation facile et une configuration des propriétés des tickets simple * faciliter les problématiques de travail hors-ligne et d'archivage * pouvoir gérer dix mille tickets à l'aise, ce qui me semble largement suffisant pour une équipe de 20 personnes pendant 5 ans. * pouvoir "scripter" simplement l'accès à la base de tickets ## Historique ## Les dix premiers mois, j'ai avancé en Erlang. J'ai obtenu un prototype qui avait les principales fonctions (enregistrer de nouveaux tickets, et consulter les anciens). Mais j'ai abandonné Erlang, car en Erlang, installer un petit programme "standalone", ce n'est pas simple. Et puis je peinais un peu, car novice dans ce langage. Je me suis alors orienté vers le C et C++, langages que je connais bien. Et j'ai tout refait, en tirant les leçons du prototype en Erlang. Aujourd'hui, après 4 mois de C/C++, j'ai une première version intéressante à présenter. Je l'utilise de manière personnelle pour noter l'avancement de mes tâches les plus fragmentées. C'est un moyen de l'éprouver. ## Anecdotes ## ### Micro-développement ### Je fais ce qu'on pourrait appeler du micro-développement. Je travaille le soir chez moi, 20 minutes par-ci, 1 heure par-là, et quand j'ai de la chance 2 heure d'affilée. Quand j'ai 20 minutes devant moi je me demande quelle partie je vais avancer, et je cherche une petite bricole à faire, qui tienne en 20 minutes. C'est parfois difficile d'aller se coucher en ayant un code en chantier qui ne compile pas. Mais un avantage de ce mode de développement, c'est que ça oblige à faire de petits pas, en ayant le temps d'y réfléchir pendant la journée et d'imaginer des algorithmes, de prévoir quelle sera la prochaine fonctionnalité, etc. Ce recul m'encourage peut-être aussi à refaire complètement des portions de code mal fichues, dans le but d'éviter les verrues et autres boursouflures. ### Base de données ### Pour la base de données, j'ai voulu faire simple : * des fichiers textes * pas de relationnels entre tables * un système incrémental : les entrées constituent l'historique du ticket, et ce dernier est dans l'état donné par les tickets les plus récents Et cela donne beaucoup de flexibilité. Si par exemple : * les tickets possèdent une propriété "status" qui peut prendre les valeurs "open", "closed" * un ticket particulier a status=closed ("closed" étant enregistré "en dur" dans un fichier texte) * si ensuite on change les valeurs possibles de status en "open", "resolved", "abandonned", alors cela affectera uniquement les tickets modifiés ultérieurement et pas les tickets déjà présents ### Mongoose ### J'ai utilisé le serveur HTTP [Mongoose](http://code.google.com/p/mongoose/) comme moteur. J'aime son code pour sa simplicité. ### Identifiants de tickets en base 34 ### Les identifiants des tickets sont dérivés d'un SHA1 en base 34 (sans les i et o, pour éviter les méprises avec 1 et O quand c'est un humain qui travaille). Puis on raccourcit aux 3 caractères de poids faible pour donner l'identifiant. S'il y a un conflit, on rallonge d'un caractère, etc. Le but est d'avoir des identifiants faciles à communiquer par oral. ### Heroku ### Ma démo est hébergée chez Heroku. Les performances ne sont pas excellentes, mais c'est une offre gratuite. Le système qu'ils ont mis en place est assez ingénieux (upload par "git push"). Autre inconvénient : quand personne ne sollicite le serveur Smit pendant 1 heure, alors Heroku l'arrête, et ne le redémarre que lors de la prochaine requête (l'internaute ne se rend compte de rien). Mais comme l'offre gratuite ne propose pas de stockage de données, les données sont perdues et réinitialisées à celles du dépôt git. ### C++ ### Je n'utilise le C++ que pour : * les conteneurs de la STL (string, list, map) * les méthodes d'objets qui rendent le code compact et plus rapide à écrire. ## Démo et code source ## Petite démo ici : http://smit.herokuapp.com Code source : https://github.com/goeb/smit

AltStyle によって変換されたページ (->オリジナル) /