(סדרת מאמרים על Serverless, CI/CD, Dev והרבה קוד)

המאמר הנוכחי מתמקד באפשרויות והשיטה סביב CI\CD, אז מהיכן להתחיל?

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

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

על CI/CD וגם Deployment

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

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

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

אחת ההמלצות הקיימות בשטח היא לאנשי פיתוח היא ביצוע merge לפחות פעם אחת ביום של הקוד לאותו מקום מרכזי ולא למקום (feature branch).

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

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

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

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

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

בנוסף לכך יש את Continuous Deployment (בקצרה CDT או CDD) ומטרתו היא זהה לשיטת Continuous Delivery אך עם הבדל משמעותי של אוטומציה בפריסת השינוי בקוד והכוונה היא ברגע שנעשה שבוצע Review על הקוד והשינוי נפרס אוטומטית.

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

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

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

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

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

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

מימוש ויתרונות CI/CD

לתצורת עבודה של CI/CD ישנם מימושים שונים וישנם יתרונות אך כמו בכל דבר תרחיש שמתאים לפיתוח במצב מסוים אינו יתאים למצב אחר.

אחת מצורות המימוש המוכרות והלא חדשות כלל היא

ביצוע ויישום – המנגנון של CI אחראי על זיהוי של הכנסת קוד וביצוע Commit למערכת, משיכת הקוד, ביצוע קימפול, Build, התקנה והרצת כל הבדיקות שאורכות 15 דקות בממוצע, ובנוסף לכך הפעולות ידרשו ביצוע עולות של Unit Tests.

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

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

• ביצוע Code Review
• ביצוע בדיקות מסוג Unit Test
• ביצוע סימולציות ותהליכים (למשל, כאן נכנס Integration)
• ביצוע בדיקות תקינות
• העלאה ופרסום מסודר (ידני או אוטומטי)

ניטור שינויים – ניטור ובדיקות בזמן אמת של התהליכים לטובת זיהוי בעיות או חריגות

תחקור – תחקור על שינוי לא תקין או באג חדש אשר נוצר בעקבות השינוי

לצד המימוש, ישנם יתרונות של תצורת עבודה מבוסס CI\CD, בין היתר:

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

CI/CD בשירות Azure

בשירות Azure ניתן לעבוד בתצורה של CI/CD על גבי פלטפורמות רבות ושונות, בין היתר הדוגמה שלפנינו על גבי Azure Web Apps עם שפות כדומגת ASP.NET, Java, Node.js, PHP. במצב כזה אנו יכולים לדלוור באופן מהיר באמצעות ניהול Pipeline מבוסס CI\CD שינויים רבים לאפליקציה או לפטפורמה שאותה אנו מפתחים.

לסיכום

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

אין עובדים ומבצעים ניהול תהליך שינויים מהסוג הנ”ל – במאמר הבא.