JetBrains ha lanzado el complemento Warm Agents para la plataforma TeamCity con el fin de abordar uno de los retrasos más habituales en los entornos de integración y entrega continuas: esperar a que se inicie un agente de compilación en la nube antes de comenzar las pruebas o el proceso de compilación. El complemento permite mantener un número objetivo de agentes inactivos y previamente iniciados para cada imagen de nube, de modo que TeamCity comienza a aprovisionar un agente nuevo en cuanto el número cae por debajo del nivel establecido.
El complemento funciona con cualquier proveedor de nube compatible con TeamCity, lo que lo hace adecuado para equipos que utilizan agentes temporales en lugar de mantener en funcionamiento una infraestructura de compilación completa. La idea está especialmente orientada a tareas breves cuyo tiempo de preparación del entorno puede superar el tiempo de ejecución; por ejemplo, un agente de Windows en la nube que arranca lentamente puede mantener una prueba de un minuto en la cola durante varios minutos adicionales.
¿Qué cambia en la práctica?
En lugar de crear los agentes únicamente cuando llega una tarea, TeamCity supervisa el número de agentes inactivos para cada imagen de nube y lanza nuevas instancias cuando el número cae por debajo del objetivo. El número puede configurarse mediante la API REST o desde la configuración del proyecto, en la ruta Project Settings | Integrations | Warm Agents. El objetivo cero se utiliza para dejar de conservar agentes preparados para una imagen determinada.
El complemento requiere TeamCity 2024.12.3 o una versión posterior, un perfil de nube y una imagen de nube configurados dentro de un proyecto, además del permiso Manage project’s agent cloud profiles. Después de instalarlo y habilitarlo desde JetBrains Marketplace, puede administrarse mediante la API REST o la herramienta teamcity-cli.
El coste de la velocidad y los límites de escalado
Warm Agents no ofrece aceleración gratuita. Cada agente preparado que permanece en funcionamiento consume una licencia de build agent, mientras que las instancias de nube inactivas siguen generando costes para el proveedor de nube. Por ello, el complemento establece una compensación clara entre el tiempo de espera y el gasto operativo, y aumentar el objetivo no siempre implica una mejora práctica si la demanda real es baja.
TeamCity respeta el número máximo de instancias en ejecución definido por la imagen de nube, incluso si el objetivo de agentes se configura con un valor superior. Además, las instancias se lanzan por lotes con intervalos breves, por lo que alcanzar un objetivo elevado puede tardar un tiempo. Al reducir el objetivo, TeamCity no detiene por la fuerza a los agentes en funcionamiento; el tiempo de inactividad definido para la imagen de nube sigue vigente, con la posibilidad de que algunas instancias detenidas vuelvan a iniciarse para mantener el número objetivo.
Programación y medición
JetBrains propone utilizar tareas programadas para cambiar el objetivo según el patrón de demanda, por ejemplo, aumentarlo por la mañana y reducirlo a cero por la tarde. Esto puede ejecutarse mediante Kotlin DSL y llamadas a la API REST, almacenando el token OAuth como un parámetro de tipo contraseña para que no aparezca en los registros de compilación.
El complemento también muestra métricas en formato Prometheus para cada imagen de nube, incluidos indicadores de uso y saturación, con el fin de ayudar a los equipos a identificar los periodos de máxima demanda y comprobar si el número de agentes preparados acompaña a la cola. En entornos con varios nodos, las solicitudes de métricas deben dirigirse al nodo principal mediante el perfil de conexión correspondiente.
¿Por qué importa esta noticia?
El complemento ofrece un mecanismo directo para convertir el tiempo de preparación de los agentes de un retraso impredecible en un recurso que puede configurarse y supervisarse. Su valor práctico será mayor para los equipos con tareas breves y repetitivas o con picos de demanda previsibles, mientras que el coste puede no justificar mantener agentes preparados en proyectos de ejecución intermitente. Por ello, su adopción requiere comparar el coste de la inactividad con el tiempo de espera real y utilizar las métricas para ajustar el objetivo, en lugar de elegir un valor fijo elevado.