Customizando build process template no TFS – Parte 1

Salve, salve galera !!!

Hoje vamos começar a falar sobre a customização build process template no TFS. A ideia desse primeiro post não é colocar a mão na massa mas sim esclarecer alguns conceitos para podermos prosseguir, OK ? E com os conceitos esclarecidos com certeza irão surgir duvidas e ideias do que/como fazer as coisas o que vai ajudar bastante a prosseguirmos.

Antes de iniciarmos precisamos estar familiarizados com algumas conceitos que serão comentados: o que é um Build ? O que é o Build Process Template ? Como funciona o build dentro do TFS ? E o que são build definitions ?

Vamos la ?

O que são Builds ?

Quando estamos desenvolvendo estamos acostumados no nosso visual studio ou outras IDEs a clicarmos no F5 ( ou outra tecla de atalho ) ou em botão que se assemelha a um Play para executar nossa aplicação, quando fazemos isso e antes da nossa aplicação surgir na tela ocorre o build da mesma que traduzindo ao pé da letra é a construção da nossa aplicação que está para nós em formato legível e visual (na maioria dos casos) em código binário, dlls, exes, etc. Para nós o procedimento é transparente porém temos por trás disso tudo no caso do visual studio por exemplo, um motor chamado MSBuild fazendo esse trabalho, convertendo nosso código C# ou VB.NET em binário.

O que é o Build Process Template ?

O build process template representa a ciclo de vida de um build dentro do TFS, um passo-a-passo que ele tem executar para nascer (iniciar) e morrer (encerrar), ciclo esse que não necessita de iteração de um usuário, mesmo por que, podemos ter build agendados (vamos entender mais pra frente o que significa isso), builds executando em N máquinas, etc. Podemos ainda para ilustrar melhor dizer que o Build Process Template é o esqueleto do processo de build. Esqueleto por que ele precisa ser preenchido com algumas informações.

Tecnicamente falando, o build process template é um arquivo .xaml baseado em Windows Workflow Foundation (WF) onde temos uma serie de atividades (ou activities ), condições, variareis e argumentos, que são desencadeadas de acordo com o roteiro que definirmos. As atividades são os mecanismos de execução das tarefas dentro do ciclo do build. Por exemplo, imaginem que no nosso build queremos que caso ocorra tudo certo a saída desse build (um executável por exemplo) seja levado a um servidor FTP. Então teríamos uma atividade que seria colocada no nosso template de build que faria isso. Não vamos nos preocupar agora com o “como eu faria isso”, só usei esse exemplo para ficar mais claro o que são as atividades. Existem atividades padrões e atividades customizadas. As atividades padrões atendem grande parte dos cenários, mas por exemplo, se quisermos realizar algo que é característico da nossa organização precisaremos criar um atividade customizada (veremos mais a diante). Existem atividades que encontramos para utilizarmos como o Community TFS Build Extensions que fornece um conjunto bem amplo de atividades, mas ainda assim as vezes precisamos customizar as nossas próprias.

Quando disse que temos condições dentro do script, quero dizer que podemos utilizar alguns mecanismos como IF, FOREACH (semelhante ao que fazemos quando estamos desenvolvendo) para direcionar o fluxo de execução, então com isso podemos por exemplo condicionar o upload para o FTP por exemplo a uma verificação em um argumento que criarmos para que o usuário informe na criação da definição de build se quer ou não subir esse arquivo.

E por fim temos os argumentos onde podemos preencher via formulário algumas informações e que iram ditar como o build será executado, o que irá ou não fazer, etc, etc, etc.

Como funciona o build dentro do TFS ?

Quando falamos da arquitetura de Build do TFS temos alguns componentes (não só os citados abaixo, mas no primeiro momento é o que nos interessa):

Build Controller: é o componente responsável por controlar as requisições de build e direciona-las para os agentes de build, caso não haja agente livre é gerada uma fila de espera para execução. Cada Build Controller trabalha com uma única Collection.

Build Agents: é o responsável por executar o build propriamente dito. Está diretamente ligado ao controller e podem haver vários para um mesmo controller, inclusive em servidores diferentes o que garante uma performance maior em ambientes críticos.

Quando disparamos uma solicitação de build o servidor de Build encaminha para o Controller que irá olhar a fila, os build em execução e outras variáveis que estejam presentes no ambiente e então irá direcionar para um Build Agente executar. Podemos ver na imagem abaixo esse fluxo (créditos da imagem para a documentação do produto no site da Microsoft).

Build Process

Build Process

O que são as build definitions ?

Tudo o que vimos até agora foi em um nível técnico considerável, e estamos falamos também nos méritos de arquitetura e configuração do ambiente, mas quando eu vejo meu build sendo executado ? Quando falamos em executar um build estamos falando em enfileirar uma definição de build (lembrem-se do que vimos sobre build agents e controllers) , que nada mais é do que um item baseado em build process template, que contém seus argumentos preenchidos e pronto para ser iniciado. Podemos ter várias definições de build, por exemplo: build da madrugada, build de integração continua, cada um com seus argumentos preenchidos e disparados de uma forma. O que precisamos deixar bem claro agora é que a build definition é a união do esqueleto (build process template) e dos argumentos preenchidos, que são disparados de alguma forma (seja a cada check-in, ou por um agendamento por exemplo) e que segue um fluxo ditado pelas parâmetros e resultado das atividades.

 

Pessoal, encerramos esse post por aqui e a partir do próximo colocaremos a mão na massa. Antes que alguém questione, sim esse post poderia ser efeito apartado já que ele mesmo não fala nada de customização, mas para falarmos unicamente de conceitos de build teríamos que “mastigar” um pouco mais e esse não era o intuito  também achei interessante dar uma contextualizada no assunto.

Caso tenham alguma dúvida é só falarem.

 

Até a próxima !

 

 
Comments

No comments yet.