המדריך המלא ל-GitHub Actions — CI/CD מובנה לתוך הריפו
כל push מריץ tests, builds ו-deploys — בלי שרת CI נפרד, בחינם לפרויקטים פתוחים
GitHub Actions היא מערכת CI/CD (continuous integration / continuous deployment) המובנית ישירות בתוך GitHub. CI/CD הוא השם של אוטומציה: כל פעם שאתם דוחפים קוד, המערכת מריצה בדיקות (tests), בונה את האפליקציה (build), ואם הכול תקין — פורסת אותה לייצור (deploy). בעבר, להקים pipeline כזה דרש שרת CI נפרד (Jenkins, TeamCity), שעות הגדרה ותחזוקה מתמשכת. עם GitHub Actions, זה קובץ YAML אחד בתוך הריפו (`.github/workflows/`), ו-GitHub עצמם מריצים את כל הפעולות על שרתים שלהם — בחינם לפרויקטים פתוחים, ועם 2,000 דקות חינמיות בחודש לפרויקטים פרטיים. אצלי (אלעד) GitHub Actions משמש כשומר-הסף של האתר הזה: בכל push הוא מריץ CI — בדיקות TypeScript ו-build מלא — ורק קוד שעובר אותן ראוי להתמזג. את הפריסה עצמה עושה דווקא Vercel, דרך ה-Git integration שלו (חיבור ישיר לריפו שפורס אוטומטית כל שינוי) — חלוקת עבודה נקייה: Actions בודק, Vercel פורס. וכל זה בלי שרת אחד שלי. זה הכלי שעושה את ההבדל בין 'אני מפתח לבד' לבין 'יש לי תהליך מקצועי'.
מה המדריך מכסה
מה זה GitHub Actions: workflow, jobs, steps
המבנה ההיררכי שכל קובץ YAML מתאר
GitHub Actions בנוי משלוש רמות. Workflow = קובץ YAML אחד שמופעל על אירוע (push, PR, schedule, manual). Jobs = יחידות עבודה בתוך workflow שיכולות לרוץ במקביל או ברצף. Steps = פקודות בתוך job. כל job רץ על runner — מכונה וירטואלית חדשה לחלוטין ש-GitHub מספקים, עם Linux/Windows/macOS לבחירה. אחרי שה-workflow מסתיים, ה-runner נמחק — clean slate בכל ריצה.
workflow ראשון: TypeScript check על כל PR
5 דקות מאפס ל-CI אמיתי
הדרך הטובה ביותר ללמוד היא לראות workflow פשוט שעושה משהו אמיתי. הדוגמה הזו מריצה `tsc --noEmit` ו-`eslint` על כל push ועל כל PR — כך שאף פעם לא ימזגו ref שלא עובר type-check.
Deploy אוטומטי של Next.js ל-Vercel
דחיפה ל-main = פריסה לייצור בתוך דקה וחצי
אחרי ש-CI עובד, השלב הבא הוא deploy אוטומטי. Vercel תומכים ב-GitHub integration שעושה deploy על כל push בלי workflow מיוחד — אבל אם אתם רוצים שליטה מלאה (deploy רק אחרי שה-tests עוברים, ל-environment ספציפי, עם build args מותאמים), workflow YAML נותן את זה.
סודות ו-OIDC: לא לשים API keys בקוד
איך לתת ל-CI גישה ל-cloud בלי לשים שם credentials סטטיים
כל workflow שעושה deploy צריך גישה ל-cloud כלשהו (Vercel, AWS, Cloudflare). הדרך הישנה היא טוקנים סטטיים שנשמרים ב-GitHub Secrets — זה עובד אבל לא אופטימלי (טוקן שדלף = גישה לחשבון). הדרך המודרנית היא OIDC (OpenID Connect): GitHub מנפיקים JWT ייחודי לכל workflow, ואתם מגדירים ב-cloud trust ש'אם ה-JWT הזה הגיע מ-repo X, branch Y, אתה יכול להניח שזה אני'.
מתקדם: matrix, reusable, self-hosted
הפיצ'רים שעושים את ההבדל
אחרי שיש workflow בסיסי שעובד, הנה הפיצ'רים שיעלו אתכם רמה.
טיפים מהשטח
מה למדתי בשלוש שנים של GitHub Actions
אחרי שלוש שנים של שימוש ב-GitHub Actions, אלה הדברים שאני הייתי רוצה לדעת בהתחלה.
