המדריך המלא ל-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 בונה את האתר הזה (Next.js) בכל push ל-main, פורס אותו אוטומטית ל-Vercel, מריץ TypeScript checks, ובודק שאין secrets שיצאו בטעות לקוד. בנוסף, יש לי actions שמתזמנים מטלות יומיות (cron triggers), פותחים PRs אוטומטית כשתלות מתעדכנת (Dependabot) — וכל זה בלי שרת אחד שלי. זה הכלי שעושה את ההבדל בין 'אני מפתח לבד' לבין 'יש לי תהליך מקצועי'.
מה המדריך מכסה
מה זה 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, אלה הדברים שאני הייתי רוצה לדעת בהתחלה.
