Artigos .NET Automatizando o processo de build - Revista .Net Magazine 101

Artigo do tipo Tutorial
Recursos especiais neste artigo:
Contém nota Quickupdate, Conteúdo sobre engenharia.
Automatizando o processo de build
O processo de build de um software é responsável por verificar se todos os componentes do nosso código fonte estão sendo integrados de maneira correta. Esse processo geralmente é manual, conforme o passar do tempo se torna uma tarefa repetitiva e propensa a erros. Para resolver este problema é necessário automatizar esse processo e uma das maneiras é utilizando o TFS.

Em que situação o tema é útil
Este tema é útil a todas as equipes de desenvolvimento que desejam aumentar a eficiência de seu processo com a
adoção da prática de automatização de builds, ganhando-se produtividade e
confiabilidade no processo.

Quando começamos a falar em build, logo pensamos no famoso atalho no Visual Studio - a tecla F5 - que é responsável por realizar o build do nosso projeto. O que geralmente ocorre em muitos projetos e equipes é eleger um membro da equipe para ser responsável por essa atividade (o famoso buildero), onde apenas na máquina dele o build consegue ser gerado, o que nos leva a ter uma dependência de pessoas para que o processo possa ocorrer. Um processo de build deve ser capaz de ser executado por qualquer membro da equipe em qualquer momento.

Um processo de build geralmente é composto pelos seguintes passos:

1. Recuperar a última versão do controlador de fontes

2. Executar o Build

3. Executar os planos de teste (unitários, integração, interface, etc)

4. Executar o Deploy para o ambiente

Quando estamos criando um processo de build devemos ter atenção nas seguintes questões:

1. Qual a frequência que devemos executar nosso build?

2. Qual o plano de Rollback?

3. O processo está de fácil manutenção?

4. O processo está de fácil execução?

Com o objetivo de solucionar os problemas relacionados a build, o TFS possui uma feature chamada Team Build que é responsável por executar qualquer processo de build do seu projeto, seja ele feito em .NET, Java, PHP, etc.

Arquitetura do TFS Build

Como podemos ver na Figura 1, o servidor TFS Build é responsável por:

· Hospedar os Controllers

· Hospedar os Agents

· Realizar a comunicação entre os projetos e o servidor de build

Quando um build é executado, o controller é acionado e realiza o download do processo que aquele build deve ser executado, após isso o controller aciona um agente que será responsável por executar o processo de build.


Figura1. Arquitetura do TFS Build

Controller

É um serviço do windows que é responsável por gerenciar todo o processo de build, o controller inicializa o processo, delega as atividades para um ou mais agentes e finaliza o processo. Para cada servidor de build é possível configurar somente um controller e o este pode estar configurado apenas em uma Collection (Nota do DevMan 1) do TFS.

Nota do DevMan 1

O conceito de Collection foi introduzido a partir do TFS 2010 e é utilizado para organizar os projetos dentro do TFS. Para cada Collection podemos ter um conjunto de Team Projects. Essa abordagem nos permite isolar os projetos em collections diferentes auxiliando na segurança, backup/recovery e compartilhamento de informações entre projetos.

Agentes

É um serviço do Windows responsável por executar as tarefas relacionadas ao acesso ao disco, como criação de um workspace local para obter os arquivos do source control, executar a compilação do projeto, executar os testes, realizar a associação com os ChangeSets (Nota do DevMan 2), copiar o resultado do build para o diretório de destino, etc. Para cada controller podemos configurar vários agentes.

Nota do DevMan 2

A cada CheckIn que realizamos no TFS é gerado automaticamente um ChangeSet que contém todos os arquivos alterados, comentários da atualização e work itens referente a alteração. Um changeset é útil quando queremos recuperar e realizar o merge de uma versão específica ou para realizar um build de uma alteração especifica do código fonte.


Build Process Template

O Build Process Template é um workflow criado com WWF (Nota do DevMan 3) que contém uma sequência de atividades que devem ser executadas quando o processo de build é executado.

Nota do DevMan 3

WWF - Windows Workflow Foundation é uma tecnologia da Microsoft lançada na versão do .NET Framework 3.0 com o objetivo de automatizar os processos de maneira intuitiva baseado em uma sequência de atividades. Para maiores detalhes vide seção Links.

Por default, quando criamos um novo Team Project no TFS 2012 é criada uma pasta no source control chamada BuildProcessTemplate, que contém 3 Build Process Template, como podemos ver na Figura 2.



Figura 2. Build Process Template Default

· Default Template – Este template é usado na maioria dos casos, onde temos todos os principais passos para executar um build de aplicações .NET (Web, WCF, WPF, etc)

· Upgrade Template – Este template foi criado para manter compatibilidade com as versões anteriores do TFS (TFS 2005 e TFS 2008) onde eram usados arquivos XMLs para orquestrar as atividades do build

· LabDefaultTemplate – Este template é para executar em um ambiente do Lab Management Feature Pack (Nota do DevMan 4).

Nota do DevMan 4

Lab Management é uma solução integrada com o TFS que tem como objetivo executar os testes da sua aplicação em diferentes ambientes virtualizados. No momento da execução do build são realizados os testes nestes ambientes, caso algum erro ocorra é gerado um snapshot desse ambiente contendo exatamente o momento que ocorreu o erro.

Na Figura 3 podemos ver as principais atividades que o Default Build Template possui.

...
Quer ler esse conteúdo completo? Tenha acesso completo