أطلقت 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 لكل صورة سحابية، بما في ذلك مؤشرات الاستخدام والتشبع، لمساعدة الفرق على معرفة فترات ذروة الطلب وما إذا كان عدد الوكلاء الجاهزين يواكب قائمة الانتظار. في البيئات متعددة العقد، يجب توجيه طلب المقاييس إلى العقدة الرئيسية عبر ملف تعريف الارتباط المخصص لذلك.
لماذا يهم هذا الخبر؟
تقدم الإضافة آلية مباشرة لتحويل زمن تجهيز الوكلاء من تأخير غير متوقع إلى مورد يمكن ضبطه ومراقبته. قيمتها العملية ستكون أكبر لدى الفرق التي لديها مهام قصيرة ومتكررة أو ذروة طلب يمكن التنبؤ بها، بينما قد لا تبرر التكلفة إبقاء وكلاء دافئين في مشاريع ذات تشغيل متقطع. لذلك يحتاج اعتمادها إلى مقارنة تكلفة الخمول بزمن الانتظار الفعلي، واستخدام المقاييس لتعديل الهدف بدلاً من اختيار رقم ثابت مرتفع.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.