JetBrains a lancé le module complémentaire Warm Agents pour la plateforme TeamCity afin de traiter l’un des retards les plus fréquents dans les environnements d’intégration et de livraison continues : l’attente du démarrage d’un agent de build cloud avant le lancement des tests ou du processus de build. Le module complémentaire permet de maintenir un nombre cible d’agents inactifs et déjà démarrés pour chaque image cloud, de sorte que TeamCity commence à fournir un nouvel agent dès que le nombre passe sous le niveau défini.
Le module complémentaire fonctionne avec tout fournisseur cloud pris en charge par TeamCity, ce qui le rend adapté aux équipes qui utilisent des agents temporaires plutôt que de maintenir une infrastructure de build complète en fonctionnement. L’idée s’adresse particulièrement aux tâches courtes dont le temps de préparation de l’environnement peut devenir supérieur au temps d’exécution ; un agent Windows cloud au démarrage lent peut ainsi laisser un test d’une minute dans la file d’attente pendant plusieurs minutes supplémentaires.
Qu’est-ce qui change concrètement ?
Au lieu de créer les agents uniquement à l’arrivée d’une tâche, TeamCity surveille le nombre d’agents inactifs pour chaque image cloud et lance de nouvelles instances lorsque le nombre passe sous l’objectif. Le nombre peut être configuré via l’API REST ou dans les paramètres du projet, à l’emplacement Project Settings | Integrations | Warm Agents. La valeur zéro permet de désactiver le maintien d’agents prêts pour une image donnée.
Le module complémentaire nécessite TeamCity 2024.12.3 ou une version ultérieure, un profil cloud et une image cloud configurés dans un projet, ainsi que l’autorisation Manage project’s agent cloud profiles. Après son installation et son activation depuis JetBrains Marketplace, il peut être géré via l’API REST ou l’outil teamcity-cli.
Le coût de la rapidité et les limites de montée en charge
Warm Agents n’offre pas d’accélération gratuite. Chaque agent prêt à l’emploi et en fonctionnement consomme une licence d’agent de build, tandis que les instances cloud inactives continuent de générer des coûts auprès du fournisseur cloud. Le module complémentaire établit donc un compromis clair entre le temps d’attente et les dépenses d’exploitation ; augmenter l’objectif n’entraîne pas toujours une amélioration pratique lorsque la demande réelle est faible.
TeamCity respecte le nombre maximal d’instances en fonctionnement défini par l’image cloud, même si l’objectif d’agents est configuré à une valeur supérieure. Les instances sont également lancées par lots avec de courts intervalles, de sorte que l’atteinte d’un objectif élevé peut prendre un certain temps. Lorsque l’objectif est réduit, TeamCity n’arrête pas de force les agents en fonctionnement ; le délai d’inactivité défini pour l’image cloud continue de s’appliquer, avec la possibilité que certaines instances arrêtées soient relancées afin de maintenir le nombre cible.
Planification et mesure
JetBrains recommande d’utiliser des tâches planifiées pour modifier l’objectif en fonction du profil de la demande, par exemple en l’augmentant le matin et en le ramenant à zéro le soir. Cela peut être mis en œuvre via Kotlin DSL et des appels à l’API REST, en stockant le jeton OAuth comme paramètre de type mot de passe afin qu’il n’apparaisse pas dans les journaux de build.
Le module complémentaire expose également des métriques au format Prometheus pour chaque image cloud, notamment des indicateurs d’utilisation et de saturation, afin d’aider les équipes à identifier les périodes de pointe et à déterminer si le nombre d’agents prêts suit la file d’attente. Dans les environnements multi-nœuds, les demandes de métriques doivent être dirigées vers le nœud principal via le profil de cookie prévu à cet effet.
Pourquoi cette actualité est-elle importante ?
Le module complémentaire fournit un mécanisme direct pour transformer le temps de préparation des agents, qui constitue un retard imprévisible, en une ressource configurable et surveillable. Sa valeur pratique sera plus importante pour les équipes qui exécutent des tâches courtes et répétitives ou qui connaissent des pics de demande prévisibles, tandis que le coût du maintien d’agents chauds peut ne pas être justifié dans les projets à exécution intermittente. Son adoption nécessite donc de comparer le coût de l’inactivité au temps d’attente réel et d’utiliser les métriques pour ajuster l’objectif plutôt que de choisir une valeur fixe élevée.