מה זה CI/CD ולמה כל מפתח backend חייב להבין את זה¶
בכל מודעת דרושים למפתח backend, בטוח נתקלתם בדרישה "ניסיון עם CI/CD". זה נשמע כמו עוד ראשי תיבות טכניים שצריך לשנן בשביל הראיון, אבל האמת היא שהרעיון שמאחורי CI/CD הוא אחד הדברים הכי פרקטיים שתלמדו כמפתחים, וברגע שתעבדו איתו פעם אחת, לא תרצו לחזור אחורה.
נתחיל מהפירוק - CI ו-CD הם שני דברים שונים¶
CI, ראשי תיבות של Continuous Integration (אינטגרציה מתמשכת), אומר שכל פעם שמישהו בצוות דוחף שינוי קוד, המערכת רצה אוטומטית בדיקות על הקוד הזה - לוודא שהוא לא שובר כלום, שהוא עומד בכללי כתיבה מוסכמים, ושהוא באמת עושה מה שהוא אמור לעשות.
CD יכול להיות Continuous Delivery (הפצה מתמשכת) או Continuous Deployment (פריסה מתמשכת), ואומר שאחרי שהקוד עבר את כל הבדיקות, הוא מגיע אוטומטית (או בלחיצת כפתור אחת) לסביבת הבדיקה או אפילו ישירות לייצור, בלי שמישהו צריך להעלות קבצים ידנית לשרת.
ביחד, CI/CD הוא בעצם קו ייצור אוטומטי לקוד שלכם - מהרגע שכתבתם שורת קוד ועד שהיא רצה בפועל אצל המשתמשים, בלי שלב ידני אחד שאפשר לפספס בו משהו.
למה זה כל כך חשוב - הבעיה שזה פותר¶
תחשבו על העולם בלי CI/CD. מפתח כותב פיצ'ר, בודק אותו ידנית על המחשב שלו (אולי), ומעלה אותו ידנית לשרת. אם הוא שוכח בדיקה חשובה, או שהקוד עובד אצלו במחשב אבל לא בסביבת הייצור, המשתמשים שלכם הם אלה שיגלו את הבאג.
עם CI/CD, כל שינוי קוד עובר את אותה סדרת בדיקות אוטומטית, בלי תלות בזיכרון או בריכוז של מישהו. זה לא מבטל באגים לגמרי, אבל זה תופס נתח עצום מהם הרבה לפני שהם מגיעים למשתמשים אמיתיים. זו רשת ביטחון שרצה אוטומטית, כל פעם, בלי יוצא מן הכלל.
מה בפועל קורה בתוך pipeline¶
pipeline של CI/CD בנוי בדרך כלל משלבים, שרצים אחד אחרי השני:
- Lint - בדיקה שהקוד כתוב בסגנון עקבי ולא מכיל טעויות בסיסיות
- Tests - הרצת בדיקות אוטומטיות שבודקות שהקוד עושה מה שהוא אמור
- Build - הרכבת הפרויקט לצורה שאפשר להריץ אותה בייצור
- Deploy - העלאת הגרסה החדשה לשרת, לרוב עם אפשרות לחזור אחורה אם משהו משתבש
אם שלב אחד נכשל, ה-pipeline עוצר שם ולא ממשיך הלאה, כדי שקוד שבור לא יגיע למשתמשים.
אילו כלים משתמשים בפועל¶
הכלים הכי נפוצים היום הם GitHub Actions (שילוב טבעי אם הקוד שלכם כבר ב-GitHub), GitLab CI, ו-Jenkins שהוא ותיק יותר אבל עדיין נפוץ בהרבה חברות. כולם בעצם עושים את אותו דבר - מריצים סקריפט אוטומטי כשמשהו קורה ברפוזיטורי הקוד שלכם, בדרך כלל push או pull request.
הטעות הנפוצה - "זה רק לחברות גדולות"¶
הרבה מתחילים חושבים ש-CI/CD רלוונטי רק לצוותים גדולים עם עשרות מפתחים. זו טעות. גם בפרויקט אישי קטן, להגדיר pipeline בסיסי שרץ בדיקות אוטומטיות בכל push חוסך לכם המון כאב ראש, ומרגיל אתכם לעבוד בצורה שהעולם המקצועי מצפה ממנה. וזה בדיוק סוג הניסיון שמעסיקים מחפשים - לא רק שידעתם לכתוב קוד, אלא שידעתם לבנות תהליך עבודה מסודר סביבו.
איך לומדים לבנות pipeline בעצמכם¶
התיאוריה של CI/CD קלה, אבל ההבנה האמיתית מגיעה כשמגדירים pipeline בעצמכם ורואים אותו נכשל, ואז מתקנים עד שהוא עובד. בקורס צד שרת אנחנו עוברים גם על DevOps ו-CI/CD כחלק אינטגרלי מהמסלול, כדי שתגיעו לעולם העבודה כשאתם כבר יודעים איך לבנות תהליך פריסה נכון, לא רק לכתוב קוד.
ואם אתם נתקעים בהגדרת pipeline ראשון וה-GitHub Actions שלכם נכשל בלי סיבה ברורה, זה בדיוק הזמן לשאול בדיסקורד.
לסיכום¶
CI/CD הוא לא קישוט טכני למפתחים מתקדמים, הוא תהליך עבודה בסיסי שכל מפתח backend צריך להכיר. הרעיון המרכזי פשוט - תנו למחשב לבדוק ולהפיץ את הקוד שלכם באופן אוטומטי ועקבי, ותפסיקו לסמוך על זיכרון אנושי בשביל דברים שאפשר לבצע בלחיצת כפתור.