CI/CD
בהנדסת תוכנה, CI/CD הוא מכלול שיטות העבודה, הכלים והאוטומציות המהווים את עמוד השדרה הטכני של פיתוח התוכנה הזריז. כלי CI/CD מאפשרים פיתוח תוכנה רציף, המצמצם ככל האפשר את הזמן העובר בין הוספת תכונה או יצירת שינוי בקוד התוכנה, לבין הגשת גרסה חדשה ויציבה של התוכנה ללקוח.[1][2][3]
CI/CD הוא ראשי תיבות של continuous integration/continuous delivery (CD מתפרש לעיתים גם בתור continuous deployment), דהיינו אינטגרציה רציפה של הקוד החדש לקוד המקור הקיים של התוכנה, ומסירה רציפה ללקוח של גרסת התוכנה החדשה.
במתודולוגיית הפיתוח הזריז ובתרבות ה-DevOps, עקרונות הCI/CD מהווים מרכיב מרכזי, וכוללים תמיכה במערכות המאפשרות פיתוח, בדיקות, אינטגרציה ופריסה רציפים ומתמשכים של התוכנה, לאורך כל מחזור חיי הפיתוח שלה.
רקע ותהליכי CI/CD
[עריכת קוד מקור | עריכה]במהלך פיתוח תוכנה, ישנם תהליכים מוגדרים רבים שעל קוד המקור של התוכנה לעבור, לפני שתוכל התוכנה להימסר ללקוח.
מטרת כלי ותהליכי CI/CD היא לעשות אוטומטיזציה לתהליכים אלה, ולחבר בין תהליכים שונים, כך שהתוצר של כל תהליך הוא בסיס העבודה של התהליך שלאחריו, וסופו של כל תהליך מניע את הפעלת התהליך הבא. מכלול התהליכים האוטומטיים שעובר קוד המקור של התוכנה נקרא CI/CD pipeline, או הפייפליין.
CI/CD מהווה גשר על הפערים בין צוותים שונים, על ידי אכיפת אוטומציה בבניית, בדיקת ומסירת התוכנה. כך לדוגמה, לאחר שמפתח התוכנה מוסיף שינוי לקוד המקור של התוכנה, תהליך פייפליין מעביר באופן אוטומטי את תוצר השינויים לצוותי בקרת האיכות, המוודאים את תקינות התוכנה לאחר השינוי. תהליך ההעברה לבקרת האיכות עשוי להיות מופעל באופן מיידי עם הכנסת השינוי, או בזמנים מוגדרים, כגון בסיום יום העבודה.
תהליכים אוטומטיים שעשויים להיות חלק מתהליך הפייפליין הם:
- בדיקת תקינות השינוי ברמה בסיסית: ווידוא שהשינוי מקושר היטב למערכת ניטור משימות כגון Jira, בדיקה שהשינוי איננו מכיל פרצת אבטחה, כגון דליפה של מפתחות פרטיים.
- בנייה של קוד המקור של התוכנה יחד עם השינוי החדש, ווידוא שהשינוי איננו יוצר בעיות קומפילציה.
- מיזוג הקוד המכיל את השינוי החדש בגרסת התוכנה המיועדת לשחרור ללקוח.
- התקנת התוכנה בסביבה המתאימה והרצת בדיקות אוטומטיות על המוצר.
- התקנה של התוכנה החדשה על שרתי בדיקות ידניות, שישמשו את אנשי הQA בתהליך עבודתם ביום העבודה הבא.
כישלון בביצוע אחד מן השלבים ימנע את מעבר התוצר לשלב הבא, ויחייב את המפתח או את הבודק לתקן את החלק המכשיל את הפייפליין. לאחר בדיקות התוכנה בכללותה, וקבלת אישור מצוותי בקרת האיכות, תהליכים נוספים עשויים להיות מופעלים כדי להתקין את עדכוני התוכנה אצל הלקוח.
כלים המשמשים ליצירת CI/CD pipeline
[עריכת קוד מקור | עריכה]כלי CI/CD מהווים את התשתית המאפשרת את האוטומציה של תהליכי הפייפליין. על גבי תשתית זו, נכתב הקוד המארגן את עיבוד קוד התוכנה עד למסירתו כמוצר מוגמר. הפייפליין עשוי להיות כתוב בשפות שונות - שפות תסריט כגון bash או python מחד, ושפות ייעודיות כגון תחביר הפייפליין של gitlab או ansible מאידך.
כלי CI/CD נפוצים הם Jenkins, Gitlab pipeline, Zuul וCircle CI. כלים אלה משמשים בדרך כלל מספר רב של מפתחים במקביל, כאשר 'עבודות' עבור מפתחים וצוותים שונים מתבצעות לפי תור, או בהתאם ליכולות העיבוד של השרת. לדוגמה, Job (תהליך פייפליין מוגדר) אחד יכול לשמש מפתח המעוניין להכניס את הקוד שלו למאגר הקוד של התוכנה, כאשר במקביל job אחר עשוי להריץ בדיקות אוטומטיות עבור צוותי בקרת האיכות, על גרסה המיועדת לשחרור ללקוח.
קישורים חיצוניים
[עריכת קוד מקור | עריכה]- אמיר עוז, אינטגרציה של החיים: כיצד CI/CD מייעלת משמעותית פיתוחים ב-2021?, באתר "אנשים ומחשבים", 25 באוגוסט 2021
הערות שוליים
[עריכת קוד מקור | עריכה]- ^ Irani, Zubin (2018-03-28). "5 common pitfalls of CICD -- and how to avoid them". InfoWorld (באנגלית). נבדק ב-2017-12-21.
- ^ Heller, Martin (2015-07-20). "Continuous integration is not always the right answer. Here's why". TechBeacon. נבדק ב-2017-12-21.
- ^ Atlassian (2017-04-14). "Continuous integration vs. continuous delivery vs. continuous deployment". Atlassian. נבדק ב-2019-04-04.