Como você rastreia bugs em seus projetos pessoais? [fechadas]

Estou tentando decidir se preciso reavaliar meu processo de rastreamento de defeitos para meus projetos caseiros. Nos últimos anos, eu realmente apenas rastreio defeitos usando TODOtags no código, e acompanho-os em uma visão específica (eu uso o Eclipse, que possui um sistema de marcação decente).

Infelizmente, estou começando a me perguntar se esse sistema é insustentável. Os defeitos encontrados geralmente estão associados a um trecho de código no qual estou trabalhando; erros que não são imediatamente entendidos tendem a ser esquecidos ou ignorados. Eu escrevi um pedido para minha esposa que teve um defeito grave por quase 9 meses e continuo esquecendo de corrigi-lo.

Que mecanismo você usa para rastrear defeitos em seus projetos pessoais? Você tem um sistema específico ou um processo para priorizar e gerenciá-los?

Fogbugz (licença individual gratuita) se for um projeto demorado ou uma lista simples de fazer (usando tarefas do Google)

Eu normalmente uso um sistema de controle de revisão baseado na Web (Github, Bitbucket, Redmine, Google Code, ...) para armazenar meu código-fonte e rastrear bugs. Se você acha que há um erro em um código específico, pode criar um problema com o número de revisão / lista de alterações / conjunto de alterações e especificar qual arquivo e o intervalo de linhas que você suspeita.

Eu costumava usar uma planilha / arquivo de texto por projeto (os comentários do ToDo no código não são bem dimensionados pelos motivos que você lista; eles são locais no código e, se houver um problema que não seja, ele tende a deslizar pelo rachaduras).

Recentemente, configurei um servidor Redmine na minha rede doméstica. É um pouco pesado para um "time" de um, mas estou trabalhando em alguns projetos no meu tempo livre e tendem a usar as opções Issue Tracker + Repository com talvez a estranha página wiki em lugares mais complexos.

Um amigo meu jura pelo Pivotal Tracker pelos mesmos propósitos, mas meu atual empregador usa o Redmine internamente, então achei que isso me daria alguma prática. Não é ruim.

Para projetos de código aberto, eu apenas uso o rastreamento de problemas do GitHub.

Na verdade, eu instalei o sistema Free MANTIS bugtracker no meu servidor da web hospedado (que eu uso em um blog e outras coisas) e coloquei todos os meus defeitos nisso.

Em outras palavras, eu corro minhas coisas como se fossem profissionais e pagas.

Acho que ajuda a manter uma melhor mentalidade (fechamento de defeitos, etc.), além de ser consistente (ish) com outras práticas comumente usadas na indústria.

Use as notas do TODO no código, etc, também - mas apenas para notas como: "um dia eu preciso tornar isso mais eficiente, o tipo de bolha prejudica o desempenho". Ou para notas mais imediatas sobre onde você chegou quando foi transportado para o jantar :)

Eu uso o programa ToDo List, um código-fonte aberto do codeproject

http://www.codeproject.com/KB/applications/todolist2.aspx

Muito bom e com muitos recursos.

Usamos o JIRA no meu local de trabalho e sou um grande fã dele. Muitos produtos e pessoas envolvidas e gerencia tudo muito bem.

Eu vim procurando uma resposta para isso há algum tempo e, desde então, elaborei um sistema muito elegante e simples, que atende a esses objetivos principais para mim:

Objetivos em ordem de importância:

1. Torne possível inserir uma nova tarefa / bug da maneira mais fácil possível, para que eu possa anotá-la assim que encontrar ou sonhar, e voltar à codificação antes de perder meu lugar.
2. Facilite a visualização e o gerenciamento dos problemas sem muita pesquisa, clique e detalhamento.
3. Facilite a ligação com o controle de versão, para que eu possa descobrir depois quais alterações foram feitas para resolver um problema ou qual tarefa ou bug causou uma alteração específica no código.
4. Facilite a instalação: instalação e configuração mínimas e preço mínimo.

(3 e 4 são menos importantes, e eu teria concordado com um sistema que não os forneceu, mas este fornece).

Etapa 1: obter um projeto no Bitbucket

Eu uso o bitbucket para rastreamento de problemas e controle de versão do git (para um projeto iOS no XCode, por exemplo). Eu olhei para o FogBUGz (sobre o qual li durante anos no JoelOnSoftware) e no GitHub e outros, mas o bitbucket parece ter os melhores recursos gratuitos para pequenas equipes.

Etapa 2: Use o Rastreamento de Problemas do Bitbucket no projeto

Em seguida, configurei o rastreamento de problemas no mesmo projeto de bitbucket. Portanto, meu projeto agora tem um repositório git e rastreamento de problemas.

Etapa 3: facilite o rastreamento de problemas!

Para isso, estou usando cartões Bitbucket, que é um front-end agradável e simples, como o Kanban, para os problemas do Bitbucket. Você só precisa fazer login na sua conta Bitbucket e configurar as colunas que deseja. Eu tenho quatro colunas: Backlog, Next, Bugs e Resolved. (Estou pensando em mesclar Bugs com Backlog, mas não importa por enquanto)

(Esta imagem é do blog Bitbucket Cards, não do meu projeto, portanto, as colunas são diferentes das que eu uso)

Os Cartões de Bitbucket permitem configurar um filtro muito simples para cada lista em que você escolhe o status e tipos de problemas que aparecem na coluna de um cartão. Portanto, openproblemas de status desse tipo bugestão na coluna Bug .

(Este é do meu projeto: é assim que seleciono o que se passa na coluna Bug)

O mais legal é que, quando você arrasta e solta um cartão de uma coluna para outra, ele altera automaticamente o status do problema que o cartão representa para corresponder ao da definição da coluna de destino.

Outra coisa legal dos cartões Bitbucket é que ele não atinge o tempo limite facilmente. Isso é crucial, pois o objetivo de toda essa configuração é facilitar as coisas - portanto, esse sistema funciona para mim, em vez de trabalhar para ele. Abro um marcador na página do meu cartão e ele permanece aberto na guia Chrome o dia todo.

Isso cuida do meu segundo objetivo.

Etapa 4: amarre-o com o controle de versão.

Os problemas do Bitbucket estão intimamente ligados ao controle de versão (assim como a maioria dos concorrentes); portanto, quando eu termino de trabalhar em um problema, eu o comprometo com uma mensagem como "Adicionada a coisa ao problema. Correções # 245". Se eu confirmar isso, empurre e recarregue minha página Cartões de Bitbucket, verei que o problema foi movido para a coluna Resolvido. Legal.

Aqui está o meu terceiro objetivo.

Etapa 5: facilite a criação de problemas.

Você provavelmente acha que toda essa configuração já é muito complicada de configurar, e por que eu gostaria de adicionar outro aplicativo Web ao processo? Bem, lembre-se do meu objetivo principal acima: quero facilitar a adição de uma tarefa que não perco minha linha de pensamento antes de chegar à área de texto para digitá-la, nem quero perder meu lugar no o código quando eu terminar.

Agora, os Cartões Bitbucket me permitem criar tarefas com bastante facilidade, mas é apenas um pouco clicável para atender plenamente ao objetivo nº 1. Você precisa clicar em Criar um problema; então um editor modal aparece; depois de inserir o título do seu problema, você deve rolar para baixo para especificar o tipo (bug / tarefa) e a prioridade; depois clique em criar.

Em vez disso, optei por usar um segundo aplicativo Bitbucket chamado taskrd .

Você pode configurar o taskrd, dando a ele seu login no Bitbucket, e configurá-lo em um marcador e guia, e mantê-lo aberto o dia todo, assim como os cartões Bitbucket. O Taskrd possui um fluxo de trabalho muito mais simples para adicionar uma nova tarefa, apenas digite-a, defina opcionalmente o tipo e a prioridade e pressione o botão Adicionar.

(esta imagem é do blog Taskrd)

Agora é possível argumentar que não vale a pena o esforço de configurar a Taskrd usando os cartões Bitbucket ou mesmo o próprio sistema de entrada de problemas da Bitbuckets. Afinal, com o Taskrd, tenho que clicar em uma guia do meu navegador e clicar em Recarregar na minha página com os Cartões Bitbucket para que ele seja atualizado e obtenha o novo problema que eu adicionei no aplicativo Taskrd. Mas, na verdade, acho que geralmente estou no modo ou no outro: ou estou usando cartões de Bitbucket para organizar o que estou fazendo a seguir, ou para examinar a lista de erros, ou estou ocupado codificando e inserindo tarefas / bugs como eles me ocorrem - tudo no modo de disparo rápido. Para este segundo modo de trabalho, o Taskrd é ótimo: eu apenas o mantenho aberto em um monitor separado e rapidamente insiro problemas enquanto trabalho.

Portanto, isso abrange a meta nº 1.

Meu último objetivo foi a instalação fácil / barata. Bem barato: tudo isso é grátis. O Bitbucket tem repositórios privados gratuitos para até cinco usuários e os outros aplicativos eram gratuitos. A instalação parece não trivial com base no exposto acima, mas na verdade a parte mais complicada foi configurar o git para enviar para o repositório de bitbucket, que será o mesmo em qualquer lugar. Não precisei instalar nada, e conectar os dois aplicativos ao meu repositório de bitbucket foi bastante fácil. Configurar as colunas de cartas como eu gostava delas demorou um pouco para brincar, mas não foi muito difícil.

Lendo isso de volta, posso parecer um pouco exagerado para o Bitbucket - mas realmente não pretendo. É que estou usando esse processo há semanas - depois de anos tentando configurações diferentes para acompanhar o que estou fazendo - e estou realmente pesquisando, então pensei em dedicar um tempo para divulgá-lo para os outros.

Se você estiver familiarizado com o uso de tags TODO no Eclipse, uma simples etapa seria usar o Mylyn . No mais básico, é uma simples lista de tarefas. Mas também associa o contexto às tarefas - clique em uma tarefa para ativá-la, faça algumas coisas e, da próxima vez que você ativá-lo, o Eclipse abrirá as classes relevantes e mostrará os métodos relevantes. De forma ainda mais poderosa, se você mudar para outro sistema de rastreamento de bugs, o Mylyn poderá extrair tarefas desses sistemas e apresentá-las no seu IDE.

Atualmente, a maioria dos downloads do Eclipse inclui o Mylyn como padrão. Basta pesquisar na visualização Lista de tarefas e começar a adicionar tarefas.

Eu uso a licença inicial de US $ 10 para Jira. É barato e eu já o conheço bem do trabalho.

Como outros aqui, eu uso um arquivo de texto ou o rastreador de erros incorporado em qualquer serviço de hospedagem de dvcs.

Muito disso depende de que tipo de "projeto pessoal" é. É algo que jamais verá a luz do dia ou será apenas um experimento? Este projeto está sendo usado pelo público?

Por exemplo, um dos meus projetos pessoais tornou-se moderadamente popular e a criação de um site Get Satisfaction para ele funcionou muito bem. Não é realmente "rastreamento de erros", mas funcionou muito bem para solicitações de erros / recursos.

Meio que surpreso que ninguém tenha dito isso ainda, mas existem soluções distribuídas de rastreamento de bugs que atuam como parte do seu controle de fonte distribuído, ou seja, o banco de dados de bugs vive com o seu código no seu controle de revisão. Implementações conhecidas incluem "Bugs Everywhere", Fossil e Ditz.

Consulte https://stackoverflow.com/questions/773818/distributed-projectmanagement-bug-tracking e https://stackoverflow.com/questions/1851221/distributed-bug-tracker-to-go-with-dvc?rq=1 para uma discussão.

Para meus projetos pessoais, eu uso o Omnifocus.

Atualização: 25/10/2010 Se encontro um bug que não posso ou não quero corrigir imediatamente, adiciono-o rapidamente à caixa de entrada do Omnifocus. Mais tarde, quando estiver fazendo uma revisão, reunirei todas as informações necessárias para corrigir o erro e adicioná-lo ao projeto. Sua posição na lista de tarefas indica sua importância relativa.

Trato os bugs da mesma maneira que os requisitos / recursos na maioria dos aspectos.

Para projetos pessoais, os comentários do TODO e um arquivo de texto com TODOs, bugs etc. geralmente são suficientes para mim.

Uso meu próprio TheKBase (como estou no OSX, uso-o no .Net em uma máquina virtual ou Mono, dependendo do meu humor). Apenas para um usuário simultâneo, mas: Permite múltiplas hierarquias, passando do gerenciador de tarefas para o gerenciador de informações, sem nenhuma etapa intermediária. Além disso, é de código aberto no Github e gratuito (isso é óbvio, eu acho).

Para os curiosos, as instruções estão aqui .

Eu uso o ToDoList para meus projetos pessoais; é leve, gratuito e possui muitos recursos. Não tenho certeza de quão bem ele é dimensionado para projetos de equipe, mas é ótimo trabalhar sozinho. Não tenho certeza de como sobrevivi usando a lista de tarefas interna do Visual Studio por tanto tempo, é uma porcaria.

Usamos uma combinação de JIRA e Google Docs and Spreadsheets. Examinei outras ferramentas, pois nossa instalação do JIRA é mais antiga que a sujeira e não é tão fácil de usar quanto as interfaces mais novas, sofisticadas, de arrastar e soltar.

Eu olhei para Manymoon, Zoho Projects, Insightly, Redmine e Assembla. Vamos experimentar a ferramenta Stand Up gratuita do Assembla . É uma interface de relatórios de campo muito simples, com três perguntas a cada membro da equipe: O que você fez na semana passada? O que você fará esta semana? Quais barreiras estão no seu caminho?

No final, acho que vou continuar com o JIRA, o Google Docs e a ferramenta Assembla Stand Up, pois a combinação me dá tudo o que preciso.

Eu gosto mais do Trac, porque é leve, fácil de usar e fácil de configurar. E o wiki integrado e o elegante navegador de repositório são uma grande vantagem.

No trabalho, usamos o JIRA, que também é bastante agradável, mas não é tão fácil de administrar. E realmente sinto falta de um wiki (a integração com o Confluence não é tão bom) e de um bom navegador de repositório (apenas temos o ViewVC).

Eu tenho usado o Trac nos últimos anos. Eu usei o Bugzilla e o JIRA também. Meus projetos de consultoria pessoal e privada envolvem o Trac simplesmente porque eu estou acostumado a isso e para iniciar um projeto na minha configuração de desenvolvimento pessoal, requer muito pouco esforço, porque o esforço acabou. Eu tenho o trac conectado com tudo o que preciso, incluindo SVN ou Git e Hudson (ou melhor, Jenkins agora).

Em alguns projetos de clientes, geralmente não há escolha a não ser o que eles usam, o que geralmente não é nada ou alguns porcaria, infelizmente. Fico surpreso quando eles têm um rastreador de erros recentemente. Pessoalmente, estou ansioso por uma oferta melhor da comunidade OSS do que o Trac. Faz as coisas, mas hoje em dia parece uma colcha de retalhos.

Não vejo sentido em usar o rastreamento formal de bugs para pequenos projetos individuais. Normalmente, eu apenas mantenho uma lista mental (muito curta) e conserto os bugs à medida que os percebo. É claro que isso não é dimensionável para projetos grandes / com várias pessoas, mas o ponto é que ele não precisa.

Se você usar ReSharper, ele tem um TODO tracker, que lhe mostra uma lista de todos TODOs, NOTES e BUGé na sua solução. Ele também os destaca em seu código, em qualquer cor que você escolher. Acho isso realmente útil em meus próprios projetos.