Ontem, eu respondi uma dúvida no grupo de discussão do ALM Brasil e vou replicá-la aqui, pois acredito que possa ajudar outras pessoas com a mesma necessidade.

A pergunta foi: “Quais são as vantagens de fazer a build no Team Build em vez do Visual Studio?”. Bom, vamos à resposta:

1. Independência de pessoas e de estações de desenvolvimento
   • Qualquer pessoa com permissão pode gerar a build com apenas um click. Você não fica dependendo de apenas uma pessoa que já tem a máquina configurada para gerar a build;
2. Melhora o gerenciamento de dependências
   • É muito comum o código compilar na máquina do desenvolvedor, mas quando vai para o servidor de build, não funciona de jeito nenhum. Isso normalmente ocorre devido a um gerenciamento de dependências ruim;
   • Como o servidor de build é uma máquina independente e ele compila o código que está no source control, se a sua estratégia de versionamento não gerenciar as dependências corretamente, o servidor de build dificilmente conseguirá compilar a sua aplicação, ou seja, ele te forçará a trabalhar direito;
   • Outro ganho que você terá aqui, é que sempre que um programador novo entrar no seu time, a chance dele fazer um get latest version no projeto e compilar de primeira será altíssima;
3. Integração Contínua
   • A cada check-in você poderá:
     1. Executar testes de automatizados (inclusive de UI) garantindo que as funcionalidades existentes não sejam quebradas (teste de regressão);
     2. Ligar o Code Coverage e saber o percentual de código que os testes estão cobrindo;
     3. Validar a arquitetura da sua aplicação e garantir, por exemplo, que a camada de apresentação não faça acesso direto ao banco de dados;
     4. Execução de análise de código estática;
4. Relatórios
   • Diversos relatórios cruzando informações sobre qualidade, build e bugs são gerados automaticamente pelo simples fato de você utilizar o Team Build;
5. Políticas de check-in
   • Você pode impedir que o programador envie um código para o controlador de versão caso a build esteja quebrada. Isso evita que uma build ruim, fique ainda pior;
6. Notificação por e-mail
   • Seu time pode ser avisado toda vez que uma build for executada, falhar ou mesmo ser promovida para ambientes de homologação / produção;
7. Agendamento de Builds
   • Com esse recurso, você pode usar a prática de build noturna e, com isso, quando o programador chegar para trabalhar pela manhã, já saberá se a build está estável ou se tem algo para corrigir do dia anterior;
8. Gated Check-in
   • Recurso muito bacana que permite rejeitar o check-in do programador caso a build falhe, seja por problemas de compilação, testes, arquitetura ou qualquer outro motivo.
9. Automação de Deployment
   • Você pode estender o Team Build para usar frameworks como o MSBuild e MSDeploy para implantar o seu site em homologação/produção e atualizar o seu banco de dados com apenas um click;
10. Rastreabilidade
    • Toda vez que você gera uma build, o Team Build automaticamente identifica e associa as changesets, work items e outros artefatos com a build. Com isso, você consegue ter uma rastreabilidade entre requisitos, código fonte, build e resultados de testes e consequentemente passa a atender práticas de Gerenciamento de Configuração requeridas pelo CMMi,  MPS.br e ITIL;
11. Integração com o Microsoft Test Manager
    • Se você utilizar o MTM, o seu tester, assim que identificar que uma nova build foi gerada, saberá quais BUGs ele precisa verificar e quais planos de testes foram afetados e precisam ser retestados;
12. Gerenciamento de Builds
    • A partir  de um console de gerenciamento, você consegue saber quais builds estão em ambientes de homologação, produção, etc;
13. Aplicação de label automática;
    • Você não precisa se preocupar em aplicar labels no seu código fonte. O team build já faz isso para você e caso você queira alterar um código que está em produção, basta criar uma branch da label que o Team Build gerou;
14. Totalmente extensível
    • Se nada disso acima te atender, você pode ir além e estender o workflow, eventos, e tudo mais que você imaginar;

E aí? Depois de tudo isso, você ainda vai fazer “build” no F5?

Abraços
André Dias