A promoção da filial da Hudson pode ser baseada na estabilidade do projeto?

Question

O servidor Hudson CI exibe estabilidade "clima", o que é legal.E permite que a construção de um projeto seja iniciada com base na construção bem-sucedida de outro.No entanto, como você pode tornar esse projeto secundário dependente adicionalmente da estabilidade de múltiplas compilações do primeiro projeto?

Especificamente, o projeto "stable_deploy" só precisa ser iniciado para promover uma versão para "estável" se o projeto "integrado" com a versão 8.3.4.1233 tiver sido compilado e testado com sucesso pelo menos 8 vezes - consecutivas.Até então, ainda está em modo de integração.

IMPORTANTE:Uma ressalva significativa a isso é que um único conjunto de projetos Hudson é usado como um "pipeline" para processar cada nova versão até o lançamento.Portanto, um projeto pode ter sido compilado com sucesso 8 vezes consecutivas, mas a versão mais recente 8.3.4.1233 pode ser apenas as 2 compilações mais recentes.As compilações anteriores a essa podem ser uma versão anterior.

Estamos abertos a reorganizar completamente isso, mas a ideia do pipeline pareceu reduzir bastante a quantidade de criação e exclusão manual de projetos.Existe uma maneira melhor de rastrear o "pipeline" de lançamento de versão?Em particular, teremos múltiplas versões neste pipeline simultaneamente no futuro devido a correções ou patches em versões mais antigas.Não vemos como fazer isso ainda, exceto criar novos projetos de pipeline para cada versão, o que é um verdadeiro incômodo.

Aqui estão alguns detalhes básicos:

O aplicativo TickZoom possui alguns testes unitários muito completos, alguns dos quais simulam ambientes de negociação em tempo real.Acrescente a isso o TickZoom faz uso elaborado de paralelização para aproveitar computadores com vários núcleos.Escusado será dizer que durante o desenvolvimento de uma nova versão, pode haver problemas de estabilidade durante os testes de integração que são descobertos pela execução repetida dos testes de construção e automáticos.Uma versão que é construída e testada de forma limpa 8 vezes seguidas sem alterações e que passou por alguns testes no mundo real pelos usuários pode ser considerada "estável" e promovida para o ramo estável.

Nossos projetos Hudson são assim:

test - Apenas para testar uma compilação, sem visibilidade do usuário.integrar_deploy - promove um projeto de teste para integrar a filial e disponibilizá -lo ao público para testes da UA.integrate - Repetidamente constrói o ramo integrate para determinar se é estável o suficiente para promover a branch estável.Isto executa o constrói e testa de hora em hora durante todas as noites.stable_deploy - Promove uma compilação do projeto integrate para o branch stable e torna-o público para os utilizadores que querem o mais recente e o melhor.stable - Constrói o branch stable uma vez por noite.Após 2 semanas de builds bem sucedidos (14 builds) pode ir para "release candidate".

E assim por diante...continua com "release candidate" e depois "release".

Answer 1

A resposta é criar um pipeline separado de trabalhos para cada nova versão menor do software.

Então eles serão assim.

integrar_0.8.3 stable_0.8.3 candidato_0.8.3 Release_0.8.3

Usaremos a API Hudson para gerar os trabalhos para cada nova versão com o script.

A promoção não pode ser totalmente automatizada, porque outros fatores além de compilações estáveis, como erros relatados pelo usuário, podem atrasar uma versão a passar pelo pipeline.

Sinceramente, Wayne

Answer 2

Eu posso ver o ponto de demonstrar estabilidade ao ter várias construções sucessivas, sem erro, mas sugiro uma abordagem um pouco diferente para tornar as coisas mais simples. Em vez de tentar agregar os resultados de várias construções para determinar se você promove a última compilação para a filial estável, execute seus testes 8 vezes contra a mesma compilação; Você pode fazer isso adicionando um parâmetro de contagem de repetição aos testes ou apenas repita as etapas do teste várias vezes na configuração do trabalho Hudson.

Se a construção passar de maneira limpa toda vez, você poderá usá -lo como uma porta de entrada para enviar a compilação para seus usuários para testes do "mundo real" antes de promovê -lo para a filial estável.

Isso tem algumas vantagens; Isso torna a configuração do Hudson mais simples conforme sua solicitação e oferece confiança adicional na estabilidade da compilação, porque você está executando os testes várias vezes contra a mesma base de código, e não contra uma base de código diferente a cada vez.

Answer 3

Eu acho que você tem que implementar alguma solução fora do Hudson, que produza arquivos de gatilho para serem usados ​​no Hudson ou estender o plugin de promoção com regras específicas da sua empresa.