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


131

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.


5
Esta questão parece ser mais adequada para programadores , pois não trata de um problema de programação, mas de um processo de desenvolvimento. Alguém pode migrar?


2
Nosso modelo é exatamente o mesmo. Estou interessado em saber como sua equipe de controle de qualidade relata problemas nas ramificações de recursos de maneira diferente dos problemas no campo ou durante o processo UAT (se você tiver um). Usamos o Atlassian JIRA e temos um fluxo de trabalho diferente para os dois.
void.pointer

2
Decidindo a mesma coisa agora. Além disso, como nosso ambiente é um aplicativo java spring, são necessários cerca de 20 minutos para criar e implantar no ambiente de teste. Feliz alguém perguntou as mesmas dúvidas que eu.
digao_mb

A primeira desvantagem não é inerente ao processo de teste nas ramificações de recursos. Ferramentas como Github Enterprise e Bitbucket têm a capacidade de exigir aprovação para solicitações de recebimento e a pessoa responsável pelo controle de qualidade pode aprovar a sinalização ao desenvolvedor de que ele é livre para se unir ao desenvolvimento.
Drek Greer

Respostas:


102

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?


2
Como garantir que o recurso1 e o recurso2 que foram testados independentemente também sejam bons para serem combinados (como mencionado na pergunta)?
Kumar Deepak

2
fazemos indiretamente, mesclando um e depois o outro para desenvolver. É o passo 4 do processo acima e tem a ver com ordem cronológica. Portanto, se o recurso 2 estiver pronto para ser mesclado, mas o recurso 1 já estiver mesclado, o desenvolvedor e o testador do recurso 2 deverão garantir que sua mesclagem funcione.
Aspasia

1
De qualquer maneira, acho que, de acordo com esse modelo de ramificação do git, você não deve mesclar duas ramificações de recursos.
Aspasia

1
Nós encontramos problemas na etapa 6, especialmente em tempos de crise, com vários recursos sendo movidos para o desenvolvimento, devido a mesclagens não triviais que acontecem depois que o controle de qualidade termina no ramo de recursos, apesar de mesclar devlop a recurso o mais tarde possível. Eu comentei em um pouco mais detalhadamente aqui: stackoverflow.com/a/25247382/411282
Joshua Goldberg

8
Você tem um ambiente de teste completo (banco de dados, servidor, cliente etc.) para cada ramo de recurso? Ou será que eles compartilham o Meio Ambiente e apenas têm nomes diferentes (por exemplo app-name_feature1- app-name_feature2, etc.)
hinneLinks

41

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:

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.


Você está dizendo "não use mesclagem, use rebase"? Se assim for, estou confuso, dada a Git FAQ sobre a diferença entre os dois: git.wiki.kernel.org/index.php/...
Vicki Laidler

1
@VickiLaidler sim, se a ramificação do recurso for rejeitada pelo controle de qualidade, o desenvolvedor precisará
refazer a reestruturação

1
@VonC Concordo plenamente, mas há alguns problemas: 1) A exclusão da ramificação afeta outras ferramentas, como Stash Pull Requests (a exclusão da ramificação fecha o PR). Prefira força empurrando. 2) Se for um grande ramo de recursos em que duas pessoas colaboraram durante a vida, as fusões teriam sido preferidas ao rebasing. Rebasing-lo no final cria pesadelo conflito como os commits mesclagem serão removidos, e se o código dependia essas mudanças de mesclagem, é não trivial para correção
void.pointer

1
Olhando para a minha resposta, eu também faria uma reformulação e não uma fusão para uma história mais limpa.
Aspasia

1
@Aspasia Bons pontos. Incluí solicitações de recebimento na resposta para obter mais visibilidade.
VonC 27/07

12

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 .


Você ainda pode fazer IC com ramificações + rebasing no Git.
void.pointer

9

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.


1

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.


1

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: insira a descrição da imagem aqui

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.