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:
- 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;
- 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;
- Integração Contínua
- A cada check-in você poderá:
- Executar testes de automatizados (inclusive de UI) garantindo que as funcionalidades existentes não sejam quebradas (teste de regressão);
- Ligar o Code Coverage e saber o percentual de código que os testes estão cobrindo;
- 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;
- Execução de análise de código estática;
- A cada check-in você poderá:
- 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;
- 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;
- 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;
- 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;
- 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.
- 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;
- 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;
- 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;
- 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;
- 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;
- 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
André Dias
André Dias é sócio-fundador da Lambda3, Visual Studio ALM Ranger & MVP e Professional Scrum Developer Trainer pela Scrum.Org. É graduado em Ciência da Computação pela Unip, atua na área de desenvolvimento de softwares a mais de 13 anos e nos últimos anos tem se dedicado as práticas de ALM (Application Lifecycle Management) e de Agilidade. Foi consultor de ALM da Microsoft Brasil, morou na Irlanda onde trabalhou em projetos para o governo Irlandês. No Brasil atuou em dezenas de projetos, muitos deles para o governo e para grandes instituições financeiras. Tem participação ativa na comunidade através da realização de palestras, organização de eventos, seu blog e seu twitter em @AndreDiasBR