GitHub Actions או GitLab CI: דקת build אינה אותה יחידת חיוב

בחירה בין GitHub Actions ל־GitLab CI מתחילה בחישוב של אותו עומס עבודה בשתי שיטות חיוב. לפי מחירון ה־runners של GitHub, כל job מעוגל כלפי מעלה לדקה שלמה, והתעריף תלוי במערכת ההפעלה ובסוג ה־runner. לכן שני pipelines שמסתיימים באותו זמן יכולים לצבור מספר שונה של דקות מחויבות אם אחד מהם מחולק ליותר jobs.

ב־GitLab.com החישוב פועל אחרת: נוסחת דקות ה־compute של GitLab מכפילה את משך הריצה של כל job, בשניות חלקי 60, במקדם העלות של ה־runner. מקדם של Linux small הוא 1 ושל Linux medium הוא 2. כדי לחזות את החשבון צריך להפריד בין צריכת ה־compute, המכסה שכל תוכנית כוללת ומחיר המושבים; כדי להשוות ביצועים צריך למדוד גם את הזמן עד לתוצאה, שאינו זהה לסכום זמני הריצה.

פיצול jobs משנה את החישוב

נניח לצורך המחשה ש־pipeline מפעיל שלושה jobs, וכל אחד מהם רץ 20 שניות. ב־GitHub Actions הם צורכים יחד שלוש דקות לאחר עיגול נפרד של כל job, אף שסכום הריצה בפועל הוא דקה אחת. על Linux small של GitLab.com, ובהנחה שאותן 20 שניות נמדדות לכל job גם שם, הסכום הוא דקת compute אחת. אם מעבירים את שלושתם ל־Linux medium בלי לשנות את משכם, המכפלה במקדם מעלה את הצריכה לשתי דקות compute.

הדוגמה מבודדת את שיטת המדידה, אך מבנה ה־pipeline משפיע גם על משך העבודה עצמו. כל job נוסף עשוי להוריד מחדש תלויות, להכין סביבת ריצה או לחזור על שלב שכבר בוצע; זמן כזה מצטרף לצריכה בשתי המערכות. מצד שני, jobs עצמאיים יכולים לרוץ במקביל ולקצר את ההמתנה לתוצאה. פיצול כדאי כאשר קיצור ההמתנה או בידוד הכישלונות מצדיקים את דקות הריצה הנוספות, ולא מפני שמספר ה־jobs קטן או גדול בפני עצמו.

מקביליות ממחישה מדוע צריך שני מדדים נפרדים. אם שלוש בדיקות רצות בו־זמנית, משך ה־pipeline עשוי להתקרב למשך הבדיקה הארוכה ביותר, בעוד החיוב או ניצול המכסה עדיין סוכמים את הצריכה של כל job. גם ניסיון חוזר אחרי כישלון מוסיף הרצה לחשבון. גיליון שמכיל רק את הזמן שבין תחילת ה־pipeline לסופו יחמיץ את שני המקרים.

מכסה, runner ואירוח עצמי

במאגרים פרטיים, כללי החיוב של GitHub Actions מקצים לתוכנית Team מכסה חודשית של 3,000 דקות ל־runners סטנדרטיים; שימוש מעבר למכסה מחויב לבעל המאגר. שימוש ב־runner סטנדרטי במאגר ציבורי, וכן שימוש ב־runner באירוח עצמי, אינו מחויב בדקות Actions. לעומת זאת, runners גדולים מחויבים גם אם נותרה מכסה, והמכסה הכלולה אינה חלה עליהם.

המשמעות היא שאותה דקת ריצה על Linux סטנדרטי ועל runner גדול אינה נכנסת לאותה עמודת עלות. גם בין runners סטנדרטיים התעריף משתנה לפי מערכת ההפעלה, ולכן אומדן שמכפיל את כל הדקות במחיר Linux יחטיא jobs שרצים על Windows או macOS. אם הצוות מפעיל runner משלו, צריך לכלול בנפרד מכונה, קיבולת ותפעול; היעדר חיוב דקות מצד הפלטפורמה אינו מבטל את עלות התשתית.

ב־GitLab.com, שאלות החיוב של GitLab קובעות שתוספת של 1,000 דקות compute עולה 10 דולר, תקפה עד שנה ואינה מתחדשת אוטומטית. Jobs על runners שהלקוח מביא אינם נספרים במכסת ה־runners המשותפים. כאן חשוב להבחין בין מקדם הצריכה למחיר התוספת: מקדם גבוה מרוקן את המכסה מהר יותר, ואילו חבילת הדקות קובעת כמה משלמים כשצריך להגדיל אותה.

המכסה של GitLab.com נמדדת ברמת מרחב השמות העליון, כך שפרויקטים באותו מרחב חולקים אותה. גם מאגר ציבורי אינו פטור אוטומטית ממגבלת דקות ה־compute של GitLab.com. לכן תחזית לפרויקט יחיד צריכה להביא בחשבון צריכה של פרויקטים אחרים שחולקים איתו מכסה. בהשוואה ל־GitHub כדאי לתעד במפורש מי מחזיק במכסה, אילו jobs משתמשים ב־runner מתארח ואילו רצים על תשתית הצוות.

גיליון חישוב לאותו עומס עבודה

היחידה המתאימה לגיליון היא סוג job, ולא build ממוצע. לכל שורה רשמו כמה builds צפויים בחודש, כמה פעמים ה־job רץ בכל build, משך ריצה ממוצע בשניות, מערכת הפעלה וסוג runner בכל פלטפורמה. jobs שמופעלים רק בבקשות מיזוג, בהרצות מתוזמנות או בניסיונות חוזרים צריכים שורות משלהם, משום שהתדירות שלהם שונה. לצד הממוצע רצוי לשמור גם משך אופייני להרצות איטיות, כדי שהתחזית לא תסתיר חודשים שבהם בדיקות או התקנת תלויות מתארכות.

• GitHub Actions: עגלו כל הרצה של כל job לדקה שלמה, הכפילו במספר ההרצות וסכמו לפי סוג runner. הפרידו שימוש הזכאי למכסה משימוש ב־runners גדולים, ואז חשבו עלות חריגה לפי התעריף המתאים לכל סוג.
• GitLab CI: הכפילו לכל job את משך הריצה בשניות חלקי 60, במקדם ה־runner ובמספר ההרצות. סכמו את דקות ה־compute של ה־jobs המתארחים, השוו אותן למכסה הזמינה למרחב השמות והציגו בנפרד רכישת דקות נוספות.
• מושבים ותשתית: הכפילו את מספר המושבים במחיר התוכנית שנבחרה והציגו את הסכום ליד עלות ה־compute. אם משתמשים ב־runners באירוח עצמי, הוסיפו שורת תשתית נפרדת במקום לייחס להם מחיר אפס.

השוואה הוגנת שומרת גם על אותה הגדרת עומס. אם גרסת GitHub מריצה בדיקות בכל push וגרסת GitLab מריצה אותן רק בבקשות מיזוג, פער החשבון נובע גם ממספר ההרצות. באופן דומה, cache חם עשוי לקצר job בלי לשנות את שיטת החיוב. הגיליון צריך להציג את ההנחות האלה בגלוי: תדירות, מדיניות cache ומספר הניסיונות החוזרים משפיעים על התוצאה לא פחות מהמחיר לדקה.

מה מראה תרחיש עלות מפורסם

תרחיש החישוב של CostOps מניח 50 builds ביום, שמונה דקות לכל build, 22 ימי עבודה ו־job אחד על Linux לכל build: 8,800 דקות בחודש. לאחר מכסת 3,000 הדקות של GitHub Team נותרות 5,800 דקות חריגה; בתעריף של 0.006 דולר לדקת Linux דו־ליבתי התוספת היא 34.80 דולר. מכסת 10,000 הדקות של GitLab Premium מכילה את אותה צריכה על Linux small בלי רכישת דקות נוספות.

עלות ה־compute לבדה הופכת כאן את GitLab לזולה יותר, אך חשבון המושבים נותן תמונה אחרת. בתרחיש של עשרה משתמשים, מושבי GitHub Team עולים 40 דולר לחודש והחריגה מביאה את הסכום ל־74.80 דולר, בעוד מושבי GitLab Premium עולים 290 דולר לחודש ללא חריגת compute. זהו חישוב מותנה לפי מחירי התוכניות והיקף העבודה שבתרחיש, ולא מבחן מהירות או הצעת מחיר לצוות מסוים. תוכנית GitLab עשויה להצדיק את מחירה באמצעות צרכים נוספים של הצוות, אך אי אפשר להסיק זאת מדקות CI בלבד.

ביצועים מודדים על אותה עבודה

המחירון אינו קובע איזו מערכת תסיים את הבדיקות מהר יותר. לשם השוואת ביצועים יש להריץ אותו קוד ואותן בדיקות, עם אותה מדיניות cache, ולרשום לכל תצורה את זמן ההמתנה בתור, משך כל job והזמן עד לתוצאה הסופית. יש לציין את מערכת ההפעלה, משאבי ה־runner ורמת המקביליות, משום שמעבר למכונה חזקה יותר עשוי לקצר הרצה ובו בזמן לשנות את התעריף או את מקדם הצריכה.

גם תוצאת benchmark של build בודד מוגבלת אם העבודה היומיומית כוללת pipelines קצרים, בדיקות מקבילות והרצות חוזרות. ההשוואה השימושית לצוות היא זוג תוצאות עבור כל תצורה: כמה זמן ממתינים בדרך כלל למשוב, וכמה צפוי לעלות חודש בהיקף ההרצות שלו. כך אפשר לראות מתי פיצול jobs קונה זמן במחיר של דקות נוספות, ומתי runner חזק מקצר את ההמתנה בלי לחסוך כסף. ההחלטה נשענת על שני המדדים יחד, לצד עלות המושבים והתשתית שהצוות כבר מפעיל.

קראו גם:

• 2FA ב־GitHub עלול לנעול אתכם בחוץ: שמרו יותר מנתיב שחזור אחד
• Sentry או Datadog: אותה שגיאה יכולה לדרוש שני כלים, לא מנצח אחד
• Zapier או Make: פעולה אחת יכולה להפוך לכמה יחידות חיוב