Usando ramificações de teste no Git

Temos alguém (vamos chamá-lo de Ted) que é responsável por testar novos recursos e correções de bugs.

Estamos usando o Git e o GitHub . masterdeve ser / é sempre implantável e developmenté onde confirmamos / mesclamos novos recursos ou correções de bugs, mas somente depois que eles foram testados por Ted.

O projeto está em PHP.

Eu gostaria que o processo de teste fosse assim:

1. Um desenvolvedor quer trabalhar em um novo recurso (digamos que o recurso / bug # 123 como Ted documentado no issue tracker), então ele puxa origin/developmentpara developmentem seu repositório local e cria um novo ramo (digamos issue-123) de lá.
2. Uma vez satisfeito com seu trabalho, ele compromete e empurra seu novo ramo para origin.
3. Ted se conecta test.ourproject.com/choose-branche vê uma lista dos ramos origine escolhe ligar issue-123(deve ser possível através da página da web). Em seguida test.ourproject.com, ele testa o aplicativo da Web (ele é realmente impiedoso) e depois de algumas idas e vindas com o desenvolvedor, ele está feliz com o recurso.
4. Ted diz o desenvolvedor que ele pode mesclar issue-123em developmenton origin.
5. Enxague e repita.

Para a terceira etapa, eu poderia hackear algo que faz o trabalho (mostrando e alternando ramificações de uma página específica), mas acho que o que descrevi é um padrão muito comum.

Portanto, minha pergunta é: esse é um fluxo de trabalho bom / sustentável / sustentável para ramificação? Você pode fazer backup de sua resposta citando alguns exemplos de outros projetos após esse fluxo de trabalho?

O fluxo de trabalho da ramificação parece muito com o gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow e existem ferramentas de suporte. É altamente recomendado.

Se houver apenas um testador, seu fluxo de trabalho de teste parecerá bom, mas se houver várias pessoas, o desenvolvimento poderá se mover entre o início e o término e, é claro, o teste deve ser realizado de maneira ideal após qualquer mesclagem. É aqui que o teste automatizado pode realmente ajudar ou um testador lento (completo) pode nunca terminar!

Outro problema é que, com muitos recursos e ramificações, torna-se tentador misturar e combinar recursos em uma liberação (ou optar por despejar após aceitação e mesclagem) ou talvez se os recursos dependem um do outro. O problema é que se você começar a ser temporário para reescrever o histórico (refazer / excluir uma confirmação ou mesclagem) em uma ramificação PUBLISHED, o que significa que foi enviado para um repositório multidev. Isso está reescrevendo a história pública. Isso pode ser feito para o bem ou para o mal e, mesmo que feito para o bem, possa causar problemas aos incautos, e a melhor prática é evitá-lo, para que a questão nunca seja levantada. No entanto, alguns fluxos de trabalho de ramificação de integração tornam isso muito tentador; portanto, se você tiver uma forte proteção em tais ramificações (por exemplo, restrições de gitolite por usuário) e as pessoas esperarem tal atividade, sempre refaça seu código em uma ramificação, prossiga - com cuidado!

Também gostaria de recomendar a leitura http://sethrobertson.github.com/GitBestPractices/, que discute todos esses assuntos e tem muitas boas referências.

Não tenho certeza de que a página de troca em si seja um padrão comum. A maioria dos projetos provavelmente simplesmente solicita ao testador que verifique com o comando git.

A abordagem geral definitivamente parece razoável.

O Google até escreveu a Gerrit para apoiar estilos semelhantes; é mais sobre revisar o código, mas aprovar a integração normalmente envolve revisar e testar. Geralmente, ele também é interconectado ao servidor de integração contínua, que cria todos os envios primeiro (não sei se eles usam o Jenkins no Google, mas acredito que já vi conectores apropriados em algum lugar).

O próprio Git usa uma ligeira variação sobre o tema. Seu mantenedor possui um script que mescla todos os envios pendentes em uma ramificação chamada pu(para "atualizações propostas", presumivelmente; a ramificação é excluída e recriada toda vez que os envios pendentes são frequentemente redefinidos). Isso é testado por várias pessoas. Se estiver tudo bem, os envios considerados completos serão mesclados next(é o mesmo que o seu development). Caso contrário, alguém testa os envios individuais para ver qual deles está quebrado. Isso facilita um pouco o testador, pois ele não precisa trocar de ramificação na maioria das vezes; eles simplesmente informam se a integração de teste funciona.

Se o seu teste for feito automaticamente e não manualmente, acho que o Travis (um sistema de CI para GitHub) fará o que você deseja - ele executa testes automaticamente em todas as solicitações pull. ( Mais informações sobre esse processo, incluindo capturas de tela. )

Observe que os testes não são executados na ramificação, mas na ramificação após a mesclagem no mestre. (ou seja, o que você obteria após mesclar a ramificação no mestre - você tem certeza de que os testes ainda serão executados com êxito após a mesclagem.)

Se as confirmações forem adicionadas à ramificação, os testes serão executados novamente. (Embora, por algum motivo, adicionar confirmações ao mestre não pareça reexecutar os testes.)