תשכחו מ-Scrum ו-Waterfall ובואו נדבר על CI/CD

כולם מדברים על זה אבל האם CI ו-CD באמת מסמנים את העתיד?

computer

מאת כפיר רוטברד

כולם מסביב מדברים על CI/CD (ר”ת של Continuous Integration ו-Continuous Delivery בהתאמה) הדרך החדשה והנכונה לעשות דברים. בכל הכנסים מדברים על זה וכל הסימנים מראים שזה הדבר הנכון הבא.

אומרים לנו שעבודה ב-Scrum נחשבת כבר לעבודה בשיטות של ימי הביניים ושעבודה במתודולוגית Waterfall כבר ממש נחשבת למתודולוגית עבודה מ”תקופת האבן”, ופשוט חייבים להתחיל לעבוד ב-CI/CD ואכן, ישנם הרבה דברים טובים ש-CI/CD נותן לנו:

  • זמן פיתוח קצר בהרבה.
  • תיקון באגים בזמן קצר בהרבה בהשוואה למצב הקלאסי.
  • “זמן ההגעה לשוק” מתקצר משנים לימים או שבועות.
  • לקוחות מקבלים יותר פונקציונאליות ושירותים נוספים מבלי להמתין זמן רב עד שהחברה תכתוב את הקוד הכרוך בפונקציונאליות אחרות.
  • קל למצוא באגים בקוד ולתקנם במהירות.
  • כל המערכת רצה בצורה הרבה יותר יציבה.

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

  1. לפתח את היכולת ל״הדליק ולכבות״ קטעי קוד – Feature toggle.
  2. לכתוב בדיקות אוטומטיות טובות.

זהו זה? רק שתי דרישות? פשוט וקל! ובכן, לא כל כך קל

בואו נתחיל עם Feature togg, זוהי היכולת לכבות תכונות שעדיין לא פותחו במלואן, לפרוס את הקוד לסביבת הייצור עם קוד “אפוי למחצה” אבל כבוי. ככה התכונות החדשות לא יופיעו כחלק מהמערכת, ואם שמרנו על הכללים של Feature toggle – הן גם לא יגרמו לרגרסיה בהתנהגות המערכת.

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

בדיקות אוטומטיות טובות הן אגוז קשה לפיצוח. הגישה ״לפי הספר״ היא שאנחנו צריכים הרבה מאוד בדיקות יחידה (Unit tests), קצת פחות (אבל עדיין הרבה יחסית) בדיקות אינטגרציה ומספר קטן יחסית של בדיקות מערכת/GUI.

ראו להלן איור שממחיש את התצורה הזאת:

פירמידת הבדיקות האוטומטיות

האתגרים ליישם זאת הם גדולים, לדוגמא:

1. מספר בדיקות היחידה הנדרשות ומספר בדיקות האינטגרציה הוא בדרך כלל גדול.
2. בדיקות אלה צריכות להיות מהירות מאוד שכן הן נועדו לרוץ בכל פעם שאנחנו מבצעים Commit לקוד שלנו.
3. בדיקות אינטגרציה דורשות סביבה מיוחדת כדי להפעיל אותן (כולל לפעמים סט נתונים מוכן מראש).
4. נדרשת תשתית בדיקות.

בנוסף לדרישות אלו ישנן עוד דרישות, זה השלב שבו בדרך כלל צוותים רבים מוותרים, שכן המאמץ הנדרש פשוט גדול מדי. עם זאת, יש דרך אחרת. הרשו לי להציג לפניכם את ה “פסאודו CI/CD”, דרך שמביאה את היתרונות שיש ל-CI/CD עם מינימום המאמץ שכרוך ביישום שלה.

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

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

הבדיקות האלה צריכות להיות מהירות יחסית, לא כדאי שייקח להן יותר מ 20 דקות לרוץ. יש כל מיני שיטות איך לשפר את זמן הריצה של בדיקות מערכת.

השלב השלישי הוא להפעיל את הבדיקות האלה בכל פעם שאנחנו פורסים את הקוד לסביבה אינטגרציה/ייצור. הבדיקות אלה חייבות לעבור בהצלחה (כן כל הבדיקות, בלי הנחות כאן) כדי שהפריסה תושלם בהצלחה.

זהו זה. סיימנו.

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

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

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

לסיכום

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

הכותב הינו דירקטור מחקר ופיתוח בחברת נטורל אינטלג’ינס

כתב אורח

אנחנו מארחים מפעם לפעם כותבים טכנולוגים אורחים, המפרסמים כתבות בתחומי התמחות שלהם. במידה ואתם מעוניינים לפרסם פוסט בשמכם, פנו אלינו באמצעות טופס יצירת קשר באתר.

להגיב

11 תגובות

  1. rumplestillskin הגיב:

    כתבה מאוד רדודה.

    מה לגבי end to end testing?
    מה לגבי מתודולוגיות בדיקות?
    אין לי כח להכנס אפילו לכל מה שחסר במאמר,
    באמת שאני לא מבין מה המטרה שלו, בחיי שהכתבה כביכול מסתיימת בכותבת ״סקאם וכו׳ זה העבר, העתיד הוא בci״ וזהו.

    חבל.

    • איתי הגיב:

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

    • אבי הגיב:

      E2E זה end to end testing אם לא הבנת

  2. Joe הגיב:

    אין קשר בין סקראם ל CI/CD.

    אחד זאת שיטת ניהול פרוייקטים ואחד שיטת שחרור קוד.

    אפשר לעשות סקראם עם CI/CD, ואפשר שלא.

  3. אבי הגיב:

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

  4. סקראמר הגיב:

    מצטער אבל לא נראה שהכותב מבין כמה דברים בסיסים … מה קשור סקראם וci cd ?
    זה שני מתודולוגיות שיכולות לעבוד ביחד ומשתלבות נהדר
    אחת מנהלת את משימות הפרויקט והשניה תומכת באוטומציה של כל התהליכים
    כתבה זו מאעה את הקוראים.

  5. איציק הגיב:

    זה בערך כמו לכתוב – תשכחו מכובעים ותתחילו לענוד משקפי שמש – לא סותר

  6. ליאור הגיב:

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

  7. David Tzemach הגיב:

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

  8. עומר הגיב:

    CI/CD זו לא מתודולוגית פיתוח קוד. מה עובר עליכם? אפשר לעבוד סקראם וגם עם CI/CD.

    כתבה לא רצינית ו/או רלוונטית.

תגיות לכתבה: