מה כדאי לסטודנט לדעת- CI/CD

אחרי הפוסטים של טסטים וגיט, הגיע הזמן לשילוב שלהם- תהליכי CI/CD.

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

• CI: אינטגרציה רציפה (continues integration), כלומר, רציפות של איחוד הקוד המקומי עם הקוד המשותף.
• CD: מסירה רציפה (continues deployment), כלומר, העברה רציפה של הקוד מסביבת הבדיקות לסביבת השימוש.

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

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

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

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

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

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

CI

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

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

תהליך הCI מתמקד בבדיקות, ולכן נפגוש אותו כשנעשה Pull Request, והוא יריץ בדיקות קצרות (בדרך כלל build וUnit tests לפחות) כדי לוודא בצורה בסיסית שאין בעיה קריטית בקוד, ושאנחנו יכולים לבצע Merge.

לאחר מכן תהליך CI אחר יריץ בדיקות מלאות יותר, מUnit tests ועד e2e (ר"ת End to end), ואולי גם בדיקות על שרתי טסטים וכד'.

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

CD

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

למה אני מתכוון?

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

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

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

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

לקריאה נוספת:

• ג'נקינס- ג'נקינס היא תוכנת קוד פתוח לביצוע תהליכי CI/CD. ניתן להתקין אותה על כל מחשב (המחשב האישי, שרת החברה, שרת בענן) ולהגדיר פעולות לביצוע.

מושגים לשפה המקצועית:

• CI: אינטגרציה רציפה (continues integration), כלומר, רציפות של איחוד הקוד המקומי עם הקוד המשותף.
• CD: מסירה רציפה (continues deployment), כלומר, העברה רציפה של הקוד מסביבת הבדיקות לסביבת השימוש.