A referência a erro / problema na mensagem de confirmação é considerada uma boa prática?

11

Estou trabalhando em um projeto em que temos o controle de origem configurado para escrever automaticamente notas no rastreador de erros. Simplesmente escrevemos o ID do problema do bug na mensagem de confirmação e a mensagem de confirmação é adicionada como uma nota ao rastreador de erros.

Eu posso ver apenas algumas desvantagens dessa prática. Se, em algum momento no futuro, o código-fonte for separado do software de rastreamento de bugs (ou os bugs / problemas relatados serão perdidos de alguma forma). Ou quando alguém está pesquisando o histórico de confirmações, mas não tem acesso ao nosso rastreador de erros.

Minha pergunta é se ter uma referência de bug / problema na mensagem de confirmação é considerado uma boa prática? Existem outras desvantagens?

programming-practices version-control issue-tracking Christian P
fonte

Respostas:

10

Adotamos essa prática e ela funciona muito bem para nós. A forte integração entre o sistema de controle de versão (VCS) e outros sistemas que usamos, por exemplo, integração contínua, rastreador de erros etc. é extremamente valiosa. Se alguma vez mudarmos algo no futuro, certamente teremos que avaliar os efeitos colaterais, incluindo os links entre o VCS e o sistema de rastreamento de bugs.

Em geral, eu consideraria isso uma boa prática. Para alguns sistemas de rastreamento, existem opções e ferramentas adicionais disponíveis, por exemplo, propriedades de bugtraq para Subversion (SVN). Isso sugere que poucas pessoas veem valor nessa prática.

Manfred
fonte
13

Se você quiser ter certeza absoluta de que nenhuma informação será perdida, mesmo que você possa usar um rastreador de erros diferente no futuro ou os dados do rastreador de algum modo desaparecerem, por que não colocar apenas o ID do problema e uma breve explicação sobre o bug? a mensagem de confirmação?

Correção do bug # 123: o aplicativo travou após o login

Então você ainda tem o link do histórico de confirmações para o rastreador de erros - e se o rastreador de erros já não estiver disponível, você ainda poderá ver no histórico o que era esse bug específico.

Christian Specht
fonte
Na verdade, fazemos isso, portanto, não precisamos mudar para o rastreador de erros toda vez que navegamos no histórico de confirmações.
Christian P
Ok, então eu deixaria como está. IMO, esta é a melhor maneira de fazê-lo!
Christian Specht
1
Sim, bom argumento. Essa foi a minha suposição de qualquer maneira, no entanto. Apenas a identificação do bug / problema por si só não é boa o suficiente na minha experiência. Olhando para o log de confirmação, você ainda deseja ver o significado de cada confirmação, por exemplo, qual foi o motivo principal dessa alteração de código. Às vezes, a mensagem de confirmação é mais do lado técnico, enquanto o texto para o sistema de rastreamento de bugs é mais voltado para os usuários do software.
Manfred
Essa tem sido geralmente a prática padrão em que também trabalhei, acho que é o caminho certo para fazê-lo.
Carson63000
+1 sempre faça isso! Acabei de fazer a manutenção de um projeto cheio de gemas como "isso pode ter sido a causa do bug 5423". Não temos acesso ao rastreador de erros.
Kryptic
2

Essa é uma prática muito comum e achei extremamente conveniente. Eu uso o TRAC, para poder ler o histórico de códigos e navegar até a tarefa que conduziu a alteração, ou ler o histórico de tarefas e navegar até as alterações no código.

"Se em algum momento no futuro ..." Se você separar o código do rastreador de erros, o histórico de revisões antigo provavelmente não será mais interessante.

Kevin Cline
fonte
2

Também uso essa prática e considero muito boa. Mas, além do ID do problema, adiciono uma breve descrição do bug / recurso (geralmente o título do sistema de rastreamento de erros). Isso geralmente ajuda a economizar tempo, porque não preciso pesquisar no sistema de rastreamento de bugs (porque reconheço a alteração) E, como você disse, se de alguma forma eu perco o sistema de rastreamento de bugs, não estou completamente perdido.

Nicolae Albu
fonte