Processo de implantação de desenvolvimento ágil. Onde o controle de qualidade e os proprietários das empresas testam?

Ultimamente, tenho lido muito sobre vários processos de implantação de aplicativos Web usando SVN ou GIT, com o objetivo de redesenhar a forma como implantamos atualmente onde trabalho.

Como acontece com muitos sabores do Agile, presume-se que qualquer coisa comprometida com o master ou o tronco esteja pronta para produção. Tanto o GitHub quanto o Etsy, http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/ , dizem que trabalham com base nisso (embora o Etsy realmente tenha um ambiente de armazenamento temporário).

Esse processo assume que todos os testes de unidade e de CI foram executados. Você executa os testes localmente e no IC e depois confirma o tronco. Portanto, neste momento, seu código é tecnicamente correto.

Seu código pode estar tecnicamente correto, mas os testes funcionais / do usuário podem descobrir mais erros, principalmente quando se trata de testes de front-end.

Minha pergunta é essa. Onde os proprietários de controle de qualidade e de negócios testam as alterações de recursos que você implementou? Na sua máquina de desenvolvimento local antes de se comprometer com o tronco ou em uma máquina de controle de qualidade / preparo?

Se você possui uma máquina de teste que executa o tronco e supõe que todo o código comprometido com o tronco está pronto para produção ... eh .. então em que momento o código foi assinado e é bom entrar em produção, tanto a nível técnico quanto comercial. perspectiva? Se você possui apenas uma máquina de preparo, muitos desenvolvedores e é nesse local que o código deve ser submetido ao controle de qualidade, como você pode implantar a partir do tronco, pois muitas alterações de desenvolvedor aguardam a aprovação.

Eu ficaria interessado em saber como os outros abordaram isso?

Para o melhor ou para o pior, costumo ver isso feito onde os testes são feitos na base da filial e a assinatura do negócio é o que o ponto de verificação deve mesclar ao principal de implantação.

Eu já vi isso feito tanto com o desenvolvimento em "main" com uma ramificação "implantada" separada ou com uma ramificação de "recurso" de desenvolvimento com a principal como "implantada".

o fluxo de trabalho acaba tendo algo parecido com isto:

• codificar algo
• executar testes locais
• faça check-in no ramo de trabalho
• (opcional) servidor de compilação cria testes ant
• Teste de controle de qualidade / negócios
• correções de bugs (volta ao topo)
• mesclar para implantar ramificação
• implantar

Algumas pessoas trabalham em um único ramo, mas se você for fazer testes manuais, isso fica difícil. A maioria das pessoas que encontrei trabalha com a suposição de que qualquer coisa que possa ser implantada no commit e que também funcione em um único tronco esteja fazendo algo pequeno ou que tenha uma quantidade enorme de testes automatizados, OU eles consideram o "deploy" nesta conversa para ser uma construção para um servidor de teste e o processo de controle de qualidade que ocorre entre o servidor de teste e a produção é tratado separadamente.

Temos testes de aceitação automatizados no mesmo ramo de recursos. Quando você faz um candidato à liberação, ele inclui os testes automatizados que você executou para verificar se o recurso é aprovado. Você também testa o candidato a lançamento. Quando tudo passa, você o promove, mesclando-o ao mestre.

Mais sobre esse processo aqui:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Faça o checkout dos comentários também.

Espero que isto ajude,

Adão

Como regra geral, esperar para confirmar antes que o código seja perfeito é metade do tempo recuperando as vantagens do sistema de controle de versão. (Sem muita elaboração, eu diria que, a menos que seja permitido vários check-ins no VCS, não há como reverter meu próprio trabalho!) Portanto, como prática, sempre pedimos que as pessoas mantenham o check-in (dentro de sua filial do SVN ou podem ser confirmados locais, no caso de GIT), o quanto eles quiserem. De fato, quanto mais, melhor.

No entanto, quando chega o ponto em que tudo parece ter sido feito e testado - chamamos de release e depois é mesclado com o tronco. Essencialmente, o controle de qualidade pode certificar o RC efetuando um novo check-out no HEADramo e, se ele / ela okey, é o mesmo que voltar ao tronco.

Então, essencialmente, usamos o conceito de ramificações de tarefas ou ramificações privadas para que as pessoas sejam livres para fazer check-ins quantas forem necessárias. Ao mesmo tempo, o tronco está relativamente livre de qualquer check-in quebrado .