חמש הטעויות הנפוצות בתהליכי CI

מאת: אייל דנון, מהנדס פתרונות ב-SkyWiz מקבוצת TeraSky, בעל הסמכת RHCA מטעם רד-האט

צוותי פיתוח בארגונים רבים מאמצים באחרונה את שיטת העבודה CI (ר"ת Continuous Integration) – החל מענקיות כמו גוגל, פייסבוק ואמזון, ועד סטארט-אפים מכל סוג או גודל. היתרונות הרבים של פיתוח תוכנה בשיטת CI לא נוגעים רק למפתחים, אלא גם ללקוחות הקצה ולהנהלות של הארגונים. פיתוח בשיטה זו תורם משמעותית לקיצור זמני ההגעה לשוק של מוצרים חדשים וגרסאות חדשות, ומאפשר לספק ללקוחות פונקציונליות עשירה יותר בזמנים קצרים ובאיכות גבוהה יותר.

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

טעות ראשונה – לא לשמור סיסמאות בתוך Version control. לא אחת נתקלנו במקרים שאנשים שמרו ב-GitHub סיסמאות לאפליקציות פנימיות, שזה בערך כמו לכתוב רשימת סיסמאות על פתק ולהשאיר אותו מונח על השולחן במשרד (או בפארק…). במקרים כאלה הארגון נחשף במקרה הטוב לפגיעה במוניטין ובמקרה הרע – לפריצה, ואז הפגיעה במוניטין תהיה רק חלק קטן מהנזק. רד-האט מציעה פתרון דוגמת RedHat Vault, שמיועד בדיוק לכך.

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

טעות שלישית – הסתפקות בתהליכי ניטור סטנדרטיים לסביבות CI. כשעובדים בשיטת CI, חשוב מאוד לנטר גם בצורה אפליקטיבית: להבין באילו מקרים תהליך הבנייה נכשל, להבין מדוע הוא נכשל ולזהות אם יש עקביות או חוקיות כלשהי שניתן לטפל בה (למשל, אם פרויקט נכשל רק בסופי שבוע). לא מספיק לעשות ניטור סטנדרטי של משאבי המערכת כגון דיסקים, זיכרון ועומס.

ניטור אפליקטיבי בהחלט יכול למנוע הרבה הפתעות לא רצויות בתהליכי ה-CI, הן בשלבי ההעלאה ל-Production והן בתהליך הפיתוח. הפתעות אלה יכולות להתבטא בבזבוז רב של משאבים ו-Troubleshooting ארוך ומייגע.

טעות רביעית – "תהליך CI שייך לצוות אחד". ארגונים רבים משייכים את תהליך ה-CI לצוות ה-DevOps, אלא שבפועל, ה-DevOps לא "חי" את הבעיות האלה באמת. לכן, צריכים להיות שותפים לתהליך ה-CI המפתחים, אנשי ה-QA וכמובן שאנשי ה-DevOps, שאמורים "לעטוף" את הכל בתשתית גנרית אחת. צריך להבין ש-DevOps זה לא תפקיד, אלא דפוס התנהלות של ארגון הפיתוח כולו. רק ברגע שמבינים ומפנימים את זה, הדרך נסללת לאימוץ נכון ומועיל באמת של שיטת ה-CI.

טעות חמישית – הטיות נפוצות בבחירת סביבת ה-CI. ברוב המקרים, אנשי ה-DevOps בוחרים סביבה זו אוטומטית לפי ההייפ או לפי מה שהם רגילים לעבוד אתו. זה בעייתי מאוד, מפני שהם לא בוחנים את הצרכים הספציפיים של החברה ושל המוצר שבפיתוח. לא תמיד מה שהתרגלתם אליו או מה שיש עליו הייפ הוא המתאים ביותר לפרויקט הבא של ארגונכם. מומלץ להניח בצד את ההרגלים הישנים ולבחון היטב כמה משתנים עיקריים, כמו: באיזה אקו-סיסטם מתנהלת סביבת הפיתוח של החברה; מהו סוג המוצר – האם כדאי לעבוד עם מיקרו-שירותים או לא? באיזו סביבה לעבוד – Windows או לינוקס? ניתן להיעזר גם בעצת מומחים, להתאמה מיטבית של סביבת ה-CI למאפייני הארגון והפרויקט. זכרו שבחירה בסביבה המתאימה ותכנון מקדים נכון ימנעו עבודה כפולה בהמשך.

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

אייל דנון וצוות המומחים של SkyWiz מקבוצת TeraSky ישתתפו ויציגו בפורום השנתי של רד-האט, שייערך ב-12 בנובמבר במרכז הכנסים אווניו שבקריית שדה התעופה. אתם מוזמנים לשוחח איתם וללמוד עוד על תהליכי CI ,CD ,DevOps ומה שביניהם.