Produza qualidade

Question

Nós temos 3 ramos {dev, teste, lançamento} e terá integração contínua configurar para cada ramo. Queremos ser capazes de qualidades construção atribuir a cada ramo ou seja, Dev - Pronto para teste ...

Alguém tem alguma experiência com este que pode oferecer qualquer melhor abordagem aconselhamento / prática?

Estamos usando TFS 2008 e estamos conscientes de que ele tem qualidades configuração construído. É apenas quando aplicar uma qualidade e que tipo de qualidades que as pessoas usam é o que estamos procurando.

Graças

:)

Answer 1

Seu objetivo aqui é obter a melhor qualidade possível em cada ramo, equilibrado contra o fardo de verificar que o nível de qualidade.

qualidade Permitindo a cair em qualquer ramo é sempre prejudicial. Não pense que você pode deixar o ramo Dev ir para o inferno e depois corrigi-lo antes de se fundir. Ele não funciona bem, por duas razões:

• A recuperação é mais difícil do que o esperado . Quando um ramo é mal quebrado, você não sabe como quebrado que realmente é. Isso porque cada edição couros outros. Também é difícil fazer qualquer progresso sobre qualquer assunto, porque você vai correr em outros problemas ao longo do caminho.

• Deixando queda de qualidade poupa nada . As pessoas às vezes dizem "qualidade, custo, cronograma - escolher qualquer 2" ou algo parecido. A falsa suposição aqui é que você "salvar", permitindo qualidade de deslizamento. O problema é que, assim como a qualidade cai, o mesmo acontece com "velocidade" - a velocidade em que você começar o trabalho feito. A boa notícia é que a manutenção de alta qualidade realmente não custo extra, e todo mundo gosta de trabalhar com uma base de código de alta qualidade.

O compromisso que você tem a fazer é em quanto tempo você gasta Verificar qualidade.

Se você Test Driven Development bem, você vai acabar com um conjunto abrangente de extremamente rápido, testes unitários confiáveis. Devido a essas qualidades, você pode razoavelmente exigir que os desenvolvedores para executá-los antes de check-in, e executá-los regularmente em cada ramo, e exigem que eles passam de 100% em todos os momentos. Você também pode manter a refatoração como você vai, o que lhe permite manter a velocidade alta ao longo da vida do projeto.

Da mesma forma, se você escrever automatizada testes de integração / clientes bem, para que eles sejam executados rapidamente e de forma confiável, então você pode exigir que eles sejam executados, muitas vezes, bem, e sempre passar.

Por outro lado, se seus testes automatizados são escamosa, se eles correm devagar, ou se você operar regularmente com "falhas conhecidas", então você vai ter que recuar sobre a forma como muitas vezes as pessoas devem executá-los, e você gastar muito trabalho tempo com estas questões. É chato. Não vá lá.

Na pior das hipóteses, a maioria dos seus testes não são automatizadas. Você não pode executá-los, muitas vezes, porque as pessoas são muito lento para estas coisas. A sua qualidade de ramo não-liberação vai sofrer, assim como a velocidade da velocidade e desenvolvimento da fusão.

Answer 2

A avaliação da qualidade de uma compilação de forma determinística e reprodutível é definitivamente um desafio. Eu sugiro o seguinte:

1. Se você está configurado para fazer regressão automatizado testando em seguida, todos esses testes devem passar.
2. Os desenvolvedores devem teste de integração cada uma de suas alterações usando uma compilação oficial Dev recém-instalado em uma plataforma oficial e limpo teste e dar o seu selo pessoal de aprovação.

Quando esses dois itens estão satisfeitos para um determinado construção Dev você pode estar razoavelmente certo de que promover esta compilação de teste não será desperdiçar o tempo de sua equipe de QA.