GitHub یا GitLab؛ یک Build مشابه ۹:۴۴ در برابر ۱۱:۱۵ طول کشید

برای بار کاری آزموده‌شده، GitHub Actions زودتر نتیجه داد: در بنچمارک Semaphore، میانگین ده اجرای Job پروژهٔ Redmine در GitHub Actions برابر ۹ دقیقه و ۴۴ ثانیه و در GitLab CI/CD برابر ۱۱ دقیقه و ۱۵ ثانیه بود. اختلاف یک دقیقه و ۳۱ ثانیه‌ای برای همین پیکربندی ثبت شده است؛ انتخاب مناسب برای تیم به هزینهٔ اجرا و زمانی که واقعاً تا دریافت نتیجه منتظر می‌ماند نیز بستگی دارد.

از نظر سهمیه، GitHub برای مخزن عمومی روی runner استاندارد مزیت روشنی دارد. راهنمای صورت‌حساب GitHub Actions اجرای این runner را برای مخازن عمومی رایگان می‌داند، برای مخازن خصوصی در طرح Free ماهانه ۲٬۰۰۰ دقیقه در نظر می‌گیرد و نرخ پایهٔ runner لینوکسی دو هسته‌ای را پس از سهمیه ۰٫۰۰۶ دلار در دقیقه ثبت می‌کند. در مقابل، قیمت‌گذاری GitLab.com برای طرح Free ماهانه ۴۰۰ دقیقهٔ محاسباتی و سقف پنج کاربر در گروه اصلی را نشان می‌دهد. برای مخزن خصوصی کم‌مصرف، هر دو سهمیه ممکن است کافی باشند؛ در حجم بالا، تعداد اجرا و شیوهٔ خرید دقیقه اهمیت بیشتری پیدا می‌کند.

اختلاف زمان به چه بار کاری مربوط است؟

بار کاری Redmine شامل نصب وابستگی‌ها، آماده‌سازی پایگاه داده و اجرای مجموعهٔ آزمون‌ها بود. اجراها پس از گرم شدن کش اندازه‌گیری شدند و منطق خط لوله، نسخه‌های نرم‌افزاری و ردهٔ توان ماشین‌ها تا حد امکان همسان نگه داشته شد. هر مسیر فقط یک Job داشت و اجرای موازی در آزمون نبود. بنابراین عدد به‌دست‌آمده زمان اجرای همان ترکیب از مخزن، کش، وابستگی‌ها و runner میزبانی‌شده است، نه سرعت ثابت یکی از دو سرویس برای هر پروژه.

این مرز برای خط لوله‌های واقعی مهم است. اگر آزمون‌های یک تیم میان چند Job تقسیم شوند، زمان پایان خط لوله به وابستگی میان Jobها، تعداد runnerهای در دسترس و کارهای موازی بستگی پیدا می‌کند. در خط لوله‌ای که یک Job طولانی مسیر اصلی را می‌بندد، سرعت همان Job اهمیت بیشتری دارد. در هر دو حالت، جابه‌جایی نتیجهٔ Redmine به مخزنی با وابستگی‌ها یا سیاست کش متفاوت می‌تواند برآورد زمان انتظار را گمراه کند.

منتشرکنندهٔ آزمون خود عرضه‌کنندهٔ سرویس CI است. این موضوع نتیجهٔ ثبت‌شده برای GitHub و GitLab را تغییر نمی‌دهد، اما دامنهٔ استفاده از آن را روشن می‌کند: داده‌ها نمونه‌ای از اجرای کنترل‌شده‌اند. برای تصمیم زیرساختی، زمان همان آزمون‌های تیم روی runnerها و تنظیمات موردنظرش معیار نزدیک‌تری به تجربهٔ روزانه خواهد بود.

دقیقهٔ محاسباتی چه فرقی با زمان انتظار دارد؟

مبلغ اجرا از مجموع مصرف Jobها به دست می‌آید، در حالی که توسعه‌دهنده معمولاً فاصلهٔ آغاز خط لوله تا رسیدن نتیجه را حس می‌کند. طبق مستندات دقیقهٔ محاسباتی GitLab، مصرف هر Job برابر مدت اجرای آن ضرب‌در ضریب نوع runner و پروژه است؛ زمان حالت‌های ایجادشده و در انتظار اجرا در مدت Job حساب نمی‌شود و مصرف Jobهای موازی با هم جمع می‌شود. پس یک خط لولهٔ موازی می‌تواند دقیقهٔ بیشتری از زمان سپری‌شده روی ساعت مصرف کند، در حالی که انتظار در صف ممکن است زمان پاسخ به مهندس را افزایش دهد.

در مقایسهٔ قیمت، نرخ هر دقیقه را باید کنار مدت واقعی Job گذاشت. runner سریع‌تر ممکن است با وجود نرخ دقیقه‌ای بالاتر، هزینهٔ هر اجرا را کاهش دهد؛ runner کندتر نیز می‌تواند سهمیه را زودتر تمام کند. ضریب مصرف GitLab با نوع ماشین تغییر می‌کند، بنابراین مقایسهٔ صرفِ سهمیه‌های اسمی برای ماشین‌های متفاوت کافی نیست. هزینهٔ ذخیره‌سازی، اشتراک پولی و نگهداری runner شخصی نیز جدا از هزینهٔ دقیقهٔ میزبانی‌شده‌اند.

پرسش‌های متداول GitLab می‌گوید محدودیت دقیقه شامل پروژه‌های عمومی GitLab.com هم می‌شود، دقیقهٔ runner شخصی از این سهمیه کم نمی‌شود و دقیقهٔ اضافه در بسته‌های ۱٬۰۰۰ دقیقه‌ای با قیمت ۱۰ دلار فروخته می‌شود. دقیقه‌های خریداری‌شده تا یک سال اعتبار دارند. این بسته‌ای بودن مهم است: هزینهٔ پرداختیِ عبور اندک از سهمیه می‌تواند با هزینهٔ دقیقه‌های واقعاً مصرف‌شده در همان ماه فرق داشته باشد.

سه حجم اجرا، سه صورت‌حساب متفاوت

برای جدا کردن اثر سهمیه از اختلاف سرعت بنچمارک، فرض کنید در هر سرویس یک Job روی runner لینوکسی استاندارد دقیقاً ۱۰ دقیقه طول بکشد. اعداد زیر سناریوی فرضی هستند: مصرف دیگری در حساب یا گروه وجود ندارد، Job دیگری اجرا نمی‌شود و در صورت نیاز، پرداخت برای مصرف مازاد فعال است. این فرضِ زمان برابر، هزینهٔ سهمیه را نشان می‌دهد؛ زمان‌های اندازه‌گیری‌شدهٔ Redmine در آن وارد نشده‌اند.

• پروژهٔ عمومی: با ۱۰۰ اجرا در ماه، Jobها جمعاً ۱٬۰۰۰ دقیقه کار می‌کنند. در GitHub، runner استاندارد برای مخزن عمومی هزینهٔ دقیقه ندارد. در GitLab.com Free، پروژهٔ عمومی معمولی ۶۰۰ دقیقه از سهمیه فراتر می‌رود؛ ادامهٔ اجرا روی runner میزبانی‌شده به خرید یک بستهٔ ۱۰ دلاری نیاز دارد. پروژهٔ پذیرفته‌شده در برنامهٔ متن‌باز GitLab ضریب مصرف متفاوتی دارد و در این محاسبهٔ پروژهٔ معمولی نمی‌گنجد.
• مخزن خصوصی کم‌مصرف: با ۲۰ اجرا، مصرف ماهانه ۲۰۰ دقیقه است و در فرض نبود مصرف دیگر، هر دو طرح Free آن را پوشش می‌دهند. در GitHub ظرفیت بیشتری برای اجراهای بعدی باقی می‌ماند. در GitLab، سهمیه در سطح گروه اصلی یا فضای نام حساب می‌شود؛ مصرف مخازن دیگر همان گروه می‌تواند وضع این مخزن را عوض کند. برای چنین حجمی، تفاوت قبض دقیقه به‌تنهایی دلیل کافی برای انتقال مخزن نیست.
• تیم پرتراکنش: با ۱٬۰۰۰ اجرا، مصرف فرضی به ۱۰٬۰۰۰ دقیقه می‌رسد. در GitHub Free، ۸٬۰۰۰ دقیقه مازاد با نرخ پایهٔ فرض‌شده ۴۸ دلار هزینه دارد. در GitLab.com Free، ۹٬۶۰۰ دقیقه مازاد خرید ده بسته، یعنی پرداخت ۱۰۰ دلار، می‌خواهد و ۴۰۰ دقیقهٔ خریداری‌شده باقی می‌ماند. این سناریو فقط برای گروهی که در محدودیت کاربران طرح Free جا می‌گیرد معتبر است؛ هزینهٔ اشتراک طرح پولی در آن محاسبه نشده است.

این ارقام نشان می‌دهند قیمت هر اجرا و پرداخت ماهانه یک عدد واحد نیستند. برای GitLab، بستهٔ خریداری‌شده ممکن است در ماه بعد هم قابل استفاده باشد؛ برای GitHub، هزینهٔ مازاد در این مثال با دقیقه‌های مصرفی محاسبه شده است. اگر مدت Job در دو سرویس مانند آزمون Redmine تفاوت داشته باشد، هم مصرف ماهانه و هم نقطهٔ عبور از سهمیه تغییر می‌کند.

Runner شخصی کجا معادله را تغییر می‌دهد؟

با runner شخصی، هزینهٔ دقیقهٔ میزبانی‌شده از مقایسه کنار می‌رود: GitHub Actions برای اجرای self-hosted دقیقهٔ میزبانی‌شده دریافت نمی‌کند و اجرای runner شخصی GitLab نیز از سهمیهٔ محاسباتی آن کم نمی‌شود. در عوض، تیم هزینهٔ ماشین، ظرفیت هم‌زمان، به‌روزرسانی محیط اجرا و رسیدگی به خرابی را بر عهده می‌گیرد. حذف هزینهٔ دقیقه در قبض سرویس به معنی رایگان شدن اجرای آزمون‌ها نیست.

برای تیمی که از پیش سخت‌افزار و مسئول نگهداری دارد، runner شخصی می‌تواند محاسبهٔ حجم بالای اجرا را تغییر دهد. برای پروژهٔ کم‌مصرف، همین مسئولیت عملیاتی ممکن است از صرفه‌جویی دقیقه‌ای سنگین‌تر باشد. سرعت آن نیز باید جدا سنجیده شود: نتیجهٔ Redmine روی runnerهای میزبانی‌شده به ماشینی با پردازنده، دیسک، کش و بار هم‌زمان متفاوت منتقل نمی‌شود.

زمان مهندس در کدام بخش تصمیم اثر دارد؟

اختلاف مشاهده‌شده در یک Job، خودبه‌خود معادل زمان کاری بازیافته نیست. ممکن است اجراها هم‌زمان باشند، مهندسی منتظر پایان همهٔ آن‌ها نماند یا صف و بازبینی کد بیش از خود آزمون طول بکشد. ارزش سرعت برای تیمی بیشتر است که نتیجهٔ CI مانع ادغام یا ادامهٔ کارش می‌شود؛ برای تیمی که اجراها را در پس‌زمینه انجام می‌دهد، همان اختلاف می‌تواند اثر عملی کمتری داشته باشد.

برای انتخاب میان GitHub Actions و GitLab CI/CD، معیار نهایی باید زمان پایان خط لولهٔ همان مخزن، مجموع دقیقهٔ قابل‌صورتحساب و هزینهٔ ماهانه پس از سهمیه باشد. این سه معیار ممکن است به یک گزینه اشاره نکنند: مخزن عمومی از قاعدهٔ دقیقهٔ رایگان GitHub بهره می‌برد، مخزن خصوصی کم‌مصرف ممکن است در هر دو طرح بدون هزینهٔ دقیقه بماند و تیم پرتراکنش باید هزینهٔ runner یا بسته‌های اضافه را نیز وارد تصمیم کند.

بیشتر بخوانید:

• GitHub Copilot یا Cursor؛ نوع کار مهم‌تر از قیمت ماهانه است
• عامل OpenAI وارد سامانهٔ دولتی استرالیا شد؛ گزارش‌دهی سه ماه طول کشید
• مخزن GitHub را جابه‌جا کنید؛ GitHub Pages با Redirect نمی‌آید