TFS Build
DiogoKN
Qual são as principais vantagens do Build no TFS? Preciso justificar o
investimento e gostaria muito da opnião de vocês.
Obrigado,
Diogo
Leandro Prado
André Dias
A lista é longa:
· Independência de pessoas e estações de desenvolvimento
o Qualquer pessoa com permissão pode gerar a build com apenas um click. Você não fica dependendo de apenas uma pessoa que tem a máquina configurada para gerar a build;
· Melhora as práticas de versionamento de código
o É muito comum o código compilar na máquina do desenvolvedor, mas quando vai pro build server, não funciona de jeito nenhum. Isso normalmente ocorre devido a um gerenciamento de dependências ruim.
o Como no build server é uma máquina independente e ele compila o código que está no servidor, automaticamente você será obrigado e melhorar sua estratégia de versionamento para garantir que a sua build rode em qq máquina, inclusive, no servidor de build;
o 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
o 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
· Relatórios
o Diversos relatórios cruzando informações sobre qualidade, build, bugs são gerados automaticamente pelo simples fato de você utilizar o Team Build;
· Políticas de check-in
o Você pode impedir que o programador suba 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
o 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
o 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
o Recurso muito bacana que permite bloquear o check-in do programador caso a build falhe, seja por problemas de compilação, testes, arquitetura ou qq outro motivo.
· Automação de Deployment
o 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
o Toda vez que você gera uma build, o Team Build automaticamente identifica quais changesets e work items foram incluídas na build. Com isso você consegue saber que na build XYZ, o caso de uso Cadastrar cliente foi incluído e os arquivos a.cs e b.cs foram modificados. Isso ajuda a atender práticas de CM requeridas pelo CMMi, MPS.br, ITIL, etc.
· Integração com o Microsoft Test Manager
o Se você utilizar o MTM, o seu tester assim que identificar que uma nova build foi gerada, ele saberá que BUGs ele precisa verificar e quais planos de testes foram afetados e precisam ser retestados.
· Gerenciamento de Builds
o 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ático;
o Você não precisa se preocupar em aplicar labels no seu código fonte. O team build já faz isso pra vc e caso você queria alterar um código que está em produção, basta criar uma branch da label que o Team Build gerou.
· Totalmente extensível
o Se nada disso acima te atender, você pode ir além e estender o workflow, eventos, e tudo mais que você imaginar J
Espero ter ajudado com a sua justificativa.
Abraços
André Dias
ALM Ranger, ALM MVP
@AndreDiasBR