Rastreamento de problemas distribuídos [fechado]

O rastreamento de problemas distribuídos parece uma ideia desafiadora para mim, mas nunca realmente decolou em grande escala. Existe uma boa razão para isso?

Estou ciente:

bugz em todos os lugares
- muito complexo para configurar
- muitos requisitos
- razoavelmente bem-sucedido, usado por alguns grandes projetos
fóssil
- tenta integrar muitas coisas e acaba sendo uma versão um pouco pior de todas elas - exceto talvez a parte de rastreamento de problemas distribuídos, que é decente (provavelmente a melhor que já vi)
vários outros projetos menores
- nenhum dos quais ganhou força

Estou pensando em fazer o meu próprio, mas antes de começar, gostaria de saber por que nenhum dos outros decolou em grande escala.

Questões previstas: (acho que todas podem ser superadas)

mesclar problemas distribuídos à medida que são atualizados é complexo, assim como mesclar qualquer arquivo de código
a continuidade da conversa pode ser destruída, pois os comentários podem chegar a qualquer momento, talvez não no fluxo correto
expectativa do servidor central com problemas atualizados

version-control issue-tracking distributed-computing

— Billy Moon
fonte

Meu ponto 2c é que o rastreamento de problemas distribuído não faz muito sentido de várias maneiras - o objetivo do rastreamento de problemas é manter todos na mesma página para que a centralização seja boa. Se eu quisesse distribuir, usaria o evernote.

— Wyatt Barnett

@ WyattBarnett é uma preocupação válida, talvez atenuada por padrões comportamentais e talvez software. Pessoalmente, vejo a única diferença entre um blog e um site: quantas vezes você o atualiza, não é o mesmo para o rastreamento de problemas distribuído? Se você atualizá-lo com frequência, é o mesmo que verificar uma página da Web com problemas, geralmente não? O único perigo é que as pessoas não atualizem e enviem problemas com frequência, mas desde que haja uma solução com um clique, não é um problema, certo? Entendo que essa necessidade de conectividade está em conflito com um dos grandes benefícios do distributedrastreamento de problemas.

— Billy Lua

Não enviar problemas é o problema nº 1 que eu já vi nos rastreadores de bugs. Como o @JeffO salienta, ter alguns recursos offline é muito mais importante do que ter um sistema distribuído. Da mesma forma, o git é bom, mas o github realmente faz o git valer a pena.

— Wyatt Barnett

@WyattBarnett, é difícil especular como as pessoas reagiriam a uma ferramenta bem formada. Talvez eles tenham maior probabilidade de enviar problemas se for possível fazer offline, e sem conexão / logon explícito. Talvez as pessoas que enviam problemas on-line acabem atrasando suas postagens, se ele estiver disponível offline. Minha intuição é que, se for extremamente simples de pressionar, as pessoas farão isso com frequência, porque se elas criaram um problema, elas querem que o mundo o veja.

— Billy Moon

Como um gerente lidará com dois projetos diferentes com uma sobreposição de membros da equipe? Eles vão querer algum tipo de capacidade de relatório abrangente.

— precisa saber é

Respostas:

Só porque o controle de origem + distribuído foi um enorme sucesso, o rastreamento de problemas + distribuído não é necessariamente uma boa ideia.

O que ganhamos com o controle de origem distribuído e se aplica ao rastreamento de problemas?

Fácil ramificação e fusão : na verdade não. Na verdade, é crucial que todos estejam na mesma página. Portanto, a ramificação seria altamente indesejável.

Desempenho : a quantidade de dados transmitidos por um rastreador de problemas é bastante pequena e todo o trabalho pesado é feito no servidor, portanto, esse não é um problema.

Fluxos de trabalho avançados (push, pull, preparo etc.): os rastreadores de problemas já possuem bons (e geralmente altamente configuráveis) fluxos de trabalho. Portanto, não precisamos de um sistema distribuído para isso. Muito pelo contrário, isso tornaria as coisas muito mais difíceis, pois você precisa lidar com mudanças conflitantes.

Recursos offline : claro, isso seria legal. No entanto, eles também podem ser obtidos sem serem totalmente distribuídos.

Além disso, o controle de fonte (distribuído) é usado quase que exclusivamente pelos programadores. O rastreamento de problemas também é usado por testadores, designers, redatores técnicos, gerentes, marketing e, às vezes, até usuários finais. Essas pessoas menos sem formação em ciência da computação podem ter dificuldades para entender os meandros de um sistema distribuído.

— oefe
fonte

Eu imagino que o rastreamento de problemas distribuídos também funcione como servidor, da mesma maneira que o git. Eu esperava que os desenvolvedores o usassem, com sua configuração local (potencialmente offline às vezes) e outras pessoas o usassem apenas do servidor central. Você acha que isso atenua algumas de suas preocupações?

— Billy Lua

Eu não acho que os conflitos de mesclagem serão um grande problema, pois cada nova entrada em um problema será acompanhada de um carimbo de data / hora; portanto, conflitos de mesclagem devem ser facilmente resolvidos (automaticamente pelo programa) usando esses carimbos de hora. Não espero que o conteúdo existente seja muito alterado. Você acha que isso é realista?

— Billy Lua

Outras pessoas usam o rastreamento de problemas antes de haver um repositório para compartilhar código - ou antes que o repositório seja usado para rastrear o código?

— Billy Lua

Eu imagino que, para pequenos projetos / trabalhos de consultoria, seria muito útil poder adicionar o rastreamento de problemas ao projeto de maneira distribuída. Em seguida, ele se torna parte do arquivo morto do projeto automaticamente e também facilita o rastreamento de algum tipo de problema, sem gerenciá-lo como uma entidade separada. Você vê isso como um benefício potencial?

— Billy Lua

A estreita integração com o VCS permitiria que o rastreador de problemas fosse facilmente atualizado. Se eu codificar algo enquanto estiver offline, posso atualizar o rastreador de problemas integrado - talvez encerrando um problema - e mais tarde, quando estiver conectado novamente, envio todas as alterações ao código e problemas juntos. Você acha que isso é realista / problemático / útil?

— Billy Lua

Não acho que ser descentralizado seja tão importante quanto ter recursos off-line. A integração com o controle de origem é um grande benefício, portanto, você deseja que cada usuário possa lidar convenientemente com as duas tarefas. Quanto mais próximos eles o fizerem, mais continuidade você terá.

Até as equipes mais distribuídas devem ser capazes de montar um servidor da web e um sistema de rastreamento. Seria mais benéfico ter um rastreador de erros central, pois todo usuário precisa apenas de um subconjunto do banco de dados de erros. Os erros são geralmente atribuídos a alguém que pode trabalhar nele individualmente. Não há nada errado em não estar disponível para todos os outros se ele usa algum tipo de sistema de "check-out" que o deixa em um estado somente leitura. Um site também permite que clientes / usuários insiram e visualizem seus próprios tickets.

Você está focado em algo com a necessidade off-line, mas muitos dos problemas que você resolveu podem ser evitados com apenas checando partes do rastreador de erros para trabalhar enquanto estiver desconectado.

Para muitos usuários, uma das melhores ferramentas de integração é o email, especialmente quando você tem pessoas fora da equipe. Não voltarei ao seu site para ver se meu problema foi resolvido. Quero um email com um possível link de resposta para fornecer feedback. Qualquer desenvolvedor que responda a um email de solicitação de alteração, pode enviar uma resposta e rastreá-la no sistema.

— JeffO
fonte

Para mim, faz mais sentido incluir os problemas no projeto VCS, para que todos os problemas estejam disponíveis, e é um problema de relatório extrair os relevantes. Eu acho que a sobrecarga no repositório é aceitável, o que você acha? Quanto a um servidor central, imagino um sistema após o git, onde ele está em sua implementação, totalmente distribuído, mas você é livre para hospedá-lo em um servidor que você chama de central (como o github, por exemplo). Alguma ideia?

— Billy Lua

Os problemas ativos são os relevantes. Não tenho certeza de quanto tempo no histórico eu gostaria que meu banco de dados de erros local fosse. Estou com você no central, semelhante ao github. Penso apenas na parte de rastreamento de bugs como mais uma lista de tarefas vinculada ao código e não uma cópia de todo o banco de dados.

— 21413 JeffO

Essa preocupação está enraizada no problema de filtrar dados irrelevantes? ou do ponto de vista do espaço de armazenamento?

— Billy Moon

@ BillyMoon - Não acho que o armazenamento seja tão problemático quanto o momento de sincronizar as entradas de rastreamento de todos. Pode não ser um grande problema, mas ainda estou colocando-o no contexto de rastreamento de chamadas distribuídas em vez de apenas fazer uma entrada em um site.

— Jeffo

Eu vou ser bem específico sobre produtos reais. Alguns provavelmente vão gostar disso e outros talvez não, mas aqui vai:

Ao longo dos anos, usei várias ferramentas para acompanhamento de problemas, tarefas e projetos. Microsoft Project, Trello e Jira já tiveram seu lugar.

Agora eu uso o Pivotal Tracker. Adoro a sofisticação e a simplicidade de uso e gosto muito da maneira como outras pessoas editam e atualizam tickets, essas alterações também são feitas e destacadas na sua janela, de modo que é de longe o melhor estilo de rede dessas ferramentas que eu ' eu tentei.

Não tenho muita certeza se é isso que você quer dizer com distribuído, mas lá está.

Se fosse, eu me acostumaria e analisaria as deficiências do Pivotal Tracker (se houver) antes de desenvolver uma alternativa.

— Michael Durrant
fonte