A JetBrains lançou o plug-in Warm Agents para a plataforma TeamCity para lidar com um dos pontos de atraso mais comuns em ambientes de integração e entrega contínuas: esperar que um agente de build em nuvem seja iniciado antes do começo dos testes ou do processo de build. O plug-in permite manter um número-alvo de agentes ociosos e previamente iniciados para cada imagem de nuvem, de modo que o TeamCity comece a provisionar um novo agente assim que o número ficar abaixo do nível definido.
O plug-in funciona com qualquer provedor de nuvem compatível com o TeamCity, o que o torna adequado para equipes que usam agentes temporários em vez de manter uma infraestrutura de build completa em execução. A ideia é especialmente voltada para tarefas curtas nas quais o tempo de preparação do ambiente pode ser maior que o tempo de execução; um agente Windows em nuvem de inicialização lenta, por exemplo, pode manter um teste de um minuto na fila por vários minutos adicionais.
O que muda na prática?
Em vez de criar os agentes somente quando a tarefa chega, o TeamCity monitora o número de agentes ociosos para cada imagem de nuvem e inicia novas instâncias quando a quantidade fica abaixo da meta. O número pode ser configurado pela REST API ou nas configurações do projeto, no caminho Project Settings | Integrations | Warm Agents. O valor zero é usado para interromper a manutenção de agentes prontos para uma determinada imagem.
O plug-in exige o TeamCity 2024.12.3 ou uma versão mais recente, um perfil de nuvem e uma imagem de nuvem configurados em um projeto, além da permissão Manage project’s agent cloud profiles. Depois de instalado e habilitado pelo JetBrains Marketplace, ele pode ser administrado pela REST API ou pela ferramenta teamcity-cli.
O custo da velocidade e os limites de expansão
O Warm Agents não oferece aceleração gratuita. Cada agente pronto em execução consome uma licença de build agent, enquanto as instâncias de nuvem ociosas continuam gerando custos para o provedor de nuvem. Portanto, o plug-in estabelece uma compensação clara entre tempo de espera e gastos operacionais, e aumentar a meta nem sempre representa uma melhoria prática quando a demanda real é baixa.
O TeamCity respeita o número máximo de instâncias em execução definido pela imagem de nuvem, mesmo que a meta de agentes seja configurada com um valor maior. As instâncias também são iniciadas em lotes, com pequenos intervalos, por isso alcançar uma meta elevada pode levar algum tempo. Ao reduzir a meta, o TeamCity não interrompe à força os agentes em execução; o tempo limite de ociosidade definido para a imagem de nuvem continua válido, com a possibilidade de algumas instâncias interrompidas serem reiniciadas para manter a quantidade desejada.
Agendamento e medição
A JetBrains sugere usar tarefas agendadas para alterar a meta de acordo com o padrão de demanda, como aumentá-la pela manhã e reduzi-la a zero à noite. Isso pode ser feito com Kotlin DSL e chamadas à REST API, armazenando o token OAuth como um parâmetro do tipo senha para que ele não apareça nos logs de build.
O plug-in também expõe métricas no formato Prometheus para cada imagem de nuvem, incluindo indicadores de uso e saturação, para ajudar as equipes a identificar os períodos de pico de demanda e verificar se o número de agentes prontos acompanha a fila. Em ambientes com vários nós, a solicitação das métricas deve ser direcionada ao nó principal por meio do perfil de cookie específico para esse fim.
Por que esta notícia é importante?
O plug-in oferece um mecanismo direto para transformar o tempo de preparação dos agentes de um atraso imprevisível em um recurso que pode ser configurado e monitorado. Seu valor prático será maior para equipes com tarefas curtas e recorrentes ou com picos de demanda previsíveis, enquanto o custo pode não justificar manter agentes aquecidos em projetos de execução intermitente. Portanto, sua adoção exige comparar o custo da ociosidade com o tempo de espera real e usar as métricas para ajustar a meta, em vez de escolher um número fixo elevado.