Qual é a melhor maneira de gerar um registro de alterações de versão preciso?

8

Estou trabalhando em alguns projetos nos quais gostaria de fornecer um registro de alterações preciso a cada versão, mas não encontrei um método para coletar o registro de alterações que funcionaria sem problemas. O problema ocorre principalmente quando o tempo entre as versões é longo e cada versão é fornecida com muitos recursos e correções de bugs, e quando o software tem várias ramificações sendo desenvolvidas ao mesmo tempo.

Algumas opções que eu considerei:

  1. Crie o log de alterações a partir das mensagens de confirmação e exija que os desenvolvedores escrevam as mensagens como se estivessem escrevendo uma linha para o log de alterações (o que eles efetivamente estariam fazendo).
    • Pode não funcionar quando há várias ramificações e a fusão entre ramificações (pode ser difícil saber quais confirmações acabaram no release).
  2. Exija que, para cada alteração no código, exista um ticket correspondente no sistema de rastreamento de bugs. O changelog pode ser escrito com base nos tickets.
    • Os desenvolvedores podem achar frustrante fazer um ticket para alterações ainda menores, especialmente se o ticket demorar mais do que corrigir o bug.
  3. Exija que os desenvolvedores sempre atualizem o log de alterações (como um arquivo de texto na raiz do projeto) ao mesmo tempo em que fazem alterações no código.
    • Parece trabalho manual que pode ser automatizado.
  4. Faça com que o gerente de projetos pegue o diff da versão atual e da anterior e escreva o changelog nesse ponto com base no que eles vêem que foi alterado.
    • Trabalho extra para a pessoa responsável pela liberação e pode não ser óbvio qual é o efeito prático de uma alteração apenas olhando o código.
  5. Envie apenas os recursos que foram planejados para a liberação; você pode escrever o changelog antes mesmo de começar a codificar.
    • Não é uma opção real, a menos que você esteja usando o modelo em cascata.

Eu usei cada um deles ou uma variação deles no passado, mas eles eram muito pouco confiáveis, trabalhosos ou rígidos. Alguém tem uma bala mágica ou boas idéias sobre como resolver o problema?

JJJ
fonte
O controle de qualidade é feito apenas para esse fim.
Mouviciel 5/10
@mouviciel: Eu acho que a maioria das pessoas que trabalham em QA vai discordar com a sua declaração ;-)
Treb
1
@ Treb: Sendo o controle de qualidade, você está certo. O Doc escreve os registros de alterações da versão, apenas garantimos que o que já existe está correto.
Steven Evers

Respostas:

6

Se você ainda não tem o requisito de um ticket para cada alteração, é razoável conseguir que os desenvolvedores criem um ticket para cada alteração importante o suficiente para terminar no log de alterações.

Se a alteração for significativa o suficiente para informar aos usuários, você provavelmente desejará fazer essa alteração sob um ticket de qualquer maneira, e escrever tickets descritivos é uma boa prática. Além disso, você pode associar isso a qualquer versão de versão e roteiro que o seu rastreador de bugs tenha.

Luke Graham
fonte
+1 Isso corresponde ao número 2 da pergunta e é o que eu acho que funciona melhor. Com relação ao subtexto da pergunta em si, você realmente deseja que as pessoas cometam correções de bugs sem tickets?
Sdg 5/10
0

Parece trabalho manual que pode ser automatizado.

Como poderia ser automatizado? Não há necessidade de editar o registro de alterações em cada confirmação, mas apenas quando um recurso que vale a pena mencionar é adicionado. Isso acontece com tanta frequência no seu software que é um incômodo adicionar uma linha ao changelog toda vez?

Tamás Szelei
fonte
0

Você pode dizer que esse é o dever do controle de qualidade de manter o changelog atualizado, mas alguns sistemas de gerenciamento de configuração de software ou rastreadores de problemas podem gerar o changelog automaticamente, o que é útil em um ambiente de múltiplos desenvolvedores. Isso pressupõe que você esteja usando o recurso / problema de rastreamento da maneira como ele se destina.

Por exemplo, o rastreador de problemas de código aberto Trac possui um ChangeLogMacro .

Outros rastreadores de problemas podem ter uma macro ou um plug-in que pode gerar o log de alterações para você. Geralmente, é uma consulta simples para selecionar todos os tickets / problemas que foram encerrados entre a última versão e a versão atual.

Spoike
fonte