CruiseControl [.Net] vs TeamCity para integração contínua?

Eu gostaria de perguntar a você qual ambiente de compilação automatizado você considera melhor, com base na experiência prática. Estou planejando fazer algum .Net e algum desenvolvimento em Java, então gostaria de ter uma ferramenta que suporte ambas as plataformas.

Estive lendo e descobrindo sobre CruiseControl.NET , usado no desenvolvimento stackoverflow, e TeamCity com seu suporte para agentes de compilação em diferentes plataformas de sistema operacional e baseado em diferentes linguagens de programação. Então, se você tem alguma experiência prática em ambos, qual você prefere e por quê?

Atualmente, estou mais interessado na facilidade de uso e gerenciamento da ferramenta, muito menos no fato de que CC é open source, e TC está sujeito a licenciamento em algum momento quando você tem muitos projetos para executar (porque, eu precisa para uma pequena quantidade de projetos).

Além disso, se houver alguma outra ferramenta que atenda ao mencionado acima e você acreditar que vale a pena uma recomendação - sinta-se à vontade para incluí-la na discussão.

Eu tenho trabalhado em e com ferramentas de Integração Contínua desde o início do Cruise Control (versão java). Eu tentei quase todos eles em algum momento. Nunca estive mais feliz do que com o TeamCity. É muito simples de configurar e ainda fornece uma grande quantidade de energia. A página de estatísticas de construção que mostra tempos de construção, contagem de teste de unidade, taxa de aprovação, etc. é muito boa. A página inicial do projeto TeamCity também é muito valiosa. Para projetos .NET simples, você pode apenas dizer ao TeamCity onde está a solução e quais assemblies têm testes e isso é tudo de que precisa (exceto localização de controle de origem). Também usamos alguns scripts MSBuild complicados com ele e fizemos o encadeamento de compilação. Também passei por duas atualizações do TeamCity e elas foram indolores.

CruiseControl.NET também funciona bem. É mais complicado de configurar, mas tem uma história mais longa, por isso é fácil encontrar soluções na web. Visto que CruiseControl.NET é de código aberto, você também tem a opção de adicionar ou alterar o que quiser. Eu tinha usado o CruiseControl.NET desde seu lançamento e escrevi alguns dos primeiros códigos para cc.tray (felizmente reescrito por alguém que conhecia melhor).

Cruise, da ThoughtWorks, também parece muito bom, mas não vejo uma razão convincente para eu mudar. Se eu estivesse começando um novo projeto, poderia tentar, mas o TeamCity fez um ótimo trabalho tornando as coisas simples simples e, ao mesmo tempo, tornando o complexo bastante indolor.

Edit: Acabamos de atualizar para TeamCity 5.0 há algumas semanas e foi outra atualização indolor. Isso nos permitiu tirar proveito dos recursos aprimorados de cobertura de código e suporte GIT. Também estamos usando agora os recursos de compilação pessoal e commit pré-testado que já existem há algum tempo. Achei que deveria atualizar a resposta para indicar que o TeamCity continua melhorando e ainda é fácil de usar.

Eu era / sou um grande fã do CC.NET. Temos atualmente 5 projetos no CruiseControl e funciona muito bem. Escrever arquivos de configuração manualmente pode ser doloroso, mas está tudo bem.

Mas ...

Depois do screencast de Kona: Integração Contínua e Melhor Teste de Unidade (o primeiro 1/3 sobre TeamCity), também verificarei o TeamCity. Eu amo o painel de teste de unidade integrado e a interface de configuração.

Acho que todos deveriam assistir a este vídeo antes de escolher CC.NET ou TeamCity.

ps: Espero que haja um vídeo valioso do CC.NET na rede também.

De longe, meu servidor CI favorito é o Hudson. Fácil de configurar e manter, muitos gráficos legais para mostrar tendências para desenvolvedores e não desenvolvedores e gratuitos.

Estou usando o TeamCity atualmente em um projeto e geralmente estou satisfeito com ele, mas muitos dos gráficos que ele gera não são especialmente úteis e são mais complicados de configurar do que o Hudson.

Dito isso, TeamCity é poderoso, gratuito para muitos usos e tem um recurso matador: Remote Run. Você pode "pré-comprometer" sua verificação diretamente do IDEA ou Eclipse, executar uma ou mais configurações de construção no servidor TeamCity e somente confirmar as alterações se a construção for bem-sucedida (por exemplo, compila e todos os testes passam).

Considerando que você pode colocar TeamCity e Hudson em operação em algumas horas, pode valer a pena pegar ambos e executá-los lado a lado, junto com quaisquer outros (como CruiseControl) que você possa imaginar. Se você não pode suportar um servidor de CI rapidamente para fazer uma comparação lado a lado, então pelo menos você tem um ponto de dados para fácil instalação e / ou configuração.

Eu usei os dois com sucesso em projetos diferentes. Do ponto de vista administrativo e de configuração, Team City é muito mais fácil de lidar. Você não precisa hackear arquivos .config como faz com o CC e a configuração é muito fácil. Como você não tem muitos projetos, eu recomendaria Team City em vez de CC até chegar ao ponto em que Team City custa $$.

Eu usei o CC.net e o TeamCity. Tenho a tarefa de configurar e instalar o TeamCity para minha organização (5 desenvolvedores). Nossa organização usa algumas práticas e ferramentas incomuns (pelo menos, para organizações do nosso tamanho), como Perforce para controle de origem e vários agentes de construção em execução em sistemas operacionais heterogêneos, o que causou alguns problemas de configuração inicial. No entanto, o suporte por e-mail foi absolutamente excelente na configuração de tudo. Recebi respostas às minhas perguntas idiotas literalmente em minutos.

A interface é intuitiva e responsiva, bem como repleta de recursos. O produto parece muito caro. A configuração é fácil e a interface da web é inteligente o suficiente para se atualizar sem qualquer reinicialização do agente ou dos serviços do servidor, ou mesmo atualização da página.

Acho que estamos usando quase todos os recursos avançados do produto e não encontramos nenhum bug até agora. Integração Ndepend, scripts NAnt aninhados, rotulagem de versão do Perforce, você escolhe, estamos fazendo isso.

Eu recomendo o TeamCity para quem procura um servidor de integração contínua, ou qualquer servidor de construção, na verdade.

Sem querer jogar ferramentas alternativas em você :-)

Hudson é uma ótima alternativa de código aberto, eu usei CC e CC.net, e confesso que acho que são ferramentas fantásticas. Estou pensando em mudar para o hudson, pois parece muito mais fácil de configurar e manter.

https://hudson.dev.java.net/

Certifique-se de que o sistema que você escolheu se adapta ao número de projetos que você precisa para gerenciar ...

Eu uso CruiseControl.Net, mas não o recomendaria para construir muitos projetos ... Eu tenho um arranjo (possivelmente um pouco estranho) onde tenho muitas bibliotecas estáticas C ++ que componho em aplicativos. Cada biblioteca depende de outras bibliotecas e os aplicativos puxam um conjunto de libs e compilação. Cada lib possui um conjunto de testes. Cada aplicativo possui um conjunto de testes. Eu construo para 5 compiladores e variações de plataformas (windows).

A primeira coisa que descobri foi que os gatilhos de projeto do CC.Net não são exatamente o que você precisa e o multi-gatilho não funciona bem com os gatilhos de projeto. A forma como os gatilhos de projeto funcionam (eles usam remoting para se conectar ao servidor onde o projeto está armazenado (mesmo se for um projeto que é gerenciado pela mesma instância do CC.Net) e, em seguida, puxar todos os projetos desse servidor e pesquisar a lista sequencialmente procurar o projeto no qual você está interessado ...) significa que eles não são bem dimensionados. Depois de ultrapassar um certo número de projetos, você descobrirá que o CC.Net está ocupando a maior parte da CPU da sua máquina de construção.

Claro, é código aberto, então você pode corrigi-lo ... E, tenho certeza que é bom para um pequeno número de projetos não interdependentes.

Para mais detalhes sobre os problemas que tive e alguns patches para CC.Net veja aqui http://www.lenholgate.com/archives/cat_ccnet.html

Recentemente, configurei o cc .net. É um ótimo aplicativo, mas requer um pouco de paciência. Você estará editando muitos arquivos de configuração no bloco de notas :)

Já existe há algum tempo, por isso é bem suportado e normalmente você pode encontrar alguém que já fez o que você queria antes. A interface da web também é .net, o que foi uma vantagem para nós, pois somos uma loja da Microsoft.

Eu não usei o TeamCity, mas ouvi algumas recomendações dele e é bonito.

Tive uma experiência configurando e executando CruiseControl (versão Java) no Linux durante minha empresa anterior. Como a maioria das pessoas sugere, não é a coisa mais trivial de configurar. Você precisa entender sua estrutura para chegar a uma configuração viável / gerenciável. No entanto, depois que você passou por esse obstáculo, sinto que o CruiseControl é bastante flexível para permitir que você faça diferentes tipos de coisas para se ajustar a diferentes cenários.

Além da documentação do CruiseControl, sua página wiki também contém algumas informações úteis.

Eu não tenho uma experiência direta com TeamCity. Embora seu recurso de confirmação de pré-teste pareça interessante o suficiente.

A outra ferramenta CC que você pode dar uma olhada é o Bamboo da Atlassian. É muito mais fácil de configurar e a interface é mais agradável. Porém, não é tão flexível quanto o CruiseControl oferece.

Uma terceira opção que você pode querer considerar: Cruzeiro da Thoughtworks. É construído no CruiseControl, mas oferece muito mais recursos, configuração mais fácil, etc, etc. Não é gratuito (ou de código aberto).

http://studios.thoughtworks.com/cruise-continuous-integration

Uso o Teamcity há 1 ano e meio e tenho uma ótima experiência. Eu integrei vários projetos .Net e Java e usei ferramentas como MSBuild, Maven, etc. Achei o Teamcity muito simples de configurar e trabalhar. Eu consegui colocar o CI em execução para alguns projetos sql também, o que foi um pesadelo, o que poderia ter sido pior com outras ferramentas de CI.
Recentemente atualizado para Teamcity 8.0.6 que era indolor. Além disso, o Teamcity fornece uma API REST que é muito útil para alguns cenários. Se você estiver usando o PowerShell para automatizar compilações, uma série de scripts de integração Psake / Teamcity estão disponíveis no GitHub