Vale a pena utilizar o Team Build?

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

  • http://pedroreys.com/ Pedro Reys

    Oi Andre,

    Muitas dessas vantagens que voce listou soa, na verdade, vantagens de um servidor de build. Nao necessariamente do TeamBuild.

    Deixa eu mudar a pergunta um pouco entao: Quais as vantagens de usar o Team Build ao inves de um outro servidor de build/CI server como Teamcity ou Hudson/Jenkins?

    • http://www.facebook.com/AndreDiasBR Andre Dias

      Na prática, todos eles em algum momento vão chamar o MSBuild. Para Continuous Delivery, até o TFS precisa de customização, então não tem vantagem pra nenhum também. O que poderia diferenciar são os “serviços agregados” da ferramenta de build, como agendamento de builds, suporte a agentes para builds distribuidas e paralelas, suporte a mecanismos de notificação, geração de relatórios, integração com testes, porém todos eles também oferecerem os mesmos recursos.
      Com isso, acaba sobrando a integração, facilidade de administração (TCO) e extensibilidade que é onde eu vejo que o TFS ganha.
      Integração: Eu não tenho que fazer nada pro TFS ter integração com Issue Tracker ou VCS. Instalou, tá funcionando. Além disso, outros produtos como o Visual Studio e o Test Manager, tiram grande vantagem do Team Build, principalmente em questoes de rastreabilidade.
      Administração: Quando eu tenho que atualizar minha plataforma, eu atualizo só o TFS, não preciso ficar mantendo Jira, Hudson, e outros e verificando se a versão 1.0 de um conversa com a 2.0 do outro.
      Extensibilidade: Outra grande vantagem do Team Build é a extensibilidade. Eu consigo definir toda a orquestração da minha build através de um Workflow absurdamente robusto. Talvez eu até consiga o mesmo nível de customização no Team City, mas editar XML na mão, sem dúvida dará mais trabalho.