A primeira parte dessa sequência de posts foi sobre os novos Agents do TFS e VSTS, e finalizou com um passo a passo de uma instalação e configuração do Agent responsável pelo Build. Mas para o Fabrikam Fiber estar totalmente na vNext, além do Build, temos que entregar a infra para Release usando o novo Agent.
É o que faremos a seguir…
Arquitetura
Vamos abstrair o fato que estamos usando a mesma VM para os stages nesse exemplo. Para quem se lembra de ter executado o HOL de deploy com o Release Management, a VSALM tem 3 ambientes configurados para o Fabrikam Fiber, em portas diferentes do IIS, na imagem a porta destacada, 10000, é a do stage de Produção.
Em um ambiente real, teríamos ao menos uma máquina para cada stage, espelhando o ambiente de Produção, em alguns casos, este pode estar em um balanceamento de carga, e aí o ambiente de teste poderia reproduzir essa configuração então seria uma máquina para Dev, duas para Teste, duas para Produção, mas para efeito deste exemplo vamos utilizar somente uma VM ao invés de cinco máquinas! 🙂
Então vamos instalar um Agent… não! Vamos instalar três Agents, mas em uma mesma máquina.
Queues e Pools
Vamos separar aqui Queues e Pools para os Agents de deploy, apesar de ser possível utilizar a mesma já criada. Pois é interessante ter uma “infra-estrutura” específica para o pipeline, para isso é preciso criar uma nova Queue, em Agent Queues, no modo de Administração.
Agora já temos onde ligar os Agents de deploy.
Deploy Agents
Instalação
A instalação é a mesma do anterior, então se você tem o Zip ainda na raiz do C, copie e cole o arquivo três vezes, CTRL + C e CTRL +V, e renomeie-os como abaixo.
Agora é só extrair as pastas.
Configuração
A configuração é a mesma, porém agora o nome do Agent é o nome da máquina e seu stage, de resto é só seguir os 7 passos anteriores, mas caso esteja com presa e não quer procurar, vou reproduzir aqui:
- Nome do Agent, como é um agente de deploy, gosto de nomear com o nome da máquina, o que faz todo o sentido, neste caso: VSALMDev, VSALMQA e VSALMProd;
- URL para o TFS, não incluia a collection;
- Qual pool este Agent irá pertencer, eu criei um pool da aplicação, então todas as máquinas serão colocadas aqui, que é FabrikanFiber;
- Será solicitado um work folder, que é o local onde será feito o download dos binários para ser usado no deploy, de novo, não existe razão para não aceitar a sugestão do Agent.
- Configure como serviço caso o Agent não precise executar nada em modo Interactive
- Conta que irá rodar o serviço, a já conhecida RMDeploy, se você estiver herdando uma infra do RM, ou crie uma só como Deploy, para o exemplo utilizei outra.
- Digite o password da conta escolhida.
Para verificar se tudo deu certo, você deverá ter no Agents Pools:
Agora que temos a infra, vamos criar em posts futuros build e deploy vNext.
Arquitetura 2
Como escrito no post anterior, o uso racional de recursos acabou entregando somente um Agent para fazer as duas tarefas… Mas, então, por que não usar apenas um Agent, o da máquina de build, daria certo? Sim!
A ideia dos Agents novos é que o time administre os recursos, por isso você pode atribuir a administração deles para outras pessoas.
E nessa segunda arquitetura eu proponho ter uma máquina de build/release com um agent, onde seria feito a compilação dos binários, e esse Agent faria a coordenação de deploy entre as máquinas dos stages. Diminuiria setup e até mesmo uma possível manutenção nos stages por conta do agent, porém ao custo de onerar os builds nessa máquina. Ou pode-se fazer ter mais agents em uma máquina centralizadora, build e deploy… As opções comçam a abrir neste momento.
Agora é partir para a definição de build e release… mas antes, temos mais algumas features desses agents que eu quero expor, até a parte 3.
Emmanuel Brandão