افزایش بیش از ۳ برابری سرعت در گیت‌هاب اکشنز با رانرهای بلک‌اسمیت
بررسی بنچمارک و تست‌های مقایسه‌ای رانرهای بلک‌اسمیت و گیت‌هاب اکشنز؛ کاهش زمان اجرای CI/CD از ۴ دقیقه به ۱ دقیقه و بهبود پایداری فرآیند توسعه.
توسعه‌دهندگانی که از گیت‌هاب اکشنز (GitHub Actions) برای فرآیندهای استقرار و تست استفاده می‌کنند، همواره با چالش زمان انتظار و سرعت اجرای مراحل روبه‌رو هستند. به تازگی آزمایش‌های دقیقی روی رانرهای شرکت بلک‌اسمیت (Blacksmith) انجام شده است تا مشخص شود ادعای آن‌ها مبنی بر سرعت بالاتر نسبت به رانرهای پیش‌فرض گیت‌هاب چقدر واقعیت دارد. نتایج این بنچمارک‌ها نشان‌دهنده تفاوت معناداری در بازدهی است.
جزئیات آزمایش مقایسه‌ای و اعداد واقعی
برای دستیابی به یک نتیجه قابل استناد، ۱۰ مرحله آزمایش مجزا روی یک جاب (Job) کاملاً یکسان در گیت‌هاب اکشنز اجرا شد. در یک سو، رانر استاندارد گیت‌هاب با سیستم‌عامل اوبونتو (ubuntu-latest) قرار داشت و در سوی دیگر، رانرهای بلک‌اسمیت استفاده شدند.
اعداد به دست آمده نشان می‌دهند که رانرهای بلک‌اسمیت بین ۳.۱۷ تا ۳.۷۷ برابر سریع‌تر از رانرهای میزبان گیت‌هاب عمل کرده‌اند. این یعنی کاری که در حالت عادی حدود ۴ دقیقه زمان می‌برد، با این جایگزین در حدود ۱ دقیقه به پایان می‌رسد. نکته مهم‌تر از سرعت، پایداری یا همان واریانس زمانی است؛ رانرهای بلک‌اسمیت در هر ۱۰ بار تکرار، نتایج بسیار نزدیکی به هم ثبت کردند، در حالی که رانرهای گیت‌هاب نوسان بیشتری در زمان اجرا نشان دادند.
چرا سرعت رانر برای تیم‌های فنی حیاتی است؟
در پروژه‌های بزرگ، هر بار که کدی تغییر می‌کند، ده‌ها تست و بررسی امنیتی به صورت خودکار اجرا می‌شود. فرض کنید یک تیم برنامه‌نویسی روزانه ۵۰ بار فرآیند CI/CD را اجرا کند. اگر هر اجرا به جای ۱۰ دقیقه، تنها ۳ دقیقه زمان ببرد، در پایان روز صدها دقیقه در وقت ارزشمند تیم فنی صرفه‌جویی شده است. این سرعت بالا نه تنها خستگی ناشی از انتظار را کاهش می‌دهد، بلکه باعث می‌شود تداخل‌های کد (Merge Conflicts) سریع‌تر شناسایی و رفع شوند.
مثال کاربردی در محیط‌های توسعه
یک سناریوی رایج در شرکت‌های نرم‌افزاری، اجرای تست‌های واحد (Unit Tests) سنگین است. در حالی که سرورهای استاندارد ممکن است در پردازش‌های موازی دچار گلوگاه شوند، زیرساخت‌های بهینه‌سازی شده با بهره‌گیری از سخت‌افزارهای مدرن‌تر، داده‌ها را با نرخ بالاتری پردازش می‌کنند. این موضوع دقیقاً مشابه تفاوت اجرای یک نرم‌افزار سنگین روی یک لپ‌تاپ معمولی در مقایسه با یک ایستگاه کاری (Workstation) قدرتمند است.
محدودیت‌ها و پیش‌نیازهای فنی
با وجود نتایج درخشان در بخش سرعت، استفاده از این ابزار با محدودیت‌هایی همراه است که باید پیش از مهاجرت به آن در نظر گرفت. در طول آزمایش مشخص شد که رانرهای بلک‌اسمیت در مخازن شخصی (Personal Repositories) به درستی وارد صف اجرا نمی‌شوند.
راهکار عبور از محدودیت صف انتظار
برای حل این مشکل، مخزن پروژه حتماً باید تحت یک سازمان (Organization) در گیت‌هاب تعریف شده باشد. اگر به عنوان یک توسعه‌دهنده مستقل قصد استفاده از این سرعت را دارید، پیشنهاد می‌شود یک سازمان رایگان در گیت‌هاب بسازید و مخزن خود را به آن منتقل کنید. بدون این تغییر ساختاری، رانرها علی‌رغم تنظیمات صحیح، دستورات را دریافت نمی‌کنند و در وضعیت انتظار باقی می‌مانند.
پایداری در عملکرد؛ فراتر از سرعت خام
یکی از یافته‌های کلیدی این بنچمارک، رفتار یکنواخت پردازنده‌ها در طول بارگذاری سنگین بود. رانرهای میزبان گیت‌هاب گاهی به دلیل اشتراک منابع با سایر کاربران، دچار افت لحظه‌ای توان می‌شوند. در مقابل، رانرهای بهینه شده توانستند در تمام ۱۰ مرحله آزمایش، سطح عملکرد خود را حفظ کنند. این موضوع برای مدیران فنی که نیاز به تخمین دقیق زمان استقرار دارند، اهمیتی دوچندان دارد.
انتخاب بین ابزارهای استاندارد و جایگزین‌های تخصصی همیشه به بودجه و نیاز پروژه بستگی دارد، اما وقتی صحبت از کاهش زمان انتظار به یک‌سوم مطرح است، بررسی این گزینه‌ها اجتناب‌ناپذیر به نظر می‌رسد.
منبع: dev.to