TFS versus alternativas de código aberto?[fechado]

Question

Atualmente, estamos no processo de configuração de um servidor de controle/construção/e mais de código-fonte para desenvolvimento .NET e estamos pensando em utilizar o Team Foundation Server (que custa muito dinheiro) ou combinar várias opções de código aberto , como SourceForge Enterprise/GForge e Subversion e CruiseControl.net e assim por diante.Alguém já percorreu o caminho do OSS ou é TFS apenas se você quiser acertar e começar a trabalhar logo?

Answer 1

Atualmente, meu trabalho usa um processo de construção principalmente OSS com Cruise Control como mecanismo e é ótimo.Eu sugeriria que, se você não sabe por que precisa do TFS, provavelmente não vale a pena o custo.

O que você deve ter em mente com relação ao material OSS é que o software já foi usado pela equipe Java há anos ou é uma porta de código Java semelhante.É robusto e adequado à finalidade.

A Microsoft não pode enviar código OSS, e é por isso que eles precisam reimplementar muitas coisas de código aberto.Então, não, não é necessário, e milhões de projetos foram enviados nessa pilha.O outro lado é que também há muitos recursos interessantes que você obtém com o TFS e que não obterá (facilmente) com a pilha OSS, como integração com seu software de rastreamento de bugs/recursos.

Answer 2

Sempre segui o caminho do OSS e nunca tive problemas.Eu também recomendaria fortemente o TeamCity para sua solução de CI.Existe uma licença gratuita e acho que ela supera o CC.NET em termos de facilidade de configuração e feedback.

Answer 3

Sou usuário diário do TFS há cerca de 1,5 anos.

• O controle de origem é estável
• Você não pode trabalhar desconectado facilmente.O check-out do arquivo vai para o servidor.
• A mesclagem automática funciona muito bem, exceto que às vezes corrompe o arquivo de origem (problema de codificação).
• TFS tem uma sensação lenta!?Principalmente o gerenciador de testes.Código gerenciado?
• Existem vários bugs bobos na parte de teste, nada crítico.
• As execuções de teste demoram muito para começar (pendente).
• Eu recebo impasses SQL de vez em quando!?
• O rastreamento de problemas é uma merda.Você é forçado a trabalhar em diálogos lentos e integrados, a web é apenas para exibição.Recomendo compará-lo com outros sistemas de rastreamento de problemas, como JIRA
• A construção funciona bem.

Answer 4

Se você estiver usando o TFS, certifique-se de instalar o VSTS2008SP1.A grande maioria das pessoas que vi postando reclamações está usando a versão 2005.2005 é a clássica síndrome do “Microsoft 1.0”.Houve MUITOS problemas que foram corrigidos pelas 2 "versões" posteriores.

O Service Pack para 2008 não é apenas uma correção de bug - mas adicionou muitos novos recursos.

No que diz respeito à escolha versus OSS - há muita discussão (aqui e em outros lugares).Não é um produto barato – mas é a melhor escolha para muitos cenários (e a pior para outros).

Answer 5

Analisamos o TFS, mas acabamos optando pelo Subversion + Trac + VisualSVN.Não fazemos CI no momento, mas acho que Cruisecontrol seria o que usaríamos.

Comecei a usar o Trac com vários projetos de código aberto e é ótimo.Na verdade, é apenas uma parte do que o TFS faz, então você terá que tomar uma decisão - se usar tudo, o TFS provavelmente fará um trabalho melhor ao unir tudo.Trac é um wiki/rastreador de bugs/navegador de origem.Tudo está vinculado - quando você digita o nome de uma WikiPage ou diz "Corrigir bug #1234" em uma mensagem de commit, sempre que você vê essa mensagem no Trac, os links vão para os lugares certos.É uma ferramenta que ajuda você a fazer seu trabalho, mas geralmente fica fora do caminho.

VisualSVN é uma ótima ponte entre o TortoiseSVN (um cliente Subversion) e o VisualStudio e melhora muito a produtividade.Eles têm um teste gratuito e depois não é muito caro (US$ 50/usuário), mas vale a pena.

Uma possível desvantagem do Trac é que no mundo Windows, é difícil trabalhar no IIS.Instalei o Trac muitas vezes, mas fiquei frustrado rapidamente ao tentar fazê-lo funcionar corretamente.Acabei instalando o Apache em um IP diferente (também poderia usar uma porta diferente) e foi perfeito.

Exceto uma pessoa da minha equipe (que tinha um pouco de experiência), ninguém jamais havia usado subversão antes.Alguns usaram VSS e isso é tudo.Todos estavam bastante céticos, mas eu diria que em poucos dias todos se converteram.Depois de aprender totalmente o Trac e se acostumar com tudo (mais alguns dias), todo mundo fica totalmente convencido e adora.

Answer 6

Nossa empresa utiliza a combinação CruiseControl/SVN/nAnt/JIRA com grande sucesso.

O problema com o TFS é que ele só vale a pena para empresas maiores.Será terrivelmente caro para pequenas empresas com 30 desenvolvedores ou menos, que já se beneficiariam enormemente com a combinação de código aberto acima.

Answer 7

Subversion + Cruisecontol.Net é uma boa alternativa.SVN é rico em recursos, estável e flexível.

Answer 8

O benefício real de usar o TFS em comparação com um conjunto separado de ferramentas de sistema operacional é a integração dos vários fluxos de informações disponíveis.

* Crie um requisito e insira no TFS
* Crie um conjunto de tarefas vinculando-as ao requisito e atribua-as aos diversos desenvolvedores
* Cada desenvolvedor trabalha em sua tarefa e faz check-in, atribuindo a tarefa ao conjunto de alterações em check-in
* Uma correção de bug chega, também neste caso o conjunto de alterações será coordenado com a solicitação de correção de bug e você também pode mapear a correção de bug para o requisito original

Feito isso todas as informações podem ser utilizadas para acompanhar o projeto e fazer avaliações sobre o trabalho, como por exemplo quantas alterações uma correção de bug causou, quais são os requisitos que geraram mais bugs ou solicitações de mudança e assim por diante.

Todas essas informações são muito úteis em organizações de médio e grande porte e, pelo que estou vendo agora, não são possíveis (ou muito difíceis) de rastrear a integração de diferentes ferramentas de SO.

Answer 9

A pilha do TFS é muito mais do que controle de origem e uma configuração de compilação CI/noturna.Pense em gerenciamento de projetos, relatórios de bugs e tudo isso resulta em algo mais do que apenas CruiseControl, SVN e NAnt.Apenas os relatórios por si só podem valer o investimento.E lembre-se também de que se você for assinante do MSDN/parceiro ISV gold/etc.você pode conseguir um pouco disso de graça...

Answer 10

Só recentemente comecei a trabalhar com o TFS no dia a dia e, como vim de uma pilha de código-fonte anteriormente aberta, acho que está faltando.

Embora a integração de todo o rastreamento de bugs e tarefas seja um recurso realmente excelente, os pontos negativos o pesam.

Pessoalmente, eu uso a pilha a seguir, que me dá tudo o que precisamos fazer, desde integração contínua até implantações automatizadas em escala empresarial por uma fração do custo:

• Subversão
• Hudson
• nCover
• nDepend
• Símio
• Jira
• Integração Jira e Subversion

Answer 11

Já vi ambos em ação (embora seja um desenvolvedor Java).A vantagem de uma abordagem pick and mix é que você pode escolher as melhores partes para tudo (por exemplo,Eu daria uma olhada no Hudson for CI - é excelente para Java, funciona também para .Net e tem cargas de plugins e é muito simples de usar).A desvantagem é que você mesmo precisa fazer toda a integração.No entanto, isso está ganhando muito mais fácil no mundo Java.Além disso, não deixe que as pessoas digam que um produto compatível é melhor.Em muitos produtos OSS neste espaço a qualidade é excelente e você obtém melhorar suporte da comunidade em vez de esperar por uma resposta do contrato de suporte do seu fornecedor (IBM, estou olhando para você)

Espero que isto ajude.

Answer 12

Eu concordo fortemente com o ponto de que só vale a pena usar o TFS se você souber exatamente para que precisa dele.Os suplementos baseados em OSS, baratos ou gratuitos, como Visual SVN e TestDriven.Net, são tão bons que a integração com o VS já é perfeita.

Answer 13

Pensei em lançar uma nova perspectiva que pode ser vista com cautela, porque ainda não experimentei, mas pretendo usar Mordido para CI em um projeto futuro.Isso é executado sobre o Trac + SVN, duas ótimas ferramentas que usei em muitos projetos com sucesso.

Answer 14

Construímos uma pilha de desenvolvimento gradualmente aqui, atualmente estamos usando:

• Subversão
• CruiseControl
• RedMine (integra rastreamento de bugs com controle de origem e inclui wiki, gerenciamento básico de projetos, etc.).

Answer 15

Acho que o TFS vale a pena por todos os recursos extras mencionados nos posts acima.Sua funcionalidade de construção contínua está faltando seriamente, então aumentamos essa parte usando CruiseControl.NET, o que é incrível.A única razão pela qual escolheríamos contra o TFS se o fizéssemos agora é que estamos migrando para o desenvolvimento multiplataforma de nossos produtos.Então, se você já pensou nisso, pense em OSS.Subversion/Trac seria minha combinação favorita, com CruiseCOntrol.NET ainda sendo a espinha dorsal.CC.NET usando mono funciona bem em Linux e Mac.

Answer 16

O TFS2010 possui um TFS Basic, que não custa nada (além da sua assinatura msdn/licença do visual studio).É limitado a 1 por licença do VS, mas você só precisa de licenças adicionais para não usuários do VS

A automação da interface do usuário no VS2010 por si só torna o TFS um vencedor em termos de soluções de código aberto

Answer 17

Vale ressaltar que a melhor alternativa para uma ampla gama de recursos do TFS não são necessariamente OSS, mas sim comerciais de baixo orçamento, como NDepend para qualidade de código e exploração de arquitetura, NCapa para cobertura de código, TestDriven.NET para testes aninhados no IDE ...