JetBrains выпустила расширение Warm Agents для платформы TeamCity, чтобы устранить одну из наиболее распространённых задержек в средах непрерывной интеграции и доставки: ожидание запуска облачного агента сборки перед началом тестирования или процесса сборки. Расширение позволяет поддерживать заданное количество простаивающих и заранее запущенных агентов для каждого облачного образа, благодаря чему TeamCity начинает подготовку нового агента сразу после снижения количества ниже установленного уровня.
Расширение работает с любым облачным провайдером, поддерживаемым TeamCity, что делает его подходящим для команд, использующих временных агентов вместо постоянной работы полной инфраструктуры сборки. Идея особенно ориентирована на короткие задачи, для которых время подготовки среды может превышать время выполнения: медленно запускающийся облачный агент Windows способен удерживать тест продолжительностью в одну минуту в очереди ещё несколько минут.
Что меняется на практике?
Вместо создания агентов только после поступления задачи TeamCity отслеживает количество простаивающих агентов для каждого облачного образа и запускает новые экземпляры, когда их количество становится ниже целевого значения. Количество можно настроить через REST API или в настройках проекта по пути Project Settings | Integrations | Warm Agents. Значение цели, равное нулю, отключает сохранение готовых агентов для определённого образа.
Для расширения требуется TeamCity 2024.12.3 или более новая версия, а также облачный профиль и облачный образ, настроенные в проекте, и разрешение Manage project’s agent cloud profiles. После установки и включения из JetBrains Marketplace им можно управлять через REST API или инструмент teamcity-cli.
Цена скорости и ограничения масштабирования
Warm Agents не обеспечивает бесплатного ускорения. Каждый готовый работающий агент потребляет лицензию build agent, а простаивающие облачные экземпляры продолжают создавать расходы у облачного провайдера. Поэтому расширение предполагает явный компромисс между временем ожидания и эксплуатационными расходами, а увеличение целевого значения не всегда означает практическое улучшение, если фактический спрос невысок.
TeamCity соблюдает максимальное количество работающих экземпляров, заданное облачным образом, даже если целевое число агентов установлено выше. Кроме того, экземпляры запускаются пакетами с небольшими интервалами, поэтому достижение высокой цели может занять некоторое время. При снижении целевого значения TeamCity не останавливает принудительно работающих агентов; для облачного образа продолжает действовать заданный период простоя, при этом некоторые остановившиеся экземпляры могут быть перезапущены для поддержания целевого количества.
Планирование и измерение
JetBrains предлагает использовать запланированные задачи для изменения целевого значения в соответствии с моделью спроса — например, повышать его утром и снижать до нуля вечером. Это можно реализовать через Kotlin DSL и вызовы REST API, сохраняя токен OAuth в качестве параметра типа «пароль», чтобы он не отображался в журналах сборки.
Расширение также предоставляет метрики в формате Prometheus для каждого облачного образа, включая показатели использования и насыщения, помогая командам определить периоды пиковой нагрузки и понять, соответствует ли количество готовых агентов очереди. В многосоставных средах запрос метрик необходимо направлять на главный узел через предназначенный для этого профиль cookie.
Почему эта новость важна?
Расширение предлагает простой механизм для превращения времени подготовки агентов из непредсказуемой задержки в ресурс, которым можно управлять и который можно отслеживать. Практическая ценность будет выше для команд с короткими и повторяющимися задачами или предсказуемыми пиками нагрузки, тогда как в проектах с периодическими запусками расходы могут не оправдать поддержание тёплых агентов. Поэтому перед внедрением необходимо сравнить стоимость простоя с фактическим временем ожидания и использовать метрики для корректировки цели вместо выбора одного постоянно высокого значения.