JetBrains, sürekli entegrasyon ve teslim ortamlarındaki en yaygın gecikme noktalarından birini ele almak için TeamCity platformuna Warm Agents eklentisini sundu: testler veya derleme işlemi başlamadan önce bir bulut derleme aracısının başlatılmasını beklemek. Eklenti, her bulut imajı için hedeflenen sayıda boşta ve önceden çalıştırılmış aracının korunmasını sağlıyor. Böylece sayı belirlenen seviyenin altına düştüğünde TeamCity yeni bir aracı sağlamaya başlıyor.
Eklenti, TeamCity'nin desteklediği tüm bulut sağlayıcılarıyla çalışıyor. Bu da onu, eksiksiz bir derleme altyapısını çalışır durumda tutmak yerine geçici aracılar kullanan ekipler için uygun hale getiriyor. Fikir özellikle, ortam hazırlama süresinin çalıştırma süresinden daha uzun olabildiği kısa görevleri hedefliyor. Zira yavaş başlatılan bir Windows bulut aracısı, bir dakika süren bir testi birkaç dakika daha kuyrukta tutabilir.
Pratikte ne değişiyor?
TeamCity, görev geldiğinde yalnızca aracı oluşturmak yerine her bulut imajı için boşta olan aracıların sayısını izliyor ve sayı hedefin altına düştüğünde yeni örnekler başlatıyor. Sayı REST API üzerinden veya Project Settings | Integrations | Warm Agents yolundaki proje ayarları aracılığıyla yapılandırılabiliyor. Belirli bir imaj için hazır aracı bulundurmayı durdurmak amacıyla sıfır hedefi kullanılabiliyor.
Eklenti TeamCity 2024.12.3 veya daha yeni bir sürümün yanı sıra, proje içinde yapılandırılmış bir bulut profili ve bulut imajı ile Manage project’s agent cloud profiles iznini gerektiriyor. Eklenti yüklenip JetBrains Marketplace'ten etkinleştirildikten sonra REST API veya teamcity-cli aracı üzerinden yönetilebiliyor.
Hızın maliyeti ve ölçeklendirme sınırları
Warm Agents ücretsiz bir hızlandırma sunmuyor. Çalışır durumdaki her hazır aracı bir build agent lisansı tüketiyor; ayrıca boşta kalan bulut örnekleri bulut sağlayıcısında maliyet oluşturmaya devam ediyor. Bu nedenle eklenti, bekleme süresi ile işletim harcamaları arasında açık bir denge kuruyor. Gerçek talep düşükse hedefi artırmak her zaman pratik bir iyileşme anlamına gelmiyor.
TeamCity, aracı hedefi daha yüksek bir değere ayarlanmış olsa bile bulut imajı tarafından belirlenen çalışan örnekler üst sınırına uyuyor. Ayrıca örnekleri kısa aralıklarla gruplar halinde başlatıyor; bu nedenle yüksek bir hedefe ulaşmak biraz zaman alabiliyor. Hedef düşürüldüğünde TeamCity çalışan araçları zorla durdurmuyor. Bulut imajı için tanımlanan boşta kalma zaman aşımı geçerliliğini koruyor ve hedeflenen sayıyı korumak amacıyla durdurulan bazı örnekler yeniden başlatılabiliyor.
Zamanlama ve ölçüm
JetBrains, talep düzenine göre hedefi değiştirmek için zamanlanmış görevlerin kullanılmasını öneriyor; örneğin hedefin sabah yükseltilmesi ve akşam sıfıra indirilmesi. Bu işlem Kotlin DSL ve REST API çağrılarıyla gerçekleştirilebiliyor. OAuth belirtecinin derleme günlüklerinde görünmemesi için parola türünde bir parametre olarak saklanması gerekiyor.
Eklenti ayrıca her bulut imajı için kullanım ve doygunluk göstergeleri de dahil olmak üzere Prometheus biçiminde ölçümler sunuyor. Bu ölçümler, ekiplerin talebin en yoğun olduğu dönemleri ve hazır aracı sayısının kuyruğa ayak uydurup uydurmadığını anlamasına yardımcı oluyor. Birden çok düğüm bulunan ortamlarda ölçüm isteğinin ilgili özel çerez profili aracılığıyla ana düğüme yönlendirilmesi gerekiyor.
Bu haber neden önemli?
Eklenti, aracı hazırlama süresini öngörülemeyen bir gecikmeden ayarlanabilir ve izlenebilir bir kaynağa dönüştürmek için doğrudan bir mekanizma sunuyor. Pratik değeri, kısa ve tekrarlanan görevleri veya öngörülebilir talep yoğunlukları bulunan ekiplerde daha yüksek olacak. Buna karşılık, aralıklı çalışan projelerde sıcak aracıları hazır tutmanın maliyeti karşılığını vermeyebilir. Bu nedenle eklentinin kullanıma alınması, boşta kalma maliyetinin gerçek bekleme süresiyle karşılaştırılmasını ve yüksek sabit bir sayı seçmek yerine hedefin ölçümler kullanılarak ayarlanmasını gerektiriyor.