Precisamos de uma ramificação separada para corrigir bugs criados durante a fase de testes?

5

Antes de lançar uma nova versão do software, que é um aplicativo da web, minha empresa cria uma ramificação release . A equipe de controle de qualidade testa essa ramificação e relata alguns problemas. Os desenvolvedores devem confirmar o código de correção para essa ramificação release ou uma nova ramificação bugfix que é mesclada à ramificação release depois?

Para mais detalhes, minha empresa usa atualmente uma versão de modificação do modelo gitflow. Nós lançamos uma nova versão a cada duas semanas. As ramificações feature não são mescladas à ramificação dev , mas à ramificação release no início do processo de liberação. Os desenvolvedores confirmam seu código de correção para a ramificação release para corrigir problemas levantados pela equipe de controle de qualidade e, às vezes, esses códigos introduzem novos problemas. Essa é a razão pela qual eu acho que devemos ter outro branch bugfix .

A ramificação bugfix coleta todas as correções para bugs que são gerados do teste da ramificação release . Depois que todos os bugs são corrigidos, a ramificação bugfix é mesclada à release one e a equipe de QA começa a testar a ramificação release outra vez. A ramificação release pode ser testada várias vezes até que não haja nenhum bug a ser corrigido.

    
por Hieu Le 25.11.2016 / 07:08
fonte

3 respostas

2

Se eu acertei você, você tem o seguinte problema:

  • antes de a nova versão ser implantada, sua ramificação de lançamento é atualmente a única que coleta todas as correções. Um desenvolvedor que deseja adicionar uma nova correção (especialmente uma correção a um problema causado por uma correção anterior), não pode testar o teste de forma confiável em uma ramificação de desenvolvimento, porque, nesse momento, as correções feitas antes de não são integrados de volta nas linhas de desenvolvimento .
  • atualmente, a única maneira de sua equipe corrigir esses problemas é verificar a ramificação do release atual, adicionar a nova correção lá, testá-la localmente e depois enviá-la para a ramificação do release. É claro que isso deve ser comunicado corretamente à sua equipe de QA, mas, mesmo assim, pode haver um risco de interferir no trabalho atual de QA.

A introdução de uma ramificação adicional do bugfix permitirá que você adie a entrega imediata de correções para a equipe de QA. Isso tem vantagens e desvantagens. Do lado profissional,

  • permite que seus desenvolvedores testem as correções integradas não apenas localmente antes acessarem o controle de qualidade
  • permite que sua equipe mescle as correções em "release" e entregue-as ao controle de qualidade em um momento controlado melhor, o que pode reduzir a percepção de que seu aplicativo da web é um "alvo em movimento". Você pode coletar algumas correções, e a equipe de controle de qualidade obtém a cada dois dias um novo "pacote" de correções, pode testá-lo.

Por outro lado,

  • você precisa gerenciar essa ramificação adicional e quando as alterações entrarem em "release", o que significa etapas adicionais de mesclagem
  • a equipe de QA não recebe as correções imediatamente quando elas são concluídas.

Note, no entanto, mesmo quando não estiver usando uma ramificação "bugfix", a equipe de QA não recebe necessariamente as correções enviadas imediatamente para sua cópia local. Se eles quiserem a cada dois dias um novo "pacote" de correções, eles apenas aguardam dois dias até que atualizem sua cópia local de "release" para obter as correções. A diferença é: com um branch bugfix, você pode mantê-lo sob melhor controle dos devs, com um branch release somente, o controle é provavelmente mais do lado do QA.

Compare esses prós e contras e decida por si mesmo qual dessas duas abordagens funcionará melhor para sua equipe.

    
por 25.11.2016 / 08:47
fonte
1

O Gitflow sugere que você se comprometa diretamente com o ramo de lançamento

only bug fixes, documentation generation, and other release-oriented tasks should go in this [the release] branch

No entanto, se você tiver vários desenvolvedores trabalhando em uma ramificação de lançamento, faz sentido que eles criem 'ramificações de recursos de lançamento'

Se você está nesta posição, porém, onde você está fazendo muito trabalho em liberações, talvez devesse estar se perguntando se o ramo de desenvolvimento foi concluído em primeiro lugar. Na maioria dos lugares em que trabalhei, fizemos QA no ramo de desenvolvimento, ANTES de criar um release ou passar para o próximo conjunto de recursos.

    
por 25.11.2016 / 10:24
fonte
0

Existem dois tipos de ramificações, ramificações compartilhadas e ramificações próprias. Neste caso, o ramo de lançamento é um ramo compartilhado até o lançamento. É importante manter o estado das filiais compartilhadas limpas, pois muitas pessoas dependem disso. Além disso, a criação de um novo ramo oferece a flexibilidade de desenvolver, testar e liberar independentemente. Até você pode decidir jogar fora e começar de novo.

No caso mencionado acima, corrija os bugs, teste-os e mescle-os para liberar o branch, uma vez que esteja pronto. Espero que isso ajude.

Link: link

- Atualizar -

Depende da sua estratégia de teste adicionar incrementalmente correções para liberar ramificação ou adicionar tudo em uma ramificação e liberá-las. Um único grande branch poderia ser mais difícil de gerenciar, já que o git não é muito amigável ao reverter os commits e mudanças. O Git não vem com nenhuma estratégia ou fluxo de trabalho de ramificação. Cabe a nós escolher o que funciona para nós e muitas grandes empresas publicaram alguns fluxos de trabalho. Na maioria dos casos, prefiro trabalhar com o fluxo de trabalho do git-flow ou do GitHub.

    
por 25.11.2016 / 07:37
fonte