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. :)
Bonne nouvelle !
Enfin, va juste falloir s’habituer.
Hey !
Superbe nouvelle, et merci pour ce comparatif ! Je cherchais également et activement un bug tracker qui soit performant et ergonomique, c’est vraiment le must. :)
Bonne chance et à bientôt. \ô/
C’est sûr que sortir des bonnes vieilles méthodes Efreiennes en ce qui concerne le travail « à l’arrache » ne doit pas être chose facile :D .
En tout cas, bonnes évolutions. Mais c’est vrai que la façon se servir du SVN est un peu bizarre j’avoue ;) .
Pourquoi ne pas avoir créé vous-mêmes un bugtracker ? Ça demandait trop de travail ?
Quelqu’un peut lui répondre ? J’en ai marre d’expliquer pourquoi il est vain de tout vouloir faire soi-même. :D
@Manuu : ça ne sert à rien de réinventer la roue…
J’ai une question. Comment allez-vous faire pour l’intégrer au site (niveau design j’entends)? N’aura-t-on pas l’impression de quitter le sdz? (Ça fait 2 questions ça…)
Cela ne sert à rien de réinventer la roue : c’est une perte de temps considérable et puis au final le bugtracker développé soit même ne sera sans doute pas aussi robuste que ceux que l’ont peut trouver.
C’est un des fléaux de la section « Recrutements pour vos projets » : tout le monde veut recoder ses outils, et en même temps il se fixent des deadlines super proches, et au final beaucoup de projets finissent à l’abandon car personne n’a la motivation de réinventer la roue, et assez souvent pas les compétences.
C’est très compréhensible, moi-même je dois souvent lutter contre le syndrome « Oh, ça doit être vachement intéressant de coder un truc comme ça ! ».
Sauf qu’après 30 secondes de réflexions, on se dit que ça ne sert à rien de réinventer la roue, surtout si c’est pour lui faire un bord carré. Outre le fait que pendant qu’on recode un outil qui existe depuis des années, les projets potentiellement innovants sont au point mort.
Mat n’aime pas de « réinventer la roue ». Pour en savoir plus consulte les commentaires de la news sur le lancement de ce blog -> sur le sdz !
@Manuu : il y a deux explications au fait de ne pas refaire personnellement quelque chose qui existe déjà :
1. les développeurs sont des flemmards donc si c’est fait, autant le réutiliser. Ça c’était l’explication pourrie et plutôt injustifiée qu’on colle généralement à la figure des devs.
2. la deuxième explication tient du fait qu’il ne sert à rien de réinventer la roue pour son plaisir. C’est effectivement mieux en matière de satisfaction personnelle de coder quelque chose de « gros », mais coder implique deux choses : avoir le temps de le faire, et surtout trouver une bonne raison de le faire (la raison d’égo personnel n’en est pas une).
Ici, l’outil convient bien comme il est là. Donc, pourquoi perdre du temps, qui pourrait être consacré à d’autres projets, à recoder un outil performant et qui fait bien ce qu’on lui demande ?
Je m’en charge :D
Il ne sert a rien de réinventer la roue à chaque fois.
Développer un Bugtracker aurait été une perte de temps considérable. Et qui aujourd’hui ne sait pas que le temps c’est de l’argent :D
De plus les système open-source sont en général bien rodé et très efficaces.
Cordialement Melimelo
et pourquoi tu recodes pas un système d’exploitation pour ton pc ?
j’ai testé jira sur le bug tracker, et c’est vrai qu’il est puissant. Les prix semblent s’adresser à de plus gros projets. Aussi, je me demandais quels étaient les point faibles de Redmine ? car si un projet gratuit fait les même fonctions qu’un produit à 5k€ ou va le monde ?
Salut.
En réponse à Manuu.
Sans connaitre parfaitement la situation de nos amis de chez simple it (sdz), voilà ce que je peux dire:
– En informatique, on essaye de ne jamais réinventer la roue ==> Pourquoi passer des dizaines d’heures sur un programme qu’une foule de personne a déja fait, et qui est trouvable gratuitement sur le net, en 3 clics?
– Simple it est une jeune entreprise qui doit tourner. Ils doivent se battre pour être rentables, puis la main d’oeuvre coûte cher. Perdre son temps à créer un logiciel qui existe déja et qui est disponible sur le net est un luxe qu’ils ne peuvent pas se permettre (niveau temps, niveau argent).
– La conclusion est qu’ils ne peuvent pas se permettre de dépenser leur énergie n’importe où. Le peu d’énergie/main d’oeuvre qu’ils ont, ils doivent l’assigner aux tâches dont la priorité est maximale.
– N’oublie pas que simple-it est une entreprise ( =business) qui doit tourner. L’entreprise doit gagner de l’argent. Pour gagner de l’argent, il faut déja éviter d’en perdre là où c’est possible.
Voilà, j’espère que ca répond à ta question.
Bonjour ;
Oui Mathieu, je veux bien commencer une explication ; elle devra être surement complétée ….
Manuu ; SDZ a évolué, et là je vais pas faire le liste..; un conseil: relies tous les articles du blog…essaies de comprendre cette mutation: un excellent site communautaire est transformé en entreprise par son créateur génial (Mathieu…aidé par Zozor sont égérie ).Aujourd’hui pour rendre pérenne son entreprise Mathieu travaille, réfléchit, fait partager ses idées …en tant que Patron responsable… de femmes et d’hommes qui travaillent avec lui.
Si je me rappelle bien, cela fait une dizaine d’année que SDZ existe et il évolue toujours…montrant la « geek attitude de Mathieu » à ses débuts…et aujourd’hui c’est Simple IT …résultat d’une certaine évolution chez Mathieu ;qui gére une Société qui ; c’est sûr a un grand avenir.
Pour une fois q’un patron fait l’effort de tenir un blog pour expliquer à la ville et au monde son travail soyons reconnaissant à cela ; et faisons évoluer nos mentalités.
Cordialement.
En réponse à Manuu, comme M@teo21 l’a déjà dit des centaines de fois :
Ça sert à rien de passer des centaines d’heures à développer un outil qui existe déjà, d’autant plus bien fait.
L’exemple tant utiliser : GESHI ou encore Pygments sur le SdZ, tout le mode a dit : « Pourquoi ne pas développer votre propre système de colorisation syntaxique ? »
Ou encore le blog, à savoir dotclear.
La réponse est au dessus ;)
Si non, je trouve que c’est une super idée le bug tracking, je pense que ça améliorera la gestion des bugs (d’ailleurs, je pense que c’est le but :D)
C’est bon merci, je crois qu’il a eu son lot de réponses ^^
Pour répondre à la question des avantages de Jira par rapport à Redmine Xt-6, je ne les ai pas testé suffisamment en profondeur tous les deux pour pouvoir bien te répondre. Je peux néanmoins dire que Jira :
Mais bon, je dois creuser un peu pour trouver ces différences. Redmine s’il est encore jeune fait vraiment bien les choses. Contrairement à Jira, il intègre un Wiki, un navigateur de repository, etc. Jira ne le fait pas car il t’invite à utiliser d’autres solutions maison (payantes), c’est logique du point de vue marketing mais pas du point de vue de notre porte-monnaie. :p
Très bonne nouvelle !
A propos de Ruby, j’ai jamais utilisé, mais par contre avec django il y a aussi un serveur web inclus, la doc précise bien qu’il doit être dédié au développement.
Personnellement je ne prendrais pas le risque d’utiliser le serveur web embarqué, la première raison qui me vient à l’esprit est qu’un serveur web comme apache est largement plus éprouvé au niveau fiabilité et sécurité.
Pour la configuration ça doit être comme pour le python, tu dois pouvoir faire ça en variantes CGI (FastCGI, WSGI…), ce que j’utilise avec lighttpd, mais apache offre les merveilleux mod_python et, le cas échéant, mod_ruby, qui semblent être des compagnons sympathiques.
Le bugtracker sera lié au SVN, le SVN sera-t-il publique ? En gros, à partir du bugtracker, peut-on voir les codes sources associés aux bugs/corrections apportées ?
Non ^^
Ah ça c’est une excellente nouvelle ! J’avoue que le forum pour gérer les bugs / suggestions, si ça a l’avantage d’être très user-friendly pour des nouveaux venus, niveau gestion en interne ça devient vite assez lourd… Je n’ai jamais essayé de bug-tracker, mais le fonctionnement parait très intéressant, et surtout c’est conçu pour ça (contrairement à un forum !).
Par contre, est-ce que ce bug tracker oblige chacun à se créer un compte ? Si oui, sera-ce lié à la création de compte SdZ. Si non, cela ne sera-t-il pas le bazar ? Il y aura toujours des malins pour poster sous un faux pseudo…
Pour Ryby(OnRails) avec Apache il y a http://www.modrails.com/
Mais je ne pourrais pas plus te renseigner, je n’ai jamais fais de Ruby :)
Question : pourquoi SVN plutôt qu’un truc qui a une vraie gestion des branches (plutôt qu’un copier-coller dans un dossier /branches/) ?
Ça aurait permis :
– De faire du boulot sur les différents modules du site chacun de son côté.
– De maintenir une version de dev à côté de la version de prod et de pouvoir faire des merges entre les deux (et entre les branches de travail et la version de dev) très facilement.
– D’éviter de dupliquer les fichiers, et donc la taille utilisée.
Ça aurait également permi, dans la vue d’une libération du code, de travailler de son côté sur un patch tout en mergant régulièrement avec le trunk.
(L’argument « car c’est plus utilisé » n’en est pas un, car Git est utilisé pour de gros projets comme Linux, Mercurial par des projets comme Mozilla, Perforce par des projets comme Qt, etc.)
À part ça c’est une bonne chose. J’espère juste que les accounts SdZ / Bug tracker ne seront pas liés (de toute façon ils n’ont pas à l’être).
Sinon, je ne sais plus où (sûrement sur un topic de S&C), j’avais vu une remarque de ta part du genre « Trac n’est pas joli par rapport à Redmine ». Je t’invite à aller regarder http://mamelouks.net/ qui est un trac que j’ai skinné et modifié un peu en profondeur dans le but de l’utiliser comme site vitrine de mon projet, et le résultat s’en trouve agréable à l’oeil et user-friendly (bon par contre, il n’a pas le même but que votre bug-tracker car on s’en sert plus pour présenter que pour gérer notre projet, mais c’est juste pour montrer qu’avoir un Trac joli, c’est possible).
Oups, j’ai également oublié de demander : un support OpenID pour le bug tracker est-il prévu ? :)
Remarque que si les comptes sont reliés à ceux du SdZ, il suffira d’attendre que le SdZ supporte OpenID… ça devrait finir par se faire un jour :-° .
vincent1870 : je crois qu’on peut reporter des bugs sans être loggué sur Redmine. Cependant il n’est pas possible (ou c’est relativement compliqué pour pas grand chose) de lier les utilisateurs du site avec ceux du tracker.
C’est libre, donc c’est possible.
Et histoire de critiquer les choix techniques comme j’aime le faire, si tous les accounts étaient centralisés à un endroit adapté (comprendre : un annuaire LDAP), il aurait été facile d’intégrer l’identification à Redmine en utilisant une des features built-in (très bon choix de proposer ça en built-in, ça doit bien aider à l’insertion dans des entreprises utilisant par exemple Active Directory).
En partant du code de cette feature et en le modifiant (car s’il y a cette feature, ça veut dire qu’il y a possibilité d’utiliser différents backends d’auth, et donc simplification de la tâche), on doit pouvoir arriver « facilement » au résultat voulu.
Refs:
– http://www.redmine.org/repositories…
– http://www.redmine.org/repositories…
Le report de bugs sans être loggué est configurable, cf. le :authorize ligne 20 de http://www.redmine.org/repositories… .
À tout casser, c’est codé en 6h en ayant des bases fines comme les miennes en Ruby.
Au boulot j’utilise Mantis mais je reconnais que l’ergonomie est à revoir. Bon courage pour résoudre les bugs ;)
Salut,
C’est marrant ce post car je cherchais justement un BugTracker (autre que mantis, paskesaymoche) que je pourrais mettre sur mon mutu chez ovh (voila la grosse difficulté ! :D).
J’aurais bien utilisé Jira (je pense pouvoir obtenir une licence communautaire gratuite) car je l’utilise au boulot et il faut avouer qu’il est complet et qu’il me surprend tous les jours de par ces possibilités. Mais, sur un mutu, c’est mort, je ne peux pas installer mon petit serveur tomcat.
Là, tu parles de redmine. Je m’empresse de me renseigner sur la bête. Ruby chez ovh, ca existe ,ou plutôt, a existé puisque ca n’a pas évolué depuis juillet 2007…
En effet, Leur installation est ultra lente. Dans les commentaires de ce post : http://forum.ovh.com/showthread.php… , il y a des bonnes idées d’installation de ruby, notamment page 5 à propos de http://www.modrails.com
J’espère que ca aidera. Bon courage.
Moi, je vais me résigné à un mantis, ou chercher de l’argent pour un dédié :D
Je trouve ça très intéressant et économique!
Pourquoi Simple IT devrait dépenser une fortune pour quelque chose de gratuit, et peut-être (sûrement) performant?
MrKooky
Tant mieux pour le bug tracker, peut-être que ça ira plus vite que d’habitude pour résoudre un bug, en plus, Monsieur Mathieu peut faire n’importe quoi pour faire planter tout le site, comme ça, New wave arrivera plus vite que jamais !
Pour l’instant, cette entreprise est quand même liée au SdZ (enfin, je trouve :p)
PS :
Déjà, à propos des commentaire qui disents tout la même chose « ça sert à rien de réinventer la roue »
J’ai envie de vous dire la même chose pour les forums, phpBB fait très bien son travail ? Non ? N’est-je point raison ?
Pourquoi réinventer le livre d’or ? Pourquoi réinventer un système de news ? Hein ?
Je crois que vous serez démunis d’arguments
Plus l’argument ce serait : Simple IT n’as pas de temps pour en créer un.
Bah euh, je veux pas dire mais phpBB c’est de la bouse en boîte quoi. ^^ Les forums sont tellement connus qu’on y trouve une masse de bots, je trouve ça pas ergonomique du tout, et c’est très fouilli. De plus le SdZ dispose de fonctions que phpBB n’a pas. En plus, interfacer phpBB avec le reste du site obligerait à tout baser sur son architecture, ce qui donnerait une mixture infâme.
Pour tout le reste (news, livre d’or), c’est plus ou moins à ça que ressemblait la v2 du SdZ je crois : un assemblage sans cohérence de modules les uns sur les autres. Là le cas est différent, puisque c’est séparé du site (même si personnellement, je ne serais pas trop contre un truc intégré au site, c’est pas vachement dur à faire non plus :) ).
Bonjour.
J’ai une question:
1) quand le BugTracker sera-t-il utilisable?
2)qui pourra aider à traquer les erreurs
3) comment s’inscrire??
Merci
On va l’ouvrir dans les prochains jours, on en parlera dans le forum rapports de bugs, vous saurez tout ce qu’il faut à ce moment-là.
Ca y est, c’est public maintenant. L’annonce sur le SdZ : http://www.siteduzero.com/forum-83-368015-desormais-rendez-vous-sur-bugs-siteduzero-com.html
L’url : http://bugs.siteduzero.com :)
il est parfait!!