Cruise Control .Net vs Team Foundation Build [fechado]

Question

Nossa equipe está configurando compilações de integração noturnas e contínuas.Somos proprietários do Team Foundation Server e podemos usar o Team Foundation Build.Estou mais familiarizado com o CC.Net e enxuto dessa forma, mas a gerência vê todo o dinheiro gasto no TFS e quer usá-lo.

Algumas coisas que gosto mais no CC.Net são a flexibilidade das notificações, bem como a facilidade de implementação de scripts personalizados.

Se você tem experiência com os dois produtos, qual prefere e por quê?

Answer 1

Eu usei ambos.Acho que depende do que sua organização valoriza.

Como você conhece o CC Net, não falarei muito sobre isso.Você já sabe o que o torna legal.

Aqui está o que eu gosto no Team Foundation Build:

• Construir Agentes.É muito simples transformar qualquer caixa em uma máquina de construção e executar uma construção nela.A MSFT acertou.
• Comunicando.Todos os resultados de compilação relevantes (testes incluídos) são armazenados em um banco de dados SQL e relatados por meio do SQL Server Reporting Services.Esta é uma ferramenta imensamente poderosa para traçar gráficos de resultados de construção e teste ao longo do tempo.CC Net não tem isso integrado.
• Você pode fazer personalizações semelhantes por meio do MSBUILD.É basicamente o mesmo que usar NAnt com CC Net

Aqui está o que me deixa louco sobre o Team Foundation Build:

• Para construir projetos C++/CLI (ou executar testes de unidade...?) o agente de construção deve ter o VSTS Dev ou Team Suite instalado.Isso, amigos, é uma loucura.
• Deve estar conectado à Nave Mãe TFS

Se você está em uma grande organização com muitos chefes que têm orçamentos enormes e adoram relatórios (e não me interpretem mal, isso tem um valor enorme) OU você precisa escalar para um farm de construção com várias máquinas, eu prefira Team Foundation Build.

Se você é uma loja mais enxuta, opte pelo CC Net e desenvolva suas próprias soluções de relatórios.Foi isso que fizemos.

Até sermos adquiridos.E tenho TFS :P

Answer 2

Presumo que, como você possui o TFS, você o usará para controle de versão.Nesse caso, eu me inclinaria para o Team Foundation Build.Dito isto, concordo bastante com usuario.

Eu escrevi o Integração CruiseControl.NET para TFS.Funciona bem e oferece os mesmos recursos de construção com os quais você está acostumado.Para mim, a principal vantagem do CC.NET é que ele é completamente extensível e tem integrações com todos os principais SCM e sistemas de construção existentes.A principal razão pela qual escrevi a integração do CC.NET ao TFS é que no TFS2005 o sistema de compilação não tinha suporte de CI pronto para uso.No entanto, a versão do TFS2008 foi muito melhorada e a equipe continua a melhorá-la ativamente para versões futuras do TFS.

O principal motivo para mudar para o TFS Build seria que ele reportasse automaticamente as informações de construção de volta ao TFS, o que ajudaria a completar o quadro de desenvolvimento de software em termos de relatórios.Ele também se integra perfeitamente ao lado de rastreamento de itens de trabalho do TFS e dentro do IDE (tanto no Visual Studio quanto no Eclipse).

Dito isso, se você tem grandes investimentos em scripts Nant que fazem mais do que apenas compilar e testar seu código ou se já possui uma solução de relatórios caseira, talvez você queira continuar com o que tem.

Answer 3

O valor real do Team Foundation Build é que ele associa conjuntos de alterações e itens de trabalho às compilações.

Isso permite alguns cenários úteis:

• Você pode examinar um item de trabalho e descobrir em qual compilação ele está incluído
• Você pode examinar uma compilação e ver quais alterações de código (e itens de trabalho) ela inclui

Depois, é claro, há os relatórios criados com base nessas informações.Mas mesmo esses links por si só são úteis para pessoas que não são de gerenciamento.

Dê uma olhada em www.tfsbuild.com para "receitas" em diferentes configurações do Team Build.

Answer 4

SVN é uma ferramenta OK, muito superior, não é verdade, SVN vs.O TFS é semelhante a uma picape Ford versus um Mercedes 500, dá conta do recado, mas não é bonito nem confortável, a fusão tem muito a desejar.Eu prefiro a ferramenta de mesclagem TFS, pois parece que o desenvolvedor de ramificação está ali trabalhando com você, é tão inteligente.Nosso SVN interno parecia estar muito corrompido, por isso o abandonamos e fomos para o TFS e não olhamos para trás.O armazenamento de conjuntos de alterações é maravilhoso para uma loja de desenvolvimento ágil, atualmente tem mais de 270 engenheiros no TFS sem problemas ou problemas, o SVN simplesmente não era capaz de lidar com esse tipo de carga sem que alguém tivesse problemas.

Prefiro o CC.NET simplesmente por causa das ferramentas que desenvolvemos internamente para ampliar a funcionalidade de relatórios e administração.No entanto, a compilação do TFS está intimamente integrada e prevemos uma mudança quando atualizarmos para o SQL 2008

Answer 5

Usamos CruiseControl.net desde junho de 2007 e funcionou muito bem para nós.A melhor parte é que ele se integra facilmente ao SVN, que é um provedor de controle de origem muito superior.

Então nossa configuração é:

• Controle de cruzeiro.Net
• SVN
• Trac - para relatórios de bugs e gerenciamento de projetos (integra-se perfeitamente com SVN)
• nunit - para teste de unidade

Tivemos um grande desenvolvimento paralelo em andamento e a experiência de ramificação e fusão foi espetacular.Se você tiver escolha, eu escolheria a configuração acima!