Onde a equipe de controle de qualidade deve fazer os testes no modelo de ramificação do Gitflow

Somos uma grande equipe (10 a 12 desenvolvedores e 4 qa) trabalhando em vários projetos com o mesmo repositório git. É um serviço web de back-end baseado em inicialização de primavera. Estamos procurando uma boa estratégia de ramificação e implantação de git. também temos uma equipe de controle de qualidade que garante que nossos recursos funcionem conforme o esperado (sem erros até certo ponto).

Depois de ler alguns artigos, tive a sensação de que o modelo Gitflow funcionaria bem para nós. Aqui vem a minha pergunta.

Onde nossa equipe de controle de qualidade deve testar nossos recursos?

1. eles devem testar na ramificação do recurso, onde irão gerar bugs e o desenvolvedor irá corrigi-lo e, uma vez aprovado no teste de controle de qualidade, fundimos. e o controle de qualidade fará novamente o teste de integração na ramificação de desenvolvimento.
2. devemos mesclar todos os recursos (após testes de unidade e testes básicos do desenvolvedor) para desenvolver ramificações e deixar o teste de qa a partir daí. correções e testes também acontecerão no desenvolvimento.

Estou curioso para saber qual abordagem funcionou bem para os outros.

O controle de qualidade provavelmente deve estar testando duas vezes.

O primeiro teste deve ser em torno das alterações específicas e feito na ramificação do recurso. Isso permite que o controle de qualidade teste as alterações específicas e verifique se a alteração específica está concluída conforme especificado e se comporta conforme o esperado. Também fornece uma visualização antecipada da segunda rodada de testes, que é realmente o que importa para o controle de qualidade.

Vindo da minha experiência em vários ambientes regulamentados, o segundo teste precisa ser feito em uma tag no ramo de desenvolvimento que corresponda a uma liberação, ou no ramo de lançamento, ou talvez no ramo mestre. Antes de uma liberação, o controle de qualidade deveria testar o código completo e completo a ser implantado antes da implantação e você deve poder afirmar que tudo o que foi testado pelo controle de qualidade é exatamente idêntico ao que é implantado na produção. Minha preferência seria que, após um congelamento do código, uma tag fosse aplicada ao ramo de lançamento e o controle de qualidade testaria isso. As alterações seriam feitas em uma ramificação de desenvolvimento, verificadas no local e testadas novamente em uma nova tag na ramificação de liberação. Essas tags no ramo de lançamento corresponderiam aos candidatos a lançamento.

Estou fazendo algumas suposições aqui. Primeiro, você tem uma cobertura de teste um pouco decente, baseada no desenvolvedor. Idealmente, isso seria testes de unidade e integração automatizados que os desenvolvedores executam e o fazem antes de enviar qualquer código em qualquer filial para o controle de qualidade. Os desenvolvedores também podem fazer alguns testes exploratórios em torno da interface do usuário para garantir que as coisas pareçam corretas antes do teste de controle de qualidade. Segundo, existe uma boa coordenação entre o desenvolvimento e o controle de qualidade para planejar as alterações que estão sendo incorporadas para garantir tempo suficiente de controle de qualidade com base nos recursos.

Ótima pergunta. Não acho que exista uma resposta correta "oficial" para isso. Depende de quão rápido você pode testar.

O problema essencial é que cada mesclagem, compilação ou mesmo implantação, potencialmente pode criar um bug. Quanto mais a cadeia você testar, mais cedo você saberá sobre os bugs, mas também terá mais vezes que testar novamente.

Para ter certeza de que você testou o software que os clientes estão usando, você realmente precisa testar a implantação ao vivo antes que o tráfego dos clientes (supondo que um aplicativo Web) seja roteado para esses servidores por meio de um padrão de implantação azul / verde.

Mas, obviamente, é um pouco tarde para ser a primeira vez que você verifica o código!

Se você testar uma ramificação de liberação em um ambiente qa, poderá correr o risco e reduzir o teste ao vivo apenas para testes de fumaça. e aplique correções de erros ao ramo de lançamento. Mas você não pode avaliar se um recurso está completo antes de criar um release

Se você testar o desenvolvimento, obterá mini ramificações de correção de bug. Os recursos ainda são mesclados antes de serem avaliados, além dos recursos para a próxima versão poderem colidir com o teste da versão atual.

Se você testar ramificações de recursos, precisará de um milhão de ambientes e terá que orquestrar a ordem das mesclagens e dos testes de aprovação. além de muitos testes.

Da minha experiência, eu recomendaria:

teste rápido da ramificação de recursos na máquina de desenvolvimento. basta garantir que seu recurso seja concluído e os testadores / desenvolvedores concordem com o que os requisitos significam.

Teste diário / teste automatizado na ramificação de desenvolvimento implantada nos servidores qa. Permite testar todos os recursos juntos e dizer quando você está pronto para o lançamento.

Se todos os recursos estiverem ativados, mas o teste não estiver concluído. por exemplo, o sprint está completo. faça uma ramificação de liberação e implante em um segundo ambiente de qa. Isso permite que a correção / teste de bug na versão 1 continue ao mesmo tempo que os recursos da versão 2.

(os devotos do scrum dirão que você deve colocar apenas correções de bugs no sprint 2, mas vamos ser práticos)

Testes de fumaça na implantação verde / azul ao vivo antes da troca. Isso é super importante, pois você encontrará erros de configuração / ambientais que ninguém realmente procura durante o desenvolvimento.

Eu concordo com Thomas Owens. Você provavelmente deveria estar testando duas vezes. Uma vez na ramificação do recurso antes de ser mesclada e uma vez na ramificação principal antes de liberar.

Na verdade, eu amo tanto o fluxo de trabalho que criei uma ferramenta, o Topico , que cria e executa automaticamente versões descartáveis ​​do seu aplicativo para cada solicitação pull, cada uma com seu próprio URL de teste exclusivo. Isso permite que sua equipe de controle de qualidade teste ramificações de recursos isoladamente, sem a necessidade de algum tipo de ambiente de teste dinâmico configurado em sua própria máquina.

Essa abordagem significa que apenas o código que passou no teste humano chegará ao ramo principal, mantendo assim sua integridade.

Eu a introduzi em algumas empresas e isso ajudou muito nossos ciclos de lançamento. Agora, podemos agendar com precisão os lançamentos, e somos muito melhores para entender o que provavelmente fará parte do próximo lançamento e o que terá que esperar por um lançamento futuro. Apenas lhe dá muito mais confiança.