O TFS, sempre comparado a um simples versionador de código fonte, sempre vejo perguntas do tipo “qual a vantagem  do TFS em relação ao SVN?”; tem uma importante parte negligenciada constantemente por empresas que não possuem um bom processo de ALM: build.

É nesta etapa do processo que são gerados os binários para instalação nos diversos ambientes de um pipeline de continuous delivery, por exemplo, é neste momento que é possível verificar bugs, medir entrega da equipe, de fornecedores de fábricas de software e por aí vai…

Até a versão 2013 o TFS e o VSTS também, tinham o Team Build, um processo que utilizava uma definição de build escrita em XAML, amada por uns e criticada por outros, este processo amarrava o build na plataforma Microsoft, era um tanto complexo de customizar. Por isso, com a mudança do mindset da empresa, a alteração da infra-estrutura de build como visto no post De Controllers e Agents para Pools e Queues na nova arquitetura de build vNext, uma mudança no modelo é esperada.

O TFS 2015 traz o build vNext, que em algum momento deve ser tornar o build do TFS, propriamente dito. Uma pista é que o build baseado em XAML foi renomeado XAML definitions e o novo simplesmente Build definitions. Ou seja, provavelmente irá desaparecer. Vamos ver mais sobre seu funcionamento.

build vNext

Preferencialmente novos build devem ser criados como o novo build do TFS. Então vamos começar migrando um build existente para o build vNext, vamos usar a já conhecida máquina do Brian. Navegando para o TP FabrikamFibe (1) e clicando no menu Build (2), veremos as primeiras grandes mudanças: agora a relação de definição de build está no Web Access, sendo possível até mesmo a criação de novas. Se você tem o Visual Studio instalado somente para criar builds verá que não é mais necessário, agora será criada on-line. Este projeto já tem um build, XAML (3).

Para criarmos um novo clique no sinal verde de ‘+’, será mostrado alguns templates, build para iOS com o Xcode e se utilizando do Xamarin para Android e o velho conhecido Visual Studio, que já está selecionado, então só clique OK.

Três grande áreas: menu (1), steps (2), parâmetros dos steps (3)

Para este exemplo vamos fazer algumas customizações, só para conhecermos melhor as possibilidades.

É possível desativar um step sem retirá-lo da definição de build, vamos fazer isso com o Visual Studio Test, selecione-o e na área de parâmetros desmarque a opção Enable, que está dentro de Control Options, veja que dentro desta área você pode determinar se um step continua a rodar mesmo que seja gerado um erro ou se ele sempre irá rodar, ou seja, se o step anterior gerar um erro obrigatoriamente ele roda.

Uma boa prática é clique no botão Salvar, assim você estará mais seguro que as alterações estão sendo salvas. E aí vai mais uma novidade: agora temos um histórico de alterações!

Fazer comentários significativos e mudanças por baby-steps é uma boa prática, quando muitas mudanças são feitas ao mesmo tempo fica difícil saber qual gerou um problema ou mesmo qual foi desnecessária, ficando ruim para desfazer.

Clique no step Publish Build Artifacts (1), é nesse passo que os binários são copiados para a pasta de ‘drop‘, nos parâmetros mude Artifact Name para File share (2), agora é preciso mudar o path para a pasta de drop.

Quando a definição de build é salva, ela é publicada imediatamente, se existe a necessidade de se fazer várias mudanças e não se quer perder alguma configuração, por causa de uma pane no navegador, por exemplo; é possível salvar como Draft e publicar depois.

Configurações globais

Repository

Em repository configuramos o tipo de repositório (1), nome (2), se ele será reiniciado a cada build (4), bom para previnir falhas; e o mapeamento (5). Nenhuma novidade do que já era feito antes.

Triggers

Em Triggers (1), podemos definir se este build irá ser um CI, continuous integration, ou se ele será agendado. Como já temos um build noturno para este TP, baseado em XAML, vamos criá-lo como CI.

Ponto interessante, mesmo sendo um repositório TFVC, é possível escolher um local de monitoramento. Se um check-in, for feito neste local irá disparar o build. Por padrão ele coloca o caminho mais alto do respositório. Se fosse do tipo Git, o monitoramento estaria nas branchs.

General

Em General o mais importante é configurarmos qual a queue para esta definição de build, conforme escrito acima leia este post, para entender como funciona queues e pools.

History

Aqui é possível ver todas as modificações, salvando as mudanças agora pode-se ver o seguinte histórico:

É possível selecionar duas mudanças e fazer um diff!

Tornando a tarefa de “debugg” nas mudanças de build muito mais simples. Repare, que apesar de os steps serem escritos em Powershell, o arquivo de definição de build é um json!

Não vimos aqui o Variables e Options, no primeiro é o local para se criar variáveis que serão utilizadas durante o build, vamos ver isso em um próximo post; no segundo é onde escolhemos a configuração de build, para este exemplo, vai ficar no default.

Para finalizar, vamos renomear a definição de build para FabrikamFiber_CI, conforme imagem abaixo.

Queue seu primeiro build

Vamos rodar para testar? Clique

Note que ele mostra no browser a execução em tempo real, no formato de um console Powershell.

E… temos um erro! Clicando no step que deu erro (1), lateral direta da tela, vamos procurar a linha de erro no log (2), é possível se guiar pela coluna esquerda (3), onde tiver erro ela ficará vermelha, parecido com os diff do Visual Studio.

O usuário que está executando o Agent não tem permissão de escrita nessa pasta. Mudando essa configuração, o build irá executar.

Clicando no link Logs, é possível visualizar tudo o que foi executado, ou fazer download do arquivo no botão ‘Download all log as zip‘.

Clicando no link do build executado a seguinte tela é apresentada.

Nela é possível ver a relação de mudanças associadas a este build, no exemplo changesets, mas também aparecem os Workitems. Também tem um link para baixar os artefatos compilados.

Um pouco mais sobre os Steps

Os steps são as antigas tasks de um modo geral. No XAML para criar uma task era preciso programar e gerar uma dll, alterar a definição de build, que muitos reclamavam ruidosamente, publicar, etc… Realmente era um processo moroso. Os steps agora são scripts Powershell! Muito mais alinhado com a cultura DevOps.

Como no exemplo escolhemos o template Visual Studio, já temos 4 steps, mas é possível customizar esse template simplesmente adicionando outros, para isso é só clicar no botão Add build step.

Já existem tarefas do tipo Maven, Gulp, e até mesmo para empacotar para um Nuget. E como dito antes, é Powershell, portanto fácil de expandir essa coleção. Na próxima semana veremos como fazer isso.