Em post anterior conhecemos a nova arquitetura de Agents para o build, ou build vNext. Esse agent foi aproveitado também para a arquitetura do Release, o substituto do Release Management, disponível agora tanto no VSTS, como no TFS 2015, a partir do Update 2.

Vamos conhecer um pouco mais do processo de setup e configuração deste Agent, para uma infra-estrutura para build e release!

Arquitetura

É interessante que com a integração das features de Release no TFS/VSTS, do produto Release Management, fosse feito um uso racional das ferramentas que estavam sendo construídas, já que tanto o Build como o Release estão fazendo uso intensivo de comando escritos em scripts em Powershell.

Se o Build é a execução de um workflow, build definition, em Powershell em uma máquina por um Agent, por que não reaproveitar essa tecnologia para executar um workflow de deploy de uma Release e também fazê-lo em Powershell?

O Agent do TFS/VSTS torna a máquina na qual é instalada sua “escrava”, adicionando-a aos recursos disponíveis na sua infra de ALM, tanto para Build, quanto para Release e você que definirá o que será executado ali.

Instalação e Configuração

O Setup e config de um Agent é feito, praticamente, ao mesmo tempo, diferentemente do anterior, em que era preciso instalar o “core” do TFS e em seguida abrir o wizard de configuração em um console idêntico ao do App Server do TFS.

Vamos criar então uma infra-estrutura básica para a construção do build do projeto Fabrikam Fiber na VM do Brian Keller.

Build Agent

Baixando o Agent

Você pode fazer o download dos binários do Agent na aba Agent Queues da página administrativa de uma TP Collection.

O pacote compactado contém a instalação do Agent, é só copiá-lo para a máquina que servirá de build machine ou que será um servidor de deploy. Coloque o arquivo Zip na raiz do disco C da VM. Renomeie-o para AgentBuild.zip. Descompacte-o.

Isso é o processo de instalação!

Configurando Queues e Pools

Antes de configurarmos o Agent precisamos criar a infra ao qual ele irá se conectar.

A máquina de build normalmente é criada seguindo um dos padrões: por tecnologia, por time, … Normalmente é a primeira, o que neste caso seria uma máquina para build de aplicações .Net. E já que ela seria cross-team project vamos conectá-la no Pool Default, que está ligado a Queue Default.

Configurando o Agent

Navegue para a pasta do Agent em um console elevado, e execute o arquivo ConfigureAgent.cmd, são apenas 7 perguntas que esse wizard fará:

1. Nome do Agent, como é um agente de build, e eu divido por tecnologia, eu gosto de nomear Agent-BuilddotNet, por exemplo, como teremos um só Agent-Build
2. URL para o TFS, não inclui collection
3. Qual pool este Agent irá pertencer, como visto em De Controllers e Agents para Pools e Queues na nova arquitetura de build vNext um Agent pertence a somente um Pool, e definimos que este de Build seria no Default. Poderíamos ter um Pool de agents de build .Net. O wizard já sugere o Default, então é só dar enter e prosseguir.
4. Será solicitado um work folder, que é o local onde será feito o download do código para ser usado em uma compilação, por exemplo, e não existe razão para não aceitar novamente a sugestão do Agent.
5. Configure como serviço caso o Agent não precise executar nada em modo Interactive
6. Conta que irá rodar o serviço, a já conhecida TFSBuild é a correta, para o exemplo utilizei outra.
7. Digite o password da conta escolhida.

Pronto! O serviço será instalado e para conferirmos a sua disponibilidade é só acessarmos a aba Agent Pools, clicando na Pool Default, é mostrado os Agents registrados e a cor verde na laterial indica que está disponível.

Na segunda parte vamos configurar os Agents necessários para o Deploy.

Emmanuel Brandão