Hudson ou Teamcity para integração contínua? [fechadas]

100

Somos uma loja Java em busca de uma ferramenta de CI para usar. Ambos Hudson e Teamcity parecem ser gratuitos, mas Teamcity parece mais habilidoso e com mais suporte.

Eu estava me perguntando por que alguém ainda usaria o Hudson e se alguém poderia fornecer algum argumento a favor / contra qualquer um deles?

— PDeva
fonte

Você pode estar interessado nas respostas aqui: stackoverflow.com/questions/1200721/…

— ire_and_curses

Eu colocaria o CruiseControl na mistura - se você ainda não o considerou. Não posso comentar sobre um ponto de vista java, tendo usado a versão .NET mas gosto disso.

— AdaTheDev

3

@ire_and_curses nenhuma das respostas no post dá um bom argumento para qualquer uma das ferramentas em comparação com a outra

— pdeva

4

-1 para Cruise Control - Muitos arquivos de configuração que precisam ser configurados manualmente "apenas isso".

— Bevan,

3

Até onde posso ver, a existência de TeamCity grátis torna o CruiseControl extinto. Não vejo razão para usar CruiseControl em vez de TeamCity. E muitas razões para o contrário.

— Niall Connaughton

113

O Team City é de longe o melhor servidor de CI que existe. Seu recurso matador para mim é a forte integração com IDEs (IntelliJ, Eclipse e VisualStudio). Ele pode mostrar, por exemplo, quando um arquivo que você está editando no IDE se torna desatualizado, quem o alterou e o que foi alterado. Você pode fazer commit do IDE para o servidor CI, executar o comile e os testes na grade de construção e, em seguida, o servidor CI confirmará se a construção for bem-sucedida. Você pode clicar em criar relatórios no aplicativo da web CI e ele abrirá os arquivos apropriados no IDE.

Existem plug-ins disponíveis (eu escrevi um: http://team-piazza.googlecode.com ), mas não muitos.

— Nat
fonte

9

Execução remota / confirmação pré-testada são recursos muito úteis do TeamCity. Em geral, TC pode ser mais conveniente se seus builds não forem rápidos, porque no TeamCity você obtém feedback contínuo sobre o que acontece em seu build (quantos testes foram aprovados, falharam, em que estágio o build está e assim por diante). Além disso, as notificações do TC são mais sofisticadas. Você pode configurar regras diferentes para diferentes tipos de builds e para uma ampla gama de notificadores (e-mail, Jabber, bandeja do Windows).

— Pavel Sher

6

@Pavel: Não conheço TeamCity tão bem quanto Hudson, então não questionarei o início do seu comentário. Mas, em relação às notificações, afirmar que o TC é mais sofisticado é puro FUD na minha opinião não tão humilde. Todos os canais de notificação mencionados estão disponíveis no Hudson (você pode até adicionar o Twitter). Na verdade, eu aposto que Hudson tem muito mais plugins do que TC (verifique wiki.hudson-ci.org/display/HUDSON/Plugins ) e tenho certeza que TC tem mais limitações que Hudson.

— Pascal Thivent

3

Eu concordo com os canais (Hudson tem muitos plug-ins), mas não concordo com as regras. No TeamCity, você pode se inscrever em construções com suas alterações, você pode escolher ser notificado quando a construção começar a falhar (por exemplo, quando o primeiro teste começar a falhar). Você pode pedir para ser notificado na primeira construção com falha após a sequência de sucesso + no primeiro sucesso após as falhas. E essas opções estão disponíveis para todos os canais de notificação. Um desses canais é o notificador IDE: quando algo der errado, você receberá uma notificação diretamente em seu IDE. Pelo que me lembro, as regras de notificação do Hudson eram muito mais simples.

— Pavel Sher

2

Pavel - não quer um fósforo de estilingue aqui, mas por padrão Hudson só enviará e-mail se você contribuiu para a construção com falha. Você também pode se inscrever para ser informado sobre cada construção com falha, se desejar. Também há mais opções no plug-in de extensão de e-mail. Você não tem que aprovar isso, mas não vamos deturpar isso.

— Jim T de

4

Um rápido google irá mostrar a você que existem plug-ins para controlar coelhos nabaztag e outros dispositivos bonitos do Team City. Ou você pode usar o plug-in vinculado à minha resposta . O benefício da integração IDE é muito mais rápido e um feedback mais focado sobre o código no qual você está trabalhando enquanto trabalha com ele. Você não precisa esperar por uma notificação, alternar para o navegador tge, ler o relatório, voltar para o IDE e abrir o arquivo apropriado. O painel do editor muda conforme você trabalha para mostrar como outros membros da equipe afetaram o código.

— Nat

58

1 para Hudson.

Hudson é um projeto muito ativo, tem uma ampla comunidade de usuários e uma lista de e-mails de usuários ativos, é realmente fácil de começar, é fácil de usar, foi usada em projetos enormes, muito grandes (JBoss, JAX-WS, etc) e, portanto, tem registros de sucesso comprovados, ofertas avançadas muito interessantes recursos (por exemplo, matriz de construção, cluster de construção, etc), é de código aberto, tem muitos plug-ins ...

~~E se o suporte é realmente uma coisa importante, você pode obter suporte comercial da Sun . Mas FWIW, eu nunca enfrentei qualquer problema de bloqueio com Hudson.~~

Atualização: como você deve saber, Kohsuke Kawaguchi (o criador do Hudson) deixou a Sun / Oracle e começou sua própria empresa para levar o Hudson ao próximo estágio . Em outras palavras, isso não é uma ameaça para Hudson. E se você estiver procurando por suporte, você pode obter uma versão certificada do Hudson CI Server como parte de um plano de assinatura (esta versão certificada inclui um lançamento de alta qualidade do Hudson com um conjunto predefinido de plug-ins mais alguns comerciais).

Atualização: para ilustrar o tamanho de sua respectiva base de usuários, aqui está uma comparação das tendências de trabalho para várias ferramentas de CI no Even (consulta ao vivo):

Engenheiro de construção Hudson, engenheiro de construção CruiseControl, engenheiro de construção Bamboo, engenheiro de construção TeamCity Tendências de trabalho

Obviamente, este não é um indicador técnico.

— Pascal Thivent
fonte

88

Talvez o TeamCity seja tão fácil de usar, que não exija ninguém especificamente empregado para configurá-lo?

— Henrik

3

@Henrik: A interpretação do gráfico acima fica a seu critério. Mas sim, talvez o TeamCity seja mágico.

— Pascal Thivent

16

Se você contratar um engenheiro de construção em tempo integral para executar sua integração contínua, agora você terá dois problemas: 1) É difícil trabalhar com seu CI, então seus desenvolvedores terão dificuldade com isso e o conhecimento ficará na cabeça dessa pessoa, 2) Você está pagando alguém para fazer um trabalho que não deveria ser feito!

— Niall Connaughton

15

Se eu estivesse selecionando um servidor de CI, escolheria aquele que tivesse MENOS vagas de emprego para um engenheiro dedicado administrá-lo. É uma ferramenta de desenvolvedor e os próprios desenvolvedores devem ser capazes de gerenciá-la. Se não puderem, você precisará de uma ferramenta diferente ou de desenvolvedores diferentes.

— Nat

O gráfico de tendências de empregos não implica em +1 para hudson ...

— Sharique Abdullah

17

Começamos com Hudson para alguns projetos Flex, depois migramos para TeamCity, quando os desenvolvedores .NET se juntaram aos nossos esforços de CI. Agora substituímos o servidor TeamCity novamente, de volta ao Hudson. As principais razões são: - A vibrante comunidade Hudson, melhor do que suporte. - A enorme quantidade de plugins para todo tipo de tarefa. - O código aberto. - Hudson é gratuito, TeamCity é gratuito apenas para 10 projetos.

editar: TeamCity agora é gratuito para 20 projetos.

— subotnik
fonte

2

As 10 restrições de projeto caíram, o único limite agora é de 20 configurações de construção. Para projetos de pequeno a médio porte, talvez seja o suficiente.

— ashwoods

4

Por curiosidade, quais recursos disponíveis por meio dos plug-ins do Jenkins estavam faltando no mundo TeamCity?

— Behrang Saeedzadeh

14

TeamCity é ótimo porque permite que cada desenvolvedor tenha seu próprio perfil de construção e se conecte a ele a partir de seu IDE. Que solitário é 'chutar o traseiro'. Também há suporte para GIT etc. Sério, dê uma olhada nisso. A versão profissional é gratuita.

— Beaumont Muni
fonte

5

GIT também é suportado por Jenkins / Hudson

— CJBrew

14

O maior argumento contra Hudson é que cada versão apresenta novos bugs.

Os lançamentos são muito frequentes, então você precisa atualizar com frequência para não ficar para trás. Isso significa que você precisa dedicar muito tempo para diagnosticar problemas e reverter para versões anteriores do Hudson. (Às vezes, uma reversão nem é possível!)

Estamos introduzindo a implantação contínua em nossa loja (quando você faz o check-in do código, ele é implantado no site ao vivo!) E ter que lutar com o Hudson está nos custando muito caro.

Estamos ativamente procurando migrar para o TeamCity puramente por causa do custo dos bugs do Hudson.

— jdtangney
fonte

8

Só porque há uma atualização disponível não significa que você deve atualizar. Eu prefiro que eles sejam lançados com mais frequência. É minha escolha quando atualizar e certamente não faço isso todas as semanas. Além disso, os mantenedores são muito conservadores quanto à compatibilidade com versões anteriores. Plugins geralmente não requerem o Hudson mais recente para funcionar. Na verdade, 130 plug-ins disponíveis agora são desenvolvidos em versões do Hudson com mais de um ano. Se você ainda estiver preocupado, há um plug-in de reversão automatizado em desenvolvimento ...;)

— Christopher Orr

1

Pela minha experiência, o problema está mais com os plug-ins do que com o próprio Hudson, embora isso não faça uma grande diferença do ponto de vista do usuário. Porém, nada o força a atualizar, a menos que você esteja enfrentando um bug específico ou não consiga viver sem um novo recurso. Simplesmente não seguimos cada lançamento e não usar a versão final não é um problema para nós: "Se não está quebrado, não conserte" .

— Pascal Thivent

2

Quando o committer principal envia uma mensagem dizendo que uma grande falha de segurança foi corrigida, esse é um motivo para atualizar. Meu ponto ainda é válido: Hudson é muito instável - mesmo sem plugins adicionais instalados.

— jdtangney

1

Posso dizer que depois de um ano e meio usando Hudson / Jenkins em um projeto, embora seja uma ótima ferramenta - nós também experimentamos qualidade inconsistente entre os lançamentos - e só atualizamos quando é absolutamente necessário. Encontramos soluções, incluindo backups frequentes de configuração. Estou ansioso para experimentar o TeamCity em meu projeto mais recente.

— JaysonRaymond

4

Por que atualizações e estabilidade devem ser fatores opostos? Isso não indica apenas uma falta de qualidade?

— Niall Connaughton

6

Eu realmente gostei do Teamcity, mas no ambiente em que estou trabalhando, o tempo que levaria para obter um pedido de compra para o Teamcity por meio das camadas de gerenciamento provavelmente teria excedido o tempo necessário para migrar tudo para o Hudson.

— sal
fonte

10

TeamCity Professional é gratuito.

— Pavel Sher

6

@Pavel, temos mais de 20 usuários e muito mais builds do que isso.

— sal de

22

@sal, sempre me surpreende como as empresas podem se preocupar tanto com alguns milhares de dólares pelas ferramentas de suas equipes de desenvolvimento e preferir que elas desperdicem centenas de horas combinadas que não perderiam com a ferramenta.

— Chris Marisic

5

@Chris E se eles começarem com uma ferramenta gratuita de código aberto apenas para ver como algo funciona e 2 anos depois perceber que ainda funciona sem problemas? Você ainda sugeriria gastar alguns milhares de dólares para atualizar para uma ferramenta comercial que provavelmente faz exatamente a mesma coisa?

— stefanB de

1

@stefan Se você usou uma ferramenta por 2 anos e ela atende às suas necessidades, a menos que haja o recurso X que você precisa de outra ferramenta, por que você mudaria para qualquer outra ferramenta gratuita ou paga?

— Chris Marisic

2

Eu usei e configurei o TeamCity e o Jenkins (também conhecido como o novo Hudson) antes e embora eu concorde que o TeamCity é muito mais inteligente de configurar, ele só é gratuito para equipes de 10 usuários ou menos. Ambos os sistemas são muito fáceis de configurar e possuem um sistema de plugins que é bem suportado. O recurso matador no TeamCity é o fluxo de trabalho de pré-check-in, onde você pode testar o código antes de fazer o check-in no controle de origem e a sutileza do Jenkins é que ele é totalmente gratuito, mesmo que você ultrapasse os 10 usuários e agentes de construção.

— runxc1 Bret Ferrier
fonte

Também gosto da visualização gráfica do Jenkins, e é isso que estou perdendo no Teamcity. Além disso, concordo com seu comentário!

— Danny Gloudemans de

Se você concordar com um comentário, vote :)

— runxc1 Bret Ferrier

1

Estou apenas começando a me acostumar com o Hudson pronto para experimentar e ver como ele se encaixará em nosso ambiente atual. Não tenho absolutamente nenhuma experiência com o Teamcity, então não posso comentar sobre isso, mas estou gostando de trabalhar com o hudson até agora.

Existem muitos plug-ins para hudson e o site hudson oferece muitos conselhos para escrever o seu próprio ( http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson ).

— Jake Worrell
fonte

1

Tenho recomendado a clientes que considerem o Bambu. A razão é que (ok, pela leitura das folhas de especificações!) Ele tem um conjunto de recursos muito semelhante ao TeamCity. No entanto, o principal benefício é uma integração muito estreita com o JIRA, que é bastante popular como um sistema de rastreamento de recurso / bug. A suíte completa é JIRA, Greenhopper, Bamboo e Eclipse. Alguns clientes também têm o centro de qualidade HP e há plug-ins que o unem ao JIRA também. Também gosto do fato de que JIRA, Bamboo e GreenHopper vêm da Atlassian.

— drekka
fonte

Após o uso extensivo do TeamCity, Jenkins parece muito bare-metal. Sim, os plug-ins permitem que você faça qualquer coisa, uma vez que você os instale. TeamCity tem um conjunto de recursos maduro que o deixa fora da caixa. No entanto, no nível de entrega contínua, ambos deixam um pipeline de teste adequado não implementado. QuickBuild é um produto ainda mais rico em recursos que merece atenção, é um payware.

— bbaassssiiee

Tendo visto o Bamboo em ação no site de um cliente, não estou mais interessado nisso. Existem algumas áreas em torno de scripts e transferência de informações entre compilações que ele tem dificuldade em fazer. Os resultados tendem a ser os desenvolvedores colocando todo tipo de coisa na área de variável global do IC que simplesmente não deveria estar lá.

— drekka