Porque usar o Team System?

Se você está numa luta para convencer seu gerente e diretores de que o Team System é a solução para todos os seus problemas, vou tentar ajudá-lo.

Abaixo, algumas features que dei ênfase nos argumentos que montei.

• Team Foundation Version Control: Um controle de versão completamente integrado ao Visual Studio 2008 e com novas funcionalidades que contribuem para mais produtividade e entendimento das alterações. As novas features incluem:
  • Annotate: É possível saber quem e quando uma linha ou trechos de código foram alterados;
  • Latest on Check-out: É possível configurar o TFSVC para que envie a última versão do arquivo checado ao desenvolvedor automaticamente;
  • Check-out compartilhado e Merge Tool: O check-out compartilhado e a ferramenta de merge foram melhorados para que o “pesadelo” de realizar um merge acabasse.
• Integração contínua: Não é mais preciso trabalho manual para gerar uma versão para debug e/ou para release. Com o Team Build é possível automatizar esse processo. Por exemplo, uma build de debug pode ser gerada a cada check-in para controle de qualidade; Pode ser configurada uma build para release, bastando inclui-lá na fila quando necessário.
• Modelagem de testes de carga: Não é preciso publicar sua aplicação num ambiente de testes e requerer trabalho manual para fazer testes de carga. O Team System 2008 conta com wizard para criar testes de carga que simulam a utilização real da sua aplicação, totalmente parametrizável.
• Métricas de código: É possível monitorar e encontrar falhas de manutenabilidade em seu código usando o Code Metrics. Com isso, seu código pode agora “falar” e mostrar onde é necessário dar uma atenção especial para melhorias.
• Análise de Código (FxCop): O FxCop que usamos atualmente como um software separado do Visual Studio pode agora ser utilizado de forma integrada, mostrando warnings em tempo de desenvolvimento. No VS 2008 foi implementada também análise de código para T-SQL.
• Análise de performance: Com essa feature, é possível identificar gargalos de performance em sua aplicação. Ele aponta o trecho de código que está causando perda de performance, facilitando e agilizando manutenção.
• Web Access: Uma interface web para o Team Foundation Server que permite gerenciar Work Items, Documentos do projeto, relatórios e controle de código. Com isso, não é obrigatório que alguém que precise ter visão do projeto tenha necessidade de instalar as ferramentas de desenvolvimento.
• Migração do SS 2005 facilitada: há ferramentas que auxiliam no processo de migração do Visual SourceSafe para o Team Foundation Version control.
• Check-In Policies: é possível configurar políticas de check-in que obrigam o desenvolvedor a verificar algumas regras antes de subir seu código. Estas regras incluem:
• • Análise de código: É possível negar o check-in se houver warnings no Code Analisys;
  • Testes unitários: Pode-se obrigar o desenvolvedor a rodar os testes unitários da aplicação antes do check-in. E este só será permitido se nenhum teste “quebrar”.
  • Vínculo a um work item: Com essa política, pode-se evitar que um desenvolvedor simplesmente baixe código, modifique e suba novamente sem que uma tarefa tenha sido atribuida a ele. Isso caracteriza que para que o desenvolvedor faça uma modificação no código, ele tenha uma solicitação e motivos para isso.
  • Qualidade da última build: Se a última build integrada estiver quebrada, podemos negar check-ins até que o problema que tenha causado sua quebra seja resolvido. Isso ajuda quando ao acúmulo de problemas. Imagine o cenário em que a build já estava quebrada e o desenvolvedor sobe mais código… Com mais problemas…

Se eu lembrar de mais vantagens (e tem ), atualizo este post.

Abraços