JetBrains hat die Erweiterung Warm Agents für die TeamCity-Plattform veröffentlicht, um einen der häufigsten Verzögerungspunkte in Umgebungen für kontinuierliche Integration und kontinuierliche Bereitstellung zu beseitigen: das Warten auf den Start eines Cloud-Build-Agents, bevor Tests oder ein Build beginnen können. Die Erweiterung ermöglicht es, für jedes Cloud-Image eine festgelegte Anzahl inaktiver und bereits gestarteter Agents bereitzuhalten. Sobald die Anzahl unter den definierten Wert fällt, beginnt TeamCity mit der Bereitstellung eines neuen Agents.
Die Erweiterung funktioniert mit jedem von TeamCity unterstützten Cloud-Anbieter und eignet sich damit für Teams, die temporäre Agents verwenden, anstatt eine vollständige Build-Infrastruktur dauerhaft zu betreiben. Die Funktion richtet sich insbesondere an kurze Aufgaben, bei denen die Vorbereitungszeit der Umgebung länger dauern kann als ihre Ausführung. So kann ein langsam startender Cloud-Windows-Agent dazu führen, dass ein einminütiger Test mehrere zusätzliche Minuten in der Warteschlange bleibt.
Was ändert sich in der Praxis?
Statt Agents erst beim Eingang einer Aufgabe zu erstellen, überwacht TeamCity die Anzahl der inaktiven Agents für jedes Cloud-Image und startet neue Instanzen, wenn die Anzahl unter das Ziel fällt. Die Anzahl kann über die REST API oder in den Projekteinstellungen unter Project Settings | Integrations | Warm Agents festgelegt werden. Mit dem Zielwert null wird die Vorhaltung bereiter Agents für ein bestimmtes Image deaktiviert.
Die Erweiterung erfordert TeamCity 2024.12.3 oder eine neuere Version, ein Cloud-Profil und ein in einem Projekt eingerichtetes Cloud-Image sowie die Berechtigung Manage project’s agent cloud profiles. Nach der Installation und Aktivierung über den JetBrains Marketplace kann sie über die REST API oder das Tool teamcity-cli verwaltet werden.
Die Kosten der Geschwindigkeit und Grenzen der Skalierung
Warm Agents bietet keine kostenlose Beschleunigung. Jeder betriebsbereite Agent verbraucht eine Build-Agent-Lizenz, und inaktive Cloud-Instanzen verursachen beim Cloud-Anbieter weiterhin Kosten. Die Erweiterung schafft daher einen klaren Zielkonflikt zwischen Wartezeit und Betriebsausgaben. Eine Erhöhung des Zielwerts bedeutet nicht immer eine praktische Verbesserung, wenn die tatsächliche Nachfrage gering ist.
TeamCity beachtet die von einem Cloud-Image festgelegte maximale Anzahl laufender Instanzen, selbst wenn für die Agents ein höherer Zielwert eingestellt wurde. Außerdem werden Instanzen in Stapeln mit kurzen Abständen gestartet, weshalb das Erreichen eines hohen Zielwerts einige Zeit dauern kann. Wenn der Zielwert gesenkt wird, beendet TeamCity laufende Agents nicht zwangsweise. Die für das Cloud-Image definierte Leerlaufzeitüberschreitung bleibt aktiv, und einige beendete Instanzen können erneut gestartet werden, um die Zielanzahl aufrechtzuerhalten.
Planung und Messung
JetBrains empfiehlt, geplante Aufgaben zu verwenden, um den Zielwert an das Nachfragemuster anzupassen, beispielsweise ihn morgens zu erhöhen und abends auf null zu senken. Dies kann über Kotlin DSL und Aufrufe der REST API umgesetzt werden. Dabei sollte das OAuth-Token als Passwortparameter gespeichert werden, damit es nicht in den Build-Protokollen erscheint.
Die Erweiterung stellt außerdem Prometheus-Metriken für jedes Cloud-Image bereit, darunter Nutzungs- und Sättigungsindikatoren. Dadurch können Teams Spitzenzeiten der Nachfrage erkennen und feststellen, ob die Anzahl der bereiten Agents mit der Warteschlange Schritt hält. In Umgebungen mit mehreren Knoten muss die Metrikanfrage über das dafür vorgesehene Cookie-Profil an den Hauptknoten gerichtet werden.
Warum ist diese Nachricht wichtig?
Die Erweiterung bietet einen direkten Mechanismus, um die Vorbereitungszeit von Agents von einer unvorhersehbaren Verzögerung in eine steuerbare und überwachbare Ressource umzuwandeln. Ihr praktischer Nutzen ist bei Teams mit kurzen, wiederkehrenden Aufgaben oder vorhersehbaren Nachfragespitzen am größten. In Projekten mit sporadischem Betrieb rechtfertigen die Kosten dagegen möglicherweise nicht das Vorhalten warmer Agents. Daher sollte ihre Einführung einen Vergleich der Leerlaufkosten mit der tatsächlichen Wartezeit umfassen. Außerdem sollten die Metriken genutzt werden, um den Zielwert anzupassen, anstatt einen dauerhaft hohen festen Wert zu wählen.