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

9

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?

— Bazza
fonte

6

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.

— Conta
fonte

Obrigado Bill. Trabalhamos em um ambiente em que os desenvolvedores estão constantemente comprometendo e implantando peças separadas de funcionalidade para o site. Se estiver trabalhando em uma ramificação de recursos, após fazer o check-in da ramificação de trabalho, onde você vê o teste de controle de qualidade / negócios sendo realizado? Se você tiver apenas uma máquina de controle de qualidade na qual os desenvolvedores confirmam ramificações, realisticamente, apenas um recurso poderá ser testado por vez, a menos que você tenha um site e uma instância separada do servidor de aplicativos configurados para cada desenvolvedor na máquina de controle de qualidade. as alterações podem ser testadas isoladamente antes de serem confirmadas no tronco.

— Bazza 16/10

na minha experiência com isso, geralmente não criamos um ramo de recursos separado para cada desenvolvedor, mais como um para cada equipe e criamos um host qa para cada um deles, mesmo que fosse apenas uma máquina de desenvolvimento extra.

— Bill

Aprecie os comentários. Me deu algumas idéias.

— Bazza

2

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

— adymitruk
fonte

@ Adam - Obrigado por isso, e o link. A discussão que houve foi interessante. Alimento para o pensamento.

— Bazza

0

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 .

— Dipan Mehta
fonte