Compilação diária vs. Zero Defect

Question

Como é que você vai fazer uma compilação diária e esforçando-se para um ambiente de zero defeito? Será que isso significa que eu nunca chegar a ir para casa até que eu matei todos os bugs no meu novo código? Ou significa que eu simplesmente não verificar o meu código de volta até que eu tenha testado completamente, o que deixa o código efetivamente ramificada por muito mais tempo?

Eu estou trabalhando com um punhado de programadores pela primeira vez (em vez de trabalhar por conta própria, ou com apenas um outro codificador), por isso estou apenas lutando com decisões como esta pela primeira vez. Devemos adotar um processo de desenvolvimento de software?

Answer 1

Sim, por favor adotar um processo de desenvolvimento de software. Há uma variedade lá fora, que eu tenho certeza que mais de um vai caber sua equipe. Mesmo aquele que não é uma combinação perfeita é muito melhor do que nenhum processo em tudo.

Então como é que a minha empresa vai sobre ter compilações diárias e que se esforça para zero-defeitos? Nós executamos nosso pacote de teste antes que o check no nosso código. O único problema para nós é que uma corrida cheia de nosso pacote de teste leva mais de 72 horas, portanto, executar um conjunto limitado de testes de unidade antes de verificar no código. Para o nosso constrói todas as noites, corremos um conjunto de testes que levam cerca de 8 horas para ser executado. Em seguida, nos fins de semana corremos o pacote de teste completo. Cada estágio capturas mais e mais problemas, mas mais de 90% são capturados com os testes de desenvolvedor de 5 minutos e, provavelmente, mais de 98% com os testes noturnos. Isso ainda nos alerta muito cedo para problemas antes que eles saiam aos nossos clientes e custam muito para corrigir.

Answer 2

Simples: Nunca o check-in de código com (conhecidas) erros nele. Isso não significa que você check-in, uma vez por dia. Check-in quando você tem uma mudança significativa implementada de modo que os outros desenvolvedores possam ter acesso a ela.

Nós sempre integrar-se localmente, executar nossos testes contra o código, e quando todos os passes, o check-in. I check-in cerca de 20-30 vezes por dia durante o trabalho. O servidor de compilação pega mudanças e funciona constrói contra o sistema. Integração Contínua (CI) é uma coisa boa. : D

Integração Contínua - Automatize seu Constrói

Comece com a construção de sucesso e mantê-lo assim, tanto quanto possível. É essencial em um ambiente de equipe. Basta lembrar que constrói vai quebrar. Espera-se que eles quebram de vez em quando. É um sinal de que você só inadvertidamente verificado em alguma coisa ruim, e você parar o que está fazendo para fazer o verde de construção novamente. Um servidor de compilação que nunca foi quebrado constrói é um sinal de alerta!

Eu também concordo com a resposta chadmyers: Qualquer que você decidir, ele precisa ser automático e automatizado. A melhor coisa sobre como automatizar ferramentas para fazer esse tipo de coisa para você é que você não precisa mais pensar ou lembrar-se de fazê-lo. Ou como Chad disse, você não parar de fazer isso. Eu poderia recomendar fazer uma recomendação para obter ferramentas CI, mas dê uma olhada aqui: Quais as ferramentas que você usa para compilações automatizadas / Automated implantações? Por quê?

Depois de ter CI, você pode obter maior qualidade se você pode injetar um pouco de humor (e vergonha) através da introdução de um símbolo de construção quebrado! http: // ferventcoder .com / Arquivo / 2008/08/20 / continuous-integração-realce - a-broken-build-token.aspx

Use uma boa ferramenta para compilações automatizadas

A maioria das pessoas em .NET uso da terra NAnt ou MSBuild scripts para ter compilações automatizadas que podem depois ligar para o seu servidor de CI. Se você está apenas começando, a minha sugestão seria usar uppercut , é um insanamente fácil de usar estrutura de construção que utiliza NAnt. Aqui está uma segunda ligação com explicações mais profundas:. uppercut

Ramos vs Trunk para o Desenvolvimento Ativo

Você não teria que ramo a menos que você deixá-tronco abrir apenas para lançamentos (o que significa que todo mundo está trabalhando no mesmo ramo como você). Mas eu teria CI tanto no tronco e do ramo de desenvolvimento ativo.

Processo de Desenvolvimento de Software

Também para responder à pergunta em um processo de desenvolvimento de software, a resposta é um retumbante sim. Mas não se apressar em nada menos que é necessária uma mudança drástica. Escolha um processo que você deseja migrar para e lentamente começar a adoptar processos. E avaliar, avaliar, avaliar. Se o processo particular não está trabalhando para o seu grupo, descobrir se você está fazendo algo errado ou se você só precisa eliminá-lo. E depois fazer. Seja qual for processar você acabar com necessidades para trabalhar para você ou não vai funcionar.

Answer 3

Isso significa fazer commits muito menores. As revisões mais frequentemente se comprometer de trabalho, a menos frequentemente a sua própria cópia de trabalho está sempre quebrado. começa o desenvolvimento iterativo com você.

Answer 4

Integrar cedo, integrar frequentemente, integrar rapidamente. Ao invés de uma 'compilação diária', construir cada vez que alguém comete e cometer muitas vezes (pelo menos uma vez por dia, de preferência mais do que 2).

Importante: o feedback rápido é necessário para baixo defeito. Se a sua construção leva muitos minutos ou mesmo mais de uma hora, eventualmente, você vai crescer a odiar a construção, aprender a evitá-lo, executá-lo o mínimo possível, etc. É um valor cai rapidamente ao ponto de ser inútil e sua vontade contagem de defeitos começar subindo rapidamente.

Invest algum tempo na frente para obter a sua construção correndo rápido. Se há coisas lento, descobrir por que ele é lento e eliminar isso. Se você não pode, então, pelo menos, criar uma cascata constrói para que o resto da compilação passa rápido (pense <2-5 minutos) e o material de longa duração pode seguir imediatamente após e demorar tanto tempo como ele quer (embora try para mantê-lo sob topos 10m).

Não posso dizer o suficiente: ciclo de feedback rápido sobre as mudanças é extremamente importante

Answer 5

O truque é o check-in o mais rápido possível, só fez alguns testes passar, agradável check-in! Corrigido um único erro, check-in! Tente encontrar as smalles incrementar possível e check-in! Isto tem a vantagem de, na verdade, tornando-se possível e convinent aos comentários write checkin que realmente são tão relevantes isso é um bônus agradável.

Claro que requer que você tenha um ambiente de CI que constrói mais frequentemente do que o noturno, o mais rápido possível é realmente a melhor opção lá.

Ah, e lembre-se, se não quebras, então você está fazendo errado. (Ou seja, você está sendo excessivamente conservador, um pouco de quebra agora e, em seguida, só vai para mostrar que você está empurrando-o esperançoso.)

Answer 6

Se você não voltar para casa até que todos os seus defeitos são ido, então você nunca vai voltar para casa.

Os meus pensamentos sobre este são de que a compilação diária deve ser automatizado em determinados momentos. Qualquer código não verificados antes isso não se construiu e se não houver checkins de alguém para 2 dias (compilações) em uma linha, em seguida, o sistema de compilação deve notificá-los eo líder técnico como este é um sinal de alerta.

Answer 7

Uma abordagem talvez mais pragmática é ter zero defeitos no tronco, e ramo de todo o desenvolvimento, em seguida, ter compilações diárias é possível tanto no tronco e ramos, mas não zero defeitos não se aplicar a ramos dev.

Enquanto ainda pode haver um certo nível de estigma de ter seu ramo quebrando os constrói, é um problema menor do que quebrar o tronco.

Answer 8

Olhando através das respostas que eu estou surpreso que ninguém tenha mencionado Test Driven Development. Se seu objetivo é zero-defeitos que é o melhor lugar para começar.

Depois que eu recomendaria fortemente par-programação.

Finalmente entender que ferramentas como CruiseControl são úteis, mas, como disse Jim Shore, integração contínua é uma atitude não uma ferramenta . É o compromisso do grupo para manter o funcionamento código que é fundamental.

Answer 9

Sobre a estratégia de defeito zero: Você pode ir para casa, se os erros conhecidos estão em seu código. É mais sobre, que os defeitos devem ser fixados, antes que novos recursos são implementados.

Isso não deve candidatar-se a toda a equipe, mas se um desenvolvedor tem um bug atribuído, que bug tem prioridade sobre novos recursos este desenvolvedores tem de criar.

Answer 10

Dependendo do que você está construindo, adotando uma abordagem que os defeitos não são permitidos não pode ser apropriado. Minha opinião pessoal é que ele raramente, ou nunca, é.

O ponto inteiro de um sistema de gerenciamento de defeito é exatamente isso - para permitir que você gerencie defeitos. Se o defeito é um show-stopping um, então com certeza, você provavelmente não quer fazer check-in, mas se é algo menor ou um caso extremo, em seguida, pode fazer sentido para check-in com o defeito conhecido, desde que você' re segui-lo.

Permitindo defeitos de existir permite que você se concentrar em coisas mais importantes - por exemplo, se você só tem uma quantidade limitada de tempo em um comunicado de que você pode não ter tempo para corrigir tudo, bem como para obter todas as funcionalidades em, por isso, se é um escolha entre a fixação de pequenos erros borda de casos de dez, ou criar um pedaço de funcionalidade de valor acrescentado, em seguida, a escolha pode ser pragmática para navio com erros conhecidos.

Eu não estou dizendo zero defeitos é uma má idéia - na verdade nós nos esforçamos para isso até o final de cada ciclo de lançamento -. Mas como muitas coisas no desenvolvimento de software, o pragmatismo normalmente funciona melhor no mundo real do que o puritanismo

Answer 11

Eu iria com @feverentcoder nos argumentos CI. CI é seu amigo, deixá-lo ajudá-lo!

Como para a Filial / Trunk ponto- todos deve sempre trabalhar no tronco , ramo es são para picos e AP, tag todos lançamentos

Quando se trata de processos, é geralmente benéfico para encontrar práticas , que são relevantes para você e, em seguida, construir micro-processos ao seu redor. Além disso, use apenas as práticas / processos que você sente aumentar a produtividade. Por último, ser courageous- tentar uma prática para uma ou duas semanas para ver se ele trabalha com você; se isso não acontecer, jogue fora. Você acabou de aprender mais uma forma não para fazer uma lâmpada!