Modelo de ramificação do Git com QA e ramificações

5

Gostaríamos de usar modelo de ramificação git de Driessen , mas também temos o lado de QA. Acho que entendo como esse fluxo do git funciona, mas ainda não tenho certeza sobre o teste. Por exemplo, tenho cinco novos recursos, cada um deles está em minha própria ramificação e quero fornecer esses recursos ao teste. Agora estou confuso sobre onde fundi-los? Para desenvolver ramo? Em caso afirmativo, o que acontece quando o controle de qualidade recusa apenas dois e eu já mesclei todos os cinco recursos? Eu gostaria de continuar separando recursos em meus próprios ramos, mas eu gostaria de usar um pedido pull para ver os diffs e digitar comentários, mas novamente, em seguida, há um problema em que ramo para mesclar?

Em outras palavras, de acordo com o diagrama, todos os novos recursos (ou seja, 5) devem ser mesclados no ramo de desenvolvimento. Do ramo de desenvolvimento para o ramo de lançamento e depois do ramo de lançamento para o mestre (eu não me importo com os hotfixes agora - eles são bem claros). Mas onde é um espaço para QA e opção eles recusarão alguns dos recursos? O que eu preciso mudar no diagrama? Peço desculpas pelo inglês, faço o que posso.

    
por Jaroslav Klimčík 16.01.2018 / 12:43
fonte

1 resposta

4

Qual modelo de ramificação do Git você deve escolher depende completamente do processo de desenvolvimento que você deseja usar. O popular “git flow” que você mencionou diz respeito a produtos que possuem lançamentos claros e recursos grandes desenvolvidos de forma independente. O ramo de desenvolvimento representa os recursos que devem fazer parte do próximo lançamento.

Isso abre duas oportunidades em que o controle de qualidade pode ser executado: o controle de qualidade pode ser feito orientado a liberação ou orientado a recursos.

Em um processo de controle de qualidade orientado ao lançamento, um ramo de lançamento é iniciado e o controle de qualidade revisa esse estado. Se o controle de qualidade encontrar problemas, você poderá corrigi-los na ramificação do release, que será posteriormente mesclada no branch de desenvolvimento. Isso pressupõe que não haverá grandes problemas que resultariam na rejeição total de um recurso, portanto, você precisa fazer alguns testes antes.

Um processo de QA orientado para o lançamento pode funcionar muito bem com lançamentos semipermanentes, mas regulares, por exemplo, um lançamento por mês. Os desenvolvedores gastam um mês preparando o próximo lançamento. Então o controle de qualidade tem um mês revisando o lançamento. Durante esse período, quaisquer problemas encontrados são corrigidos. No final do mês, a versão pode ser liberada e o controle de qualidade obtém a próxima versão dos desenvolvedores. Isso evita o tempo ocioso tanto para o QA quanto para os desenvolvedores, ao custo de prolongar o tempo de ciclo entre o início de um recurso e seu lançamento.

Em um processo de controle de qualidade orientado a recursos, o recurso é revisado quando é mesclado na ramificação de desenvolvimento. Assim, o estado do ramo de desenvolvimento é sempre QA'd e pronto para lançamento. Isso espalha o risco por um longo período e permite rejeitar um recurso não incluído antes de ser incluído em um lançamento, sem atrasar recursos não relacionados.

A desvantagem é que você pode, no máximo, um controle de qualidade, um recurso de cada vez, ou você pode perder a interferência entre os diferentes recursos. Isso pode ser um gargalo de um processo e desestimula recursos pequenos e facilmente revisados.

Algumas atividades de controle de qualidade também podem ser realizadas antes que qualquer coisa seja mesclada. Por exemplo. Se um recurso envolver alterações na interface do usuário, os testes de UX concentrados poderão ser realizados isoladamente para esse recurso muito antes de serem liberados. Isso requer que os desenvolvedores possam pedir ajuda ao controle de qualidade quando acharem que é útil, sem precisar navegar em qualquer burocracia. Isso também requer que o controle de qualidade seja suficientemente flexível para acomodar essas solicitações.

Todas essas estratégias podem e devem ser combinadas. Quanto mais perto você chega de um lançamento, mais importante é o controle de qualidade, mas o feedback anterior é mais econômico, porque as mudanças podem ser feitas com mais facilidade.

Observe que a automação e o ferramental podem ter enormes benefícios aqui. Isso acelera e agiliza seu processo, o que pode ter um efeito exponencial na produtividade. Isso começa com a automação de criação e implementação simples, para que o controle de qualidade possa executar facilmente o software de qualquer filial que gostaria de revisar. A automação de testes pode liberar o controle de qualidade para realizar tarefas valiosas de alto nível, como validação de recursos, testes de fumaça, testes exploratórios manuais e desenvolvimento de novos cenários de teste. Isso não é específico de nenhum processo ou esquema de ramificação, mas ferramentas sólidas podem facilitar o envolvimento do controle de qualidade no processo de desenvolvimento.

    
por 16.01.2018 / 13:52
fonte