Qual é a melhor maneira de configurar um servidor de teste de integração?

Question

Configurando um servidor de integração, estou em dúvida sobre a melhor abordagem em relação ao uso de múltiplas tarefas para concluir a construção.A melhor forma é colocar tudo em apenas um grande trabalho ou tornar pequenos dependentes?

Answer 1

Você definitivamente deseja dividir as tarefas.Aqui está um bom exemplo de configuração do CruiseControl.NET que possui diferentes alvos (tarefas) para cada etapa.Ele também usa um arquivo common.build que pode ser compartilhado entre projetos com pouca customização.

http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk

Answer 2

Eu uso o TeamCity com um script de construção nant.O TeamCity facilita a configuração da parte do servidor de CI, e o script de construção nant facilita a execução de uma série de tarefas no que diz respeito à geração de relatórios.

Aqui está um artigo que escrevi sobre o uso de CI com CruiseControl.NET. Ele possui um script de construção nant nos comentários que pode ser reutilizado em projetos:

Integração Contínua com CruiseControl

Answer 3

A abordagem que prefiro é a seguinte configuração (na verdade, supondo que você esteja em um projeto .NET):

• CruiseControl.NET.
• Tarefas NANT para cada etapa individual.Nant.Contrib para modelos CC alternativos.
• NUnit para executar testes de unidade.
• Ncover para realizar cobertura de código.
• FXCop para relatórios de análise estática.
• Subversion para controle de origem.
• CCTray ou similar em todas as caixas de desenvolvimento para receber notificações de compilações e falhas, etc.

Em muitos projetos você descobre que existem diferentes níveis de testes e atividades que ocorrem quando alguém faz um check-in.Às vezes, isso pode aumentar com o tempo, a ponto de levar muito tempo após uma compilação até que um desenvolvedor possa ver se quebrou a compilação com um check-in.

O que faço nesses casos é criar três builds (ou talvez duas):

• Uma construção de CI é acionada por check-in e faz um SVN Get, Build limpo e executa testes leves.O ideal é que você possa manter isso em minutos ou menos.
• Uma construção mais abrangente que pode ser feita de hora em hora (se houver alterações), que faz o mesmo que o CI, mas executa testes mais abrangentes e demorados.
• Uma construção noturna que faz tudo e também executa cobertura de código e análise estática dos assemblies e executa quaisquer etapas de implantação para construir pacotes MSI diários, etc.

O principal aspecto de qualquer sistema de CI é que ele precisa ser orgânico e ser constantemente ajustado.Existem algumas extensões excelentes para CruiseControl.NET que registram e traçam horários de construção, etc., para as etapas e permitem fazer análises históricas e, assim, permitir que você ajuste continuamente as construções para mantê-las rápidas.É algo que os gerentes acham difícil aceitar que uma caixa de construção provavelmente irá mantê-lo ocupado por um quinto do seu tempo de trabalho apenas para impedir que ela pare.

Answer 4

Nós usamos robô de construção, com a construção dividida em etapas discretas.Há um equilíbrio a ser encontrado entre ter as etapas de construção divididas com granularidade suficiente e ser uma unidade completa.

Por exemplo, na minha posição atual, construímos subpeças para cada uma de nossas plataformas (Mac, Linux, Windows) em suas respectivas plataformas.Temos então uma única etapa (com algumas subetapas) que os compila na versão final que terminará nas distribuições finais.

Se algo der errado em alguma dessas etapas, é muito fácil diagnosticar.

Meu conselho é escrever as etapas em um quadro branco da forma mais vaga possível e basear suas etapas nisso.No meu caso seria:

1. Construir peças de plug-in
   1. Compilar para Mac
   2. Compilar para PC
   3. Compilar para Linux
2. Faça os plug-ins finais
3. Execute testes de plug-in
4. Construir IDE intermediário (temos que inicializar a construção)
5. Crie o IDE final
6. Execute testes IDE

Answer 5

Eu definitivamente dividiria os trabalhos.Provavelmente, você fará alterações nas compilações e será mais fácil rastrear problemas se você tiver tarefas menores em vez de pesquisar em uma compilação monolítica.

De qualquer forma, você deve ser capaz de criar um grande trabalho a partir de peças menores.

Answer 6

Bom dia,

Como você está falando sobre testes de integração, minha grande (óbvia) dica seria tornar o servidor de teste construído e configurado o mais próximo possível do ambiente de implantação.

</thebloodyobvious> (-:

obrigada Roubar

Answer 7

Divida suas tarefas em metas/operações distintas e, em seguida, use um script de nível superior para uni-las adequadamente.

Isso torna seu processo de construção mais fácil de entender para outras pessoas (você documenta à medida que avança para que qualquer pessoa da sua equipe possa entendê-lo, certo?), além de aumentar o potencial de reutilização.É provável que você não reutilize os scripts de alto nível (embora isso possa ser possível se você tiver projetos semelhantes), mas você pode definitivamente reutilizar (mesmo que seja copiar/colar) as operações discretas com bastante facilidade.

Considere o exemplo de como obter a fonte mais recente do seu repositório.Você desejará agrupar as tarefas/operações para recuperar o código com algumas instruções de registro e referenciar as informações da conta apropriadas.Esse é o tipo de coisa muito fácil de reutilizar de um projeto para outro.

Para o ambiente da minha equipe, usamos o NAnt, pois ele fornece um ambiente de script comum entre as máquinas de desenvolvimento (onde escrevemos/depuramos os scripts) e o servidor de CI (já que apenas executamos os mesmos scripts em um ambiente limpo).Usamos Jenkins para gerenciar nossas compilações, mas em sua essência cada projeto está apenas chamando os mesmos scripts NAnt e então manipulamos os resultados (ou seja, arquivar a saída da compilação, sinalizar testes com falha, etc.).