Comment suivez-vous les bugs dans vos projets personnels?
J'essaie de décider si je dois réévaluer mon processus de suivi des défauts pour mes projets locaux. Depuis plusieurs années, je ne fais que suivre les défauts en utilisant les balises TODO dans le code, et en gardant une trace dans une vue spécifique (j'utilise Eclipse, qui a un système de marquage décent).
Malheureusement, je commence à me demander si ce système n'est pas viable. Les défauts que je trouve sont généralement associés à un extrait de code sur lequel je travaille; les bogues qui ne sont pas immédiatement compris ont tendance à être oubliés ou ignorés. J'ai écrit une demande pour ma femme qui a un défaut grave depuis près de 9 mois, et j'oublie toujours de la réparer.
Quel mécanisme utilisez-vous pour suivre les défauts de vos projets personnels? Avez-vous un système spécifique ou un processus pour les hiérarchiser et les gérer?
Fogbugz (licence individuelle gratuite) s'il s'agit d'un projet assez long ou d'une liste de tâches simple (à l'aide de tâches Google)
J'utilise généralement un système de contrôle des révisions basé sur le Web (Github, Bitbucket, Redmine, Google Code, ...) pour stocker mon code source et suivre les bogues. Si vous pensez qu'il y a un bogue dans un code spécifique, vous pouvez créer un problème avec le numéro de révision/la liste des modifications/l'ensemble de modifications et spécifier le fichier et la plage de lignes que vous suspectez.
J'avais l'habitude d'utiliser une feuille de calcul/fichier texte par projet (les commentaires ToDo dans le code ne s'adaptent pas bien pour les raisons que vous indiquez; ils sont locaux pour le code, et s'il y a un problème qui ne l'est pas, il a tendance à glisser à travers le fissures).
Récemment, j'ai installé un serveur Redmine sur mon réseau domestique. C'est un peu lourd pour une "équipe", mais je travaille sur pas mal de projets à mon rythme, et j'ai tendance à utiliser simplement les options Issue Tracker + Repository avec peut-être la page wiki étrange dans des endroits plus complexes.
Un de mes amis ne jure que par Pivotal Tracker aux mêmes fins, mais mon employeur actuel utilise Redmine en interne, alors j'ai pensé que cela me donnerait un peu de pratique. Ce n'est pas mauvais.
Pour les projets open source, j'utilise simplement le suivi des problèmes de GitHub.
J'ai en fait installé le système de bugtracker Free Mantis sur mon serveur Web hébergé (que j'utilise pour un blog et d'autres choses), et y ai mis tous mes défauts.
En d'autres termes, je gère mes affaires comme si elles étaient professionnelles et payantes.
Je trouve que cela aide à garder un meilleur état d'esprit (fermeture des défauts, etc.) tout en étant cohérent (ish) avec les autres pratiques couramment utilisées dans l'industrie.
Utilisez également les notes TODO dans le code, etc., mais uniquement pour les notes comme: "un jour, je dois rendre cela plus efficace, le type de bulle nuit aux performances". Ou pour des notes plus immédiates sur l'endroit où vous vous êtes levé lorsque vous avez été transporté pour le dîner :)
J'utilise le programme ToDo List, un code open source de codeproject
http://www.codeproject.com/KB/applications/todolist2.aspx
Très agréable et avec de nombreuses fonctionnalités.
Nous utilisons JIRA sur mon lieu de travail et j'en suis un grand fan. Beaucoup de produits et de personnes impliquées et il gère tout cela très bien.
Je suis venu chercher une réponse il y a un certain temps et j'ai depuis élaboré un système très soigné et simple, qui répond à ces objectifs clés pour moi:
Objectifs par ordre d'importance:
- Permettre de saisir une nouvelle tâche/bogue aussi facilement que possible, afin de pouvoir le noter dès que je le repère ou le rêve, et revenir au codage avant de perdre ma place.
- Rendez-vous facile à voir et à gérer les problèmes sans beaucoup de recherche, de clic, d'exploration.
- Facilitez la connexion avec le contrôle de version afin que je puisse découvrir plus tard quelles modifications ont été apportées pour résoudre un problème, ou quelle tâche ou bogue a entraîné une modification spécifique du code.
- Rendez-le relativement facile à installer: installation et configuration minimales et prix minimal.
(3 et 4 sont moins importants, et j'aurais été d'accord avec un système qui ne les fournissait pas, mais celui-ci le fait).
Étape 1: obtenir un projet dans Bitbucket
J'utilise bitbucket pour le suivi des problèmes et pour le contrôle de version git (pour un projet iOS dans XCode par exemple). J'ai regardé FogBUGz (dont j'ai lu pendant des années sur JoelOnSoftware) et GitHub et d'autres, mais bitbucket semble avoir les meilleures fonctionnalités gratuites définies pour les petites équipes.
Étape 2: utiliser le suivi des problèmes Bitbucket dans le projet
Ensuite, j'ai configuré le suivi des problèmes dans le même projet bitbucket. Donc mon projet a maintenant un dépôt git et un suivi des problèmes.
Étape 3: simplifiez le suivi des problèmes!
Pour cela, j'utilise Bitbucket Cards qui est un front-end agréable et simple de type kanban pour les problèmes de Bitbucket. Il vous suffit de vous connecter à votre compte Bitbucket et de configurer les colonnes que vous souhaitez. J'ai quatre colonnes: Backlog, Next, Bugs et Resolved. (Je pense à fusionner Bugs avec Backlog, mais tant pis pour l'instant)
(Cette image provient du blog Bitbucket Cards, pas de mon projet, donc les colonnes sont différentes de celles que j'utilise)
Les cartes Bitbucket vous permettent de configurer un filtre très simple pour chaque liste où vous choisissez le (s) statut (s) et le (s) type (s) de problèmes qui vont dans une colonne de carte. Ainsi, open les problèmes d'état du type bug vont dans la colonne Bug .
(Celui-ci est de mon projet: c'est ainsi que je sélectionne ce qui se passe dans la colonne Bug)
Ce qui est vraiment cool, c'est que lorsque vous faites glisser et déposez une carte d'une colonne dans une autre, cela changera automatiquement l'état du problème que la carte représente pour correspondre à cela dans la définition de la colonne de destination.
Une autre bonne chose à propos des cartes Bitbucket est qu'elles ne s'arrêtent pas facilement. Ceci est crucial car le but de toute cette configuration est de le rendre facile - donc ce système fonctionne pour moi au lieu que je travaille pour lui. J'ouvre un signet sur ma page de carte et elle reste ouverte sur un onglet Chrome toute la journée.
Cela prend soin de mon 2e objectif.
Étape 4: associez-le avec le contrôle de version.
Les problèmes de Bitbucket sont étroitement liés au contrôle de version (comme pour la plupart des concurrents), donc quand j'ai fini de travailler sur un problème, je le commets avec un message comme "Ajouté le truc à tout le monde. Corrige # 245". Si je valide cela, puis pousse, puis recharge ma page de cartes Bitbucket, je verrai que le problème a été déplacé vers la colonne Résolu. Cool.
Voilà mon 3ème but fait.
Étape 5: simplifiez la création de problèmes.
Vous pensez probablement que toute cette configuration est déjà trop compliquée à configurer, et pourquoi voudrais-je ajouter une autre application Web au processus. Eh bien, rappelez-vous mon objectif principal ci-dessus: je veux qu'il soit si facile d'ajouter une tâche que je ne perde pas le fil de mes réflexions avant d'arriver dans la zone de texte pour la saisir, ni de perdre ma place dans le code au moment où j'ai fini.
Maintenant, les cartes Bitbucket me permettent de créer des tâches assez facilement, mais c'est juste un peu trop cliquable/défilant pour atteindre pleinement l'objectif n ° 1. Vous devez cliquer sur Créer un problème; puis un éditeur modal apparaît; après avoir entré le titre de votre problème, vous devez faire défiler vers le bas pour spécifier le type (bug/tâche) et la priorité; puis cliquez sur créer.
Au lieu de cela, j'ai choisi d'utiliser une deuxième application Bitbucket appelée taskrd .
Vous pouvez configurer taskrd, en lui donnant votre identifiant Bitbucket, et le définir sur un signet et un onglet, et le garder ouvert toute la journée, tout comme les cartes Bitbucket. Taskrd a un flux de travail beaucoup plus simple pour ajouter une nouvelle tâche, il suffit de la taper, éventuellement définissez le type et la priorité, puis appuyez sur le bouton Ajouter.
(cette image provient du blog Taskrd)
On peut maintenant soutenir que cela ne vaut pas la peine de configurer Taskrd plutôt que d'utiliser des cartes Bitbucket ou même le propre système de saisie des problèmes de Bitbuckets. Après tout, avec Taskrd, je dois cliquer sur un onglet de mon navigateur, puis sur Recharger sur ma page avec des cartes Bitbucket pour qu'il se rafraîchisse et reçoive le nouveau problème que j'ai ajouté dans l'application Taskrd. Mais en fait, je trouve que je suis généralement en mode ou dans l'autre: soit j'utilise des cartes Bitbucket pour organiser ce que je fais ensuite, soit pour parcourir la liste des bogues, soit je suis occupé à coder et à saisir des tâches./bugs comme ils me viennent à l'esprit - tous en mode de tir rapide. Pour ce 2ème mode de travail, le Taskrd est génial: je le garde juste ouvert sur un moniteur séparé, et saisis rapidement les problèmes pendant que je travaille.
Cela couvre donc l'objectif n ° 1.
Mon dernier objectif était une configuration facile/bon marché. C'est bon marché: tout cela est gratuit. Bitbucket a des référentiels privés gratuits pour jusqu'à cinq utilisateurs et les autres applications étaient gratuites. La configuration semble non triviale sur la base de ce qui précède, mais la partie la plus compliquée était vraiment de configurer git pour pousser vers le référentiel bitbucket qui sera le même partout. Je n'ai rien eu à installer et la connexion des deux applications à mon référentiel bitbucket a été assez facile. Mettre en place les colonnes de cartes comme je les aimais a pris un peu de temps mais n'était pas vraiment difficile.
En relisant cela, je pourrais me sentir un peu comme un shill pour Bitbucket - mais je ne le pense vraiment pas. C'est juste que j'utilise ce processus depuis des semaines - après des années à essayer différentes configurations pour suivre ce que je fais - et je le creuse vraiment, alors j'ai pensé prendre le temps de le présenter aux autres.
J'utilise la licence de démarrage de 10 $ pour Jira. C'est bon marché et je le connais déjà bien au travail.
Si vous êtes familier avec l'utilisation des balises TODO dans Eclipse, une étape simple consiste à utiliser Mylyn . À la base, c'est une simple liste de tâches. Mais, il associe également le contexte aux tâches - cliquez sur une tâche pour l'activer, faites des choses, puis la prochaine fois que vous l'activerez, Eclipse ouvrira les classes pertinentes et vous montrera les méthodes pertinentes. Encore plus puissamment, si vous passez finalement à un autre système de suivi des bogues, Mylyn peut extraire des tâches de ces systèmes et les présenter dans votre IDE.
La plupart des téléchargements Eclipse de nos jours ont Mylyn inclus en standard. Recherchez simplement la vue Liste des tâches et commencez à ajouter des tâches.
Un peu surpris que personne ne l'ait encore dit, mais il existe des solutions de suivi des bogues distribuées qui agissent dans le cadre de votre contrôle de source distribué, c'est-à-dire que la base de données de bogues vit avec votre code dans votre contrôle de révision. Les implémentations bien connues incluent "Bugs Everywhere", Fossil et Ditz.
Voir https://stackoverflow.com/questions/773818/distributed-projectmanagement-bug-tracking et https://stackoverflow.com/questions/1851221/distributed-bug-tracker- to-go-with-dvc? rq = 1 pour une discussion.
Comme d'autres ici, j'utilise soit un fichier texte, soit le traqueur de bogues intégré au service d'hébergement dvcs.
Beaucoup dépend du type de "projet personnel". Est-ce quelque chose qui va jamais voir le jour ou est-ce juste une expérience? Ce projet est-il utilisé par le public?
Par exemple, l'un de mes projets personnels est devenu modérément populaire et la mise en place d'un site Get Satisfaction pour cela a très bien fonctionné. Pas vraiment de "suivi des bogues" mais cela fonctionnait très bien pour les demandes de bogues/fonctionnalités.
Pour les projets personnels, les commentaires TODO et un fichier texte avec TODO et bugs etc. me suffisent généralement.
Pour mes projets personnels, j'utilise Omnifocus.
Mise à jour: 25/10/2010 Si je trouve un bogue que je ne peux pas ou ne veux pas corriger immédiatement, je l'ajoute rapidement à la boîte de réception Omnifocus. Plus tard, lorsque je ferai un examen, je rassemblerai toutes les informations dont je pense avoir besoin pour corriger le bogue, puis les ajouter au projet. Sa position dans la liste des tâches indique son importance relative.
Je traite les bogues de la même manière que les exigences/fonctionnalités à bien des égards.
J'utilise ToDoList pour mes projets personnels; il est léger, gratuit et possède de nombreuses fonctionnalités. Je ne sais pas à quel point cela évolue pour les projets d'équipe, mais c'est génial pour moi de travailler seul. Je ne sais pas comment j'ai survécu à l'aide de la liste des tâches intégrée de Visual Studio pendant si longtemps, c'est de la merde.
Nous utilisons une combinaison de JIRA et de Google Docs and Spreadsheets. J'ai examiné d'autres outils car notre installation JIRA est plus ancienne que la saleté et n'est pas aussi facile à utiliser que les interfaces plus récentes, plus sophistiquées, glisser-déposer.
J'ai examiné Manymoon, Zoho Projects, Insightly, Redmine et Assembla. Nous allons expérimenter avec outil de montage gratuit Assembla . Il s'agit d'une interface de rapport sur 3 champs très simple qui pose 3 questions à chaque membre de l'équipe: Qu'avez-vous fait la semaine dernière? Que ferez-vous cette semaine? Quels sont les obstacles sur votre chemin?
En fin de compte, je pense que je vais m'en tenir à JIRA, Google Docs et l'outil Assembla Stand Up, car la combinaison me donne tout ce dont j'ai besoin.
J'aime le plus Trac, car il est léger, facile à utiliser et facile à configurer. Et le wiki intégré et l'élégant navigateur de référentiel sont un gros plus.
Au travail, nous utilisons JIRA, qui est également assez agréable, mais pas si facile à administrer. Et je manque vraiment un wiki (l'intégration avec Confluence n'est pas si géniale) et un bon navigateur de référentiel (nous avons juste ViewVC).
J'utilise Trac depuis quelques années. J'ai également utilisé Bugzilla et JIRA. Mes projets de conseil personnels et privés impliquent Trac simplement parce que j'y suis habitué et que le démarrage d'un projet dans ma configuration de développement personnel nécessite si peu d'effort car l'effort est terminé. J'ai trac connecté avec tout ce dont j'ai besoin, y compris SVN ou Git et Hudson (ou plutôt Jenkins maintenant).
Sur certains projets clients, il n'y a généralement pas d'autre choix que ce qu'ils utilisent, ce qui souvent n'est rien ou de la merde maison malheureusement. Je suis surpris quand ils ont récemment un bug tracker. Personnellement, j'attends avec impatience une meilleure offre de la communauté OSS que Trac. Cela fait avancer les choses, mais ces jours-ci semblent être un tel patchwork.
J'utilise mon propre TheKBase (puisque je suis sur OSX, je l'utilise sur .Net dans une machine virtuelle ou Mono, selon mon humeur). Pour un seul utilisateur simultané uniquement, mais: il autorise plusieurs hiérarchies, il passe donc du gestionnaire de tâches au gestionnaire d'informations sans aucune étape entre les deux. De plus, il est open source sur Github et gratuit (c'est évident, je suppose).
Pour les curieux, les instructions sont ici .
Si vous utilisez ReSharper, il a un TODO tracker, qui affiche une liste de tous les TODOs, NOTEs et BUGs de votre solution. Il les met également en surbrillance dans votre code dans la couleur de votre choix. Je trouve cela vraiment utile sur mes propres projets.
Je ne vois pas l'intérêt d'utiliser le suivi de bogues formel pour les petits projets individuels. Habituellement, je garde juste une liste mentale (très courte) et corrige les bugs quand je les connais. Bien sûr, cela ne s'adapte pas aux grands projets/à plusieurs personnes, mais le fait est que cela n'est pas nécessaire.