Estratégia de ramificação Git integrada ao processo de teste / controle de qualidade

Nossa equipe de desenvolvimento tem usado a estratégia de ramificação do GitFlow e tem sido ótima!

Recentemente, recrutamos alguns testadores para melhorar nossa qualidade de software. A idéia é que todos os recursos sejam testados / controle de qualidade por um testador.

No passado, os desenvolvedores trabalham em recursos em ramificações de recursos separadas e os mesclam de volta à developramificação quando concluídos. O desenvolvedor testará seu trabalho nesse featureramo. Agora, com testadores, começamos a fazer esta pergunta

Em qual filial o testador deve testar novos recursos?

Obviamente, existem duas opções:

• no ramo do recurso individual
• no developgalho

Teste no ramo de desenvolvimento

Inicialmente, acreditávamos que este é o caminho certo a seguir, porque:

• O recurso é testado com todos os outros recursos mesclados à developramificação desde o início do desenvolvimento.
• Qualquer conflito pode ser detectado mais cedo ou mais tarde
• Isso facilita o trabalho do testador, ele está lidando apenas com um ramo ( develop) o tempo todo. Ele não precisa perguntar ao desenvolvedor sobre qual ramificação é para qual característica (ramificações de características são ramificações pessoais gerenciadas exclusiva e livremente pelos desenvolvedores relevantes)

Os maiores problemas com isso são:

• O developramo está poluído com insetos.

  Quando o testador encontra bugs ou conflitos, ele os reporta ao desenvolvedor, que corrige o problema no ramo de desenvolvimento (o ramo de recursos foi abandonado uma vez mesclado) e pode haver mais correções necessárias posteriormente. A subsequência múltipla confirma ou mescla (se uma ramificação for recriada fora da developramificação novamente para corrigir os erros) dificultará a reversão do recurso da developramificação, se possível. Existem vários recursos mesclados e corrigidos na developramificação em momentos diferentes. Isso cria um grande problema quando queremos criar uma versão com apenas alguns dos recursos da developramificação

Teste na ramificação de recursos

Então, pensamos novamente e decidimos que deveríamos testar os recursos nos ramos de recursos. Antes de testarmos, mesclamos as alterações do developramo para o ramo do recurso (acompanhe o developramo). Isso é bom:

• Você ainda testa o recurso com outros recursos no mainstream
• Desenvolvimento adicional (por exemplo, correção de bug, resolução de conflitos) não poluirá o developramo;
• Você pode facilmente decidir não liberar o recurso até que ele seja totalmente testado e aprovado;

No entanto, existem algumas desvantagens

• O testador precisa fazer a mesclagem do código e, se houver algum conflito (muito provável), ele precisará pedir ajuda ao desenvolvedor. Nossos testadores são especializados em teste e não são capazes de codificação.
• um recurso pode ser testado sem a existência de outro novo recurso. por exemplo, os recursos A e B estão sendo testados ao mesmo tempo, os dois recursos não se conhecem porque nenhum deles foi mesclado à developfilial. Isso significa que você precisará testar developnovamente a ramificação quando os dois recursos forem mesclados à ramificação de desenvolvimento de qualquer maneira. E você deve se lembrar de testar isso no futuro.
• Se os Recursos A e B forem testados e aprovados, mas quando um conflito for identificado, ambos os desenvolvedores dos dois recursos acreditam que não é sua própria falha / trabalho porque seu recurso passou no teste. Há uma sobrecarga extra na comunicação e, às vezes, quem resolve o conflito fica frustrado.

Acima está a nossa história. Com recursos limitados, gostaria de evitar testar tudo em qualquer lugar. Ainda estamos procurando uma maneira melhor de lidar com isso. Eu adoraria ouvir como outras equipes lidam com esse tipo de situação.

A maneira como fazemos isso é a seguinte:

Testamos as ramificações de recursos depois de mesclar o código de ramificação de desenvolvimento mais recente. O principal motivo é que não queremos "poluir" o código de ramificação de desenvolvimento antes que um recurso seja aceito. Caso um recurso não seja aceito após o teste, mas gostaríamos de liberar outros recursos já incorporados no desenvolvimento que seriam um inferno. Develop é uma ramificação da qual é feita uma liberação e, portanto, deve estar melhor em um estado liberável. A versão longa é que testamos em várias fases. Mais analiticamente:

1. O desenvolvedor cria um ramo de recurso para cada novo recurso.
2. A ramificação do recurso é (automaticamente) implantada em nosso ambiente TEST com todas as confirmações para o desenvolvedor testar.
3. Quando o desenvolvedor termina a implantação e o recurso está pronto para ser testado, ele mescla a ramificação de desenvolvimento na ramificação de recursos e implementa a ramificação de recursos que contém todas as alterações de desenvolvimento mais recentes no TEST.
4. O testador testa no TEST. Quando termina, ele "aceita" a história e funde o ramo do recurso no desenvolvimento. Como o desenvolvedor mesclou anteriormente o ramo de desenvolvimento no recurso, normalmente não esperamos muitos conflitos. No entanto, se for esse o caso, o desenvolvedor pode ajudar. Este é um passo complicado, acho que a melhor maneira de evitá-lo é manter os recursos o mais pequenos / específicos possível. Diferentes recursos precisam ser eventualmente mesclados, de uma maneira ou de outra. É claro que o tamanho da equipe desempenha um papel na complexidade desta etapa.
5. A ramificação de desenvolvimento também é (automaticamente) implementada no TEST. Temos uma política que, embora os recursos criados pelo ramo possam falhar, o ramo de desenvolvimento nunca deve falhar.
6. Quando atingimos um congelamento de recursos, criamos um release do develop. Isso é implantado automaticamente no STAGING. Testes completos de ponta a ponta ocorrem antes da implantação da produção. (ok, talvez exagere um pouco, eles não são muito extensos, mas acho que deveriam ser). Idealmente, testadores beta / colegas, ou seja, usuários reais devem testar lá.

O que você acha dessa abordagem?

Antes do teste, mesclamos as alterações do ramo de desenvolvimento para o ramo do recurso

Não. Não, especialmente se 'nós' for o testador de controle de qualidade. A fusão envolveria a solução de possíveis conflitos, o que é melhor feito pelos desenvolvedores (eles conhecem seu código), e não pelo testador de controle de qualidade (que deve proceder ao teste o mais rápido possível).

Faça com que o desenvolvedor refaça sua featureramificação por cimadevel e empurre essa featureramificação (que foi validada pelo desenvolvedor como compilando e trabalhando com base no develestado de ramificação mais recente ).
Isso permite:

• uma integração muito simples no ramo de recursos (mesclagem trivial de avanço rápido).
• ou, conforme recomendado por Aspasia abaixo nos comentários , uma solicitação de recebimento (GitHub) ou solicitação de mesclagem (GitLab) : o mantenedor faz uma mesclagem entre o ramo PR / MR do recurso e develop, mas somente se nenhum conflito for detectado pelo GitHub / GitLab.

Cada vez que o testador detecta um bug, ele o denuncia ao desenvolvedor e exclui o ramo de recursos atual.
O desenvolvedor pode:

• consertar o bug
• rebase em cima de uma ramificação de desenvolvimento recentemente buscada (novamente, para garantir que seu código funcione em integração com outros recursos validados)
• empurre o featuregalho.

Ideia geral: verifique se a parte de mesclagem / integração é feita pelo desenvolvedor, deixando o teste para o controle de qualidade.

A melhor abordagem é a integração contínua , onde a idéia geral é mesclar as ramificações de recursos na ramificação do desenvolvedor o mais rápido possível. Isso reduz a sobrecarga de mesclar dores.

Confie nos testes automatizados o máximo possível e tenha as compilações iniciadas automaticamente com os testes de unidade da Jenkins. Faça com que os desenvolvedores façam todo o trabalho para mesclar suas alterações na ramificação principal e forneçam testes de unidade para todo o código.

Os testadores / controle de qualidade podem participar de revisões de código, marcar testes de unidade e escrever testes de integração automatizados para serem adicionados ao conjunto de regressão à medida que os recursos são concluídos.

Para mais informações, consulte este link .

Usamos o que chamamos de "ouro", "prata" e "bronze". Isso poderia ser chamado de prod, preparo e qa.

Eu vim chamar isso de modelo do caldeirão. Funciona bem para nós, porque temos uma enorme necessidade de controle de qualidade no lado comercial, pois os requisitos podem ser difíceis de entender em relação aos técnicos.

Quando um bug ou recurso está pronto para teste, ele entra em "bronze". Isso aciona uma compilação jenkins que envia o código para um ambiente pré-construído. Nossos testadores (que não são super técnicos) apenas acessam um link e não se importam com o controle de origem. Essa compilação também executa testes, etc. Recuamos e avançamos nessa compilação, na verdade, enviando o código ao ambiente de teste \ qa se os testes (unidade, integração, selênio) falharem. Se você testar em um sistema separado (chamamos de lead), poderá impedir que as alterações sejam enviadas ao seu ambiente de qa.

O medo inicial era que tivéssemos muitos conflitos entre esses recursos. Isso acontece quando o recurso X faz parecer que o recurso Y está sendo interrompido, mas é pouco frequente e realmente ajuda. Isso ajuda a obter uma grande variedade de testes fora do que parece ser o contexto da mudança. Muitas vezes, por sorte, você descobrirá como sua mudança afeta o desenvolvimento paralelo.

Depois que um recurso passa no controle de qualidade, o movemos para "prateado" ou estadiamento. Uma construção é executada e os testes são executados novamente. Semanalmente, enviamos essas alterações para a nossa "árvore" de ouro ou produtos e as implantamos em nosso sistema de produção.

Os desenvolvedores iniciam suas alterações a partir da árvore de ouro. Tecnicamente, você pode começar a partir do preparo, já que eles serão lançados em breve.

Correções de emergência são colocadas diretamente na árvore de ouro. Se uma alteração é simples e difícil de controlar a qualidade, ela pode ir diretamente para a prata, que encontrará o caminho para a árvore de testes.

Após nosso lançamento, pressionamos as alterações de ouro (prod) para bronze (teste) apenas para manter tudo sincronizado.

Convém refazer a recuperação antes de entrar na pasta de teste. Descobrimos que limpar a árvore de teste de tempos em tempos a mantém limpa. Há momentos em que os recursos são abandonados na árvore de testes, especialmente se um desenvolvedor sair.

Para grandes recursos para vários desenvolvedores, criamos um repositório compartilhado separado, mas o mesclamos na árvore de testes da mesma forma quando estamos prontos. As coisas tendem a mudar de controle de qualidade, por isso é importante manter seus conjuntos de alterações isolados, para que você possa adicionar e mesclar / squash em sua árvore de preparação.

"Cozer" também é um bom efeito colateral. Se você tiver alguma mudança fundamental, deixe descansar um pouco, pois há um lugar agradável para isso.

Lembre-se também de que não mantemos lançamentos anteriores. A versão atual é sempre a única versão. Mesmo assim, você provavelmente pode ter uma árvore de cozimento principal, na qual seus testadores ou comunidade podem conversar sobre como vários itens de colaboradores interagem.

Eu não confiaria apenas nos testes manuais. Eu automatizaria o teste de cada ramo de recurso com Jenkins. Configurei um laboratório VMWare para executar os testes Jenkins no Linux e Windows para todos os navegadores. É realmente uma excelente solução para testes entre navegadores e plataformas. Testei a funcionalidade / integração com o Selenium Webdriver. Meus testes de selênio são executados sob Rspec. E eu os escrevi especialmente para serem carregados pelo jRuby no Windows. Executo testes de unidade tradicionais sob Rspec e Javascript sob Jasmine. Configurei testes sem cabeça com o Phantom JS.

Em nossa empresa, não podemos usar o desenvolvimento ágil e precisamos de aprovação para todas as mudanças nos negócios, pois isso causa muitos problemas.

Nossa abordagem para trabalhar com o GIT é esta;

Nós implementamos o "Git Flow" em nossa empresa. Estamos usando o JIRA e apenas os tickets JIRA aprovados devem ser colocados em produção. Para aprovação do teste, o extendemos com uma ramificação de teste separada.

As etapas para o processamento de um ticket JIRA são:

1. Crie uma nova ramificação a partir de Develop-Branch
2. Faça as alterações de código na filial do recurso
3. Puxe do recurso as alterações para a ramificação de teste / controle de qualidade
4. Após a aprovação do negócio, extraímos a alteração do ramo de recursos para o desenvolvimento
5. O desenvolvimento ocorre frequentemente em um release e, finalmente, master branch

A divisão de cada solicitação em um próprio recurso garante que apenas as alterações aprovadas foram para a produção.

O processo completo é assim: