ti-enxame.com

Servidor de construção contínua (cc.net, hudson, bamboo, etc ...) experiência de construção remota?

Atualmente usamos o servidor cc.net uma vez para o nosso processo de construção, que constrói tanto .net (usando msbuild & nant) e Java (usando maven e ant).

CC.net monitora o controle de origem e aciona uma compilação remota em execução em um servidor separado. CC.net então agrupa os resultados.

Quando executamos a compilação remota, normalmente:

  • executa nunit ou junit ou similar usando dados simulados
  • opcionalmente, executa um script de banco de dados para criar uma nova instância de banco de dados ou restaurar um banco de dados de uma posição conhecida.
  • executa Selenium ou semelhante à IU de teste
  • executa emma ou ncover para cobertura de código
  • constrói o sistema para vários ambientes de implantação (teste, aceitação, produção)

Podemos ter vários builds em execução ao mesmo tempo, alguns .net e alguns Java (de diferentes equipes de projeto).

É muito demorado fazer as compilações remotas funcionarem quando configuramos um novo projeto e sentimos que deve haver algo mais adequado para compilações remotas do que cc.net.

Alguém tem alguma experiência com builds remotos com sistemas de integração contínua?
Eu realmente não quero listas de recursos de servidores de CI, gostaria muito mais de saber como você as usou em um ambiente de vários idiomas e servidores.

9
Chris Buckett

Hudson (Atualização: no mundo de hoje, eu usaria Jenkins, um fork do Hudson.)

Eu usei hudson em ambos os ambientes Java e .NET enterprise para projetos de alta visibilidade (você provavelmente já esteve em alguns dos sites). Hudson é sólido desde o início, mas a melhor parte é que existem muitos plug-ins para fazer praticamente tudo o que você quiser. Hudson é altamente configurável, tem uma grande comunidade e é muito fácil de configurar em um ambiente de cluster se você precisar de várias compilações ao mesmo tempo. É meu servidor CI favorito de todos os que usei (CC.NET, Hudson e TFS).

Além disso, você pode usar o plug-in ChuckNorris para que ele dê o polegar para cima ou para baixo.

8
Ryan Hayes

Estávamos enfrentando essa questão há algum tempo e decidimos ir com TeamCity . Nós apenas olhamos para Hudson, CC e TeamCity. A escolha foi fácil de fazer - TeamCity acabou sendo nosso servidor de compilação. Observe que não sou um profissional nisso e foi minha primeira experiência com a construção de servidores naquela época.

Hudson - Eu não tinha ideia do que fazer e onde ler sobre isso. E embora eu pudesse entender algo lá, não era uma opção - muito trabalho. Decidi dar uma olhada no CC.

Controle de cruzeiro - igual ao Hudson, mas de uma forma ligeiramente diferente. Absolutamente nada pode ser entendido lá sem um manual e uma tonelada de ajuda do google. Acabei de dar uma olhada no TC.

TeamCity - TeamCity parecia o paraíso após os dois primeiros. É o mais utilizável desses três. Instale, vá ao painel de administração, configure um projeto (mostre onde está o SVN, aponte para construir arquivos, especifique a cobertura/testes de unidade etc.) e comece a desfrutar. E embora eu não possa dizer que não pesquisei nada no Google, 95% do processo de configuração foi muito fácil e claro. Eu recomendo fortemente esta ferramenta. Vá e dê uma olhada nisso. Isso vai te poupar muito tempo e nervos :)

Devo também observar que o TC não é gratuito. Embora eles tenham uma edição gratuita que pode ser usada em projetos comerciais com algumas limitações (max build configs 20) - dê uma olhada em sua página de preços.

PS Parece que trabalho para o TC, mas não trabalho :)

7
Jefim

Usamos CC.NET 1.4.

Estamos tentando atualizar para 1.6 ... que pesadelo.

É poderoso ... mas SÓ se você usá-lo corretamente e entender como tudo se encaixa. O que é pedir muito a toda a equipe. Temos 'buildmasters' que têm acesso ao servidor e podem alterar as configurações. Mesmo assim, há muita pesquisa no Google em relação à ccnet e todo o negócio se tornou uma grande confusão.

Eu pessoalmente quero mudar para TeamCity.

Eu recomendo que você fique longe da ccnet.

3
Nobody

boa pergunta. No momento, também estamos tentando descobrir qual ferramenta se encaixa melhor para nós. Portanto, só poderei contar uma pequena experiência. Mas estaríamos muito interessados ​​em qual sistema de CI você escolheu agora e por quais motivos. Portanto, mantenha-nos informados.

Estou muito impressionado com o quão alto é o nível do seu CI. Tenho que admitir que temos menos requisitos porque ainda não executamos testes de interface do usuário e não criamos instâncias de banco de dados ou similares, apenas usamos simulações para nossos testes de unidade.

Agora, às nossas experiências até agora:

Para projetos Java projetos, estamos usando Bamboo, que funciona bem com JUnit e Emma. E não há muito esforço para configurar um novo projeto.

Para projetos .NET, ainda estamos procurando a melhor solução

  • Cruise Control: Não foi possível colocá-lo em funcionamento ainda devido a problemas de conexão com nosso repositório

  • TFS:

    a) Existem algumas etapas de configuração necessárias para poder executar a primeira compilação.

    b) Existem algumas armadilhas que você deve superar em relação aos direitos de acesso. Existem muitas funções que você pode definir e você deve saber exatamente quais direitos têm seu processo de construção e quais têm sua conta de login pessoal. Mas se você tiver tempo suficiente para gerenciar, poderá definir cada granularidade específica de que precisa.

    c) Em relação às bibliotecas referenciadas, existem também algumas coisas para gerenciar se você quiser compartilhar as bibliotecas para muitos projetos e não quiser lidar com elas em todos os projetos

    d) Executar o teste NUnit não é tão fácil quanto pensávamos. Só é fácil se você estiver usando a execução de teste fornecida pelo Visual Studio, mas isso não é NUnit

    e) Não tentamos executar o NCover ainda (o mais importante primeiro :-))

  • Hudson: Vamos tentar a próxima ferramenta. Parece ter um plug-in muito bom e fácil para .net, contarei como funcionou

  • Bamboo: Primeira previsão que obtivemos: "Too Java specific". Mas talvez tentemos o plug-in .NET mesmo assim, avisarei você

Espero que possamos continuar essa discussão e trocar experiências.

Andy

1
Mayoares