מה זה GitHub Actions

אם יש לכם פרויקט על GitHub, כנראה שכבר ראיתם את זה: התג הירוק הקטן ליד ה-commit שאומר "כל הבדיקות עברו", או אדום שאומר שמשהו נשבר. מאחורי התג הזה עומד GitHub Actions, מערכת ה-CI/CD המובנית של GitHub, שהפכה בשנים האחרונות לאחד הכלים הכי נפוצים לאוטומציה של תהליכי פיתוח.

מה זה workflow ואיך הוא מופעל

הרעיון הבסיסי הוא פשוט: אתם כותבים קובץ YAML שיושב בתיקייה .github/workflows בתוך הריפוזיטורי, ומתאר workflow - תהליך שמתבצע אוטומטית כשקורה אירוע מסוים. האירוע יכול להיות דחיפת קוד, פתיחת pull request, יצירת release, או אפילו לוח זמנים קבוע כמו "כל לילה בחצות".

כשהאירוע קורה, GitHub מריץ את ה-workflow על מכונה זמנית שנקראת runner. אפשר להשתמש ב-runners המנוהלים של GitHub עצמו, שמתאפסים אחרי כל ריצה, או להריץ runners משלכם אם צריך חומרה או תלויות ספציפיות.

jobs, steps וה-marketplace

כל workflow מורכב מ-jobs, וכל job מורכב מרשימת steps שרצים בזה אחר זה - להתקין תלויות, להריץ טסטים, לבנות דוקר אימג', לפרוס לענן. כל צעד כזה יכול להיות פקודת shell פשוטה, או שימוש ב-action - חבילה מוכנה שמישהו אחר כבר כתב ופרסם.

זה בדיוק מה שהופך את GitHub Actions לכל כך נוח: יש marketplace ענק של actions מוכנים לכל דבר שאפשר לחשוב עליו - התקנת Node.js בגרסה מסוימת, פרסום חבילה ל-npm, שליחת התראה לסלאק, פריסה ל-AWS. במקום לכתוב סקריפט מאפס, לרוב אפשר למצוא action קיים ופשוט להוסיף אותו לתהליך.

למה זה הפך לכל כך פופולרי

היתרון הכי גדול של GitHub Actions הוא שאין שום תשתית נוספת להקים. אם הקוד שלכם כבר יושב ב-GitHub, ה-CI/CD כבר שם, מחכה שתפעילו אותו. אין שרת נפרד להתקין ולתחזק, אין הרשאות נוספות לנהל, הכל חי באותו מקום שבו הקוד כבר נמצא.

מעבר לזה, יש אינטגרציה הדוקה עם שאר הפלטפורמה - workflows יכולים להגיב ישירות לתגובות בפול ריקווסט, לתייג אנשים, לחסום מיזוג אם בדיקה נכשלה, הכל בלי לצאת מהממשק שהצוות כבר משתמש בו כל יום. זו הסיבה שהוא כל כך נפוץ בפרויקטי קוד פתוח - כל תורם, גם מבחוץ, מקבל את אותו תהליך בדיקות אוטומטי בלי שום הגדרה נוספת.

שימושים נפוצים בפועל

השימוש הכי בסיסי הוא הרצת טסטים אוטומטית על כל pull request, כדי לתפוס שגיאות לפני שהן נכנסות לענף הראשי. מעבר לזה, הרבה צוותים משתמשים ב-GitHub Actions כדי לבנות ולפרסם חבילות - נניח, לבנות דוקר אימג' ולדחוף אותו ל-registry בכל פעם שיש release חדש.

שימוש נוסף ונפוץ מאוד הוא פריסה אוטומטית - deployment - כשקוד נכנס לענף הראשי, ה-workflow יכול לבנות את הפרויקט ולפרוס אותו ישירות לסביבת הייצור, בלי שאף אחד יצטרך להריץ פקודות ידנית.

GitHub Actions מול Jenkins

מי שמכיר את Jenkins בטח שם לב לדמיון הרעיוני, ובאמת שני הכלים פותרים אותה בעיה בגישות שונות. Jenkins הוא שרת שאתם מתקינים ומתחזקים בעצמכם, עם שליטה וגמישות מלאות אבל גם עלות תחזוקה. GitHub Actions הוא שירות מנוהל, קל להתחיל איתו, ומשתלב ישירות בתוך GitHub, אבל פחות גמיש כשצריך תהליכים מאוד מותאמים אישית או תשתית עצמאית. לפרויקטים חדשים שכבר חיים ב-GitHub, זו לרוב הבחירה הפשוטה יותר.

מלכודת נפוצה

טעות שכיחה היא לשכוח שכל דקת ריצה על runners המנוהלים של GitHub נספרת, ובפרויקטים פרטיים יש מכסה מוגבלת. workflow לא יעיל שמתקין תלויות מאפס בכל ריצה, במקום להשתמש ב-caching מובנה, יכול לגרום לבדיקות פשוטות לקחת דקות ארוכות במקום שניות. שווה מהתחלה להרגיל את עצמכם להשתמש ב-actions לניהול caching של תלויות.

מי שרוצה להבין את כל התמונה - איך תהליכי בנייה, בדיקה ופריסה מתחברים לשאר תשתית צד השרת - מוזמן להסתכל על קורס צד שרת.

GitHub Actions הפך תוך כמה שנים לאחד הכלים הכי נפוצים בעולם הפיתוח, ופשוט כי הוא מוריד את החיכוך כמעט לגמרי. אם עוד לא הגדרתם workflow בפרויקט שלכם, זה שווה חצי שעה מהזמן שלכם.

הצטרפו לקהילה בדיסקורד