בשנתיים האחרונות יותר ויותר חברות עוברות לעבוד בשיטה של CI/CD אך במקביל יותר ויותר אנשים לא מבינים על מה המהומה ומה הדרך הזו בעצם נותנת. על CI/CD אפשר לפתוח בלוג שלם. יש ספרים, הרצאות ועוד ועוד. אין בכוונתי כאן להיכנס לעומק הנושא אלא רק לנגוע בדברים בכלליות.
נתחיל בהסתכלות על המצב ה"קלאסי" של פיתוח, אצל חברות שמפתחות תוכנה המשווקת לציבור. בחברת הפיתוח יושבים כמה מפתחים וכל אחד (או קבוצה) אחראים לפיתוח חלק כלשהו. GUI, לוגיקה, ועוד ועוד. כל קבוצה (או יחידים) מפתחים בנפרד ובסוף יום (או כמה פעמים ביום) כל אחד מעלה את הקוד שלו למערכת SCM (ר"ת Source Code Management) ואחת לזמן מה מגיע החלק הקשה – איחוד הקוד של כל האינדיבידואלים או הקבוצות השונות לקוד אחיד למה שיהיה בהמשך גירסה חדשה של התוכנה. באיחוד כזה מתרחשים הרבה קונפליקטים מבחינת קוד – אחד שבר (בטעות) קוד ישן, השני הגדיר דברים בצורה שונה והקוד שלו בעייתי לאיחוד, ויש עוד שלל בעיות באיחוד קוד (שלא לדבר על ההערות שנזרקות…) שנכתב לאורך תקופה ללא איחוד. אלו כמובן בעיות שיש להן פתרון (במיוחד עם GIT..) ולכן עולה השאלה "בשביל מה אנחנו צריכים CI/CD אם אנחנו לא סטארט-אפ?"
ל-CI/CD (ר"ת של Continuous Integration ו-Continuous Deployment בהתאמה) יש (די בצדק) שם שמתאים לפיתוח בדרכים של ASD (ר"ת Agile Software Development) או בשם יותר ידוע – XP (ר"ת Extreme Programming), מה שדי מרתיע חברות פיתוח "קלאסיות" מאימוץ CI/CD, אבל יש יתרונות גדולים ל-CI/CD:
- זמן פיתוח קצר בהרבה
- שמירת תאימות לאורך זמן
- תיקון באגים בזמן קצר בהרבה בהשוואה למצב הקלאסי
- ה-Time To Market מתקצר משנים לימים או שבועות.
- לקוחות מקבלים יותר פונקציונאליות ושרותים נוספים מבלי להמתין זמן רב עד שהחברה תכתוב את הקוד הכרוך בפונקציונאליות הנוספת.
- קל למצוא באגים בקוד ולתקן במהירות.
- כל המערכת רצה בצורה הרבה יותר יציבה
- זמן ה-Downtime מתקצר לאחוזים בודדים
כך שיש יתרונות רבים למעבר לעבודה במתודולוגיה של CI/CD. גם מצד המפתחים עצמם אין הרבה שינויים שהם צריכים להתרגל. הם צריכים לדחוף את הקוד שלהם בתכיפות יותר גדולה ולהריץ (ולכתוב) יותר טסטים כדי לוודא שהקוד יציב, אבל בשאר הזמן הם ממשיכים לכתוב קוד כבעבר, רק שהקוד שלהם מגיע לפרודקשן הרבה יותר מהר (לאחר בדיקות כמובן).
נכיר בקצרה את Jenkins. מערכת Jenkins נוצרה ב-2005 ע"י מפתח שעבד ב-Sun ו-Sun שחררה את הקוד לקהילה והמוצר עבר שינויים שונים במהלך חייו והיה נקרא Hudson. ב-2011 חברת אורקל (שרכשה את SUN) הצליחה להסתכסך עם קהילת המפתחים בקוד פתוח ולפיכך המפתחים החליטו לקחת את הקוד ולפצל (Fork) את המוצר ולתת לו שם חדש: Jenkins.
ל-Jenkins ישנם יכולות רבות בכל מה שקשור ל-CI/CD. המערכת עצמה מתאימה הן למשימות פשוטות (קימפול קוד והנגשת קבצים בינאריים לשותפים עסקיים לדוגמא) ועד לעבודות מורכבות הקשורות להעברת קבצים בינאריים למערכות אחרות, המתנה לתשובות והעברה לפרודקשן, או להקמת מכונות VM חדשות שיריצו את החבילות הבינאריות החדשות, אך זה לא נעצר כאן – ל-Jenkins יש גם מספיק תוספים שמאפשרים פונקציונאליות כמו בדיקת סגנון קוד, הפצת קבצים בינאריים/חבילות (לדוגמא: artifcats) ועוד פונקציות רבות שמצריכות התקנת Plugin (לגבי מתחרים ל-Jenkins – ראו התייחסות בהמשך).
אחרי שהקמנו מערכת Jenkins, אנחנו מתחילים להשתמש בה והעבודה ב-CI/CD מתחילה עם המפתחים. אחרי שהמפתחים דחפו את השינויים מגיע תור ה-CI Server או במקרה שלנו – Jenkins לעשות את העבודה. ניצור JOB שבו בעצם אנחנו מגדירים ל-Jenkins מה לעשות. מהיכן לקחת את הקוד, מה לקמפל, ומה לעשות עם הקבצים (כמו לדוגמא האם להעביר אותם בדיקת סגנון קוד עם SonarQube לדוגמא) להעלות אותם ל-Artifactory, לשרת אחר וכו'.
מבחינת המפתחים, כשעובדים ב-Continuous Integration כל מפתח כותב את הקוד שלו, מוריד את הקוד של האחרים מה-SCM, משנה את הקוד שלו בהתאם על מנת לאחד אותו עם השאר, מריץ קוד בדיקות (Unite Testing), ולאחר שהקוד עבר בהצלחה בדיקות מקומיות, הוא מבצע Push ל-SCM. את התהליך עושים מספר פעמים ביום בכל פעם שכותבים חלק, לדוגמא – כותבים פונקציה חדשה, משפרים משהו קיים, מתקנים באגים וכו'. משם Jenkins ימשיך את תהליך ה-CI אם נגדיר לו מתי (אם לבדוק את ה-SCM אם מישהו ביצע commit לדוגמא, או לפי שעון).
אחד החלקים החשובים בפילוסופיית ה-CI היא שמירת תאימות. אפשר להרחיב דברים, אבל לא מומלץ לשבור את התאימות אחורה הואיל ושבירת תואמות גם גורמת לנו נזק בהמשך השרשרת כשטסטים אוטומטיים שונים נכשלת. אם צריך לשבור תאימות, עדיף כמובן ליצור Branch ב-SCM ולעבוד עליו.
מכאן אנו עוברים לחלק של ה-CD או ה-Continuous Deployment: קימפול והכנת קבצים בינאריים וחבילות זה טוב – אבל צריך לעשות עם זה משהו…
ב-Jenkins יש לנו "צינורות" (Pipelines) ועם הפונקציונאליות הזו אנחנו נגדיר ל-Jenkins מה אנחנו הולכים לעשות עם הקבצים הבינאריים. אנחנו יכולים לדוגמא להגדיר בצינורות לזרוק את הקבצים הבינאריים בשרת טסטים, להריץ טסטים שונים (Unit tests, Selenium ועשרות סוגים שונים של בדיקות, תלוי בקוד, פלטפורמה וכו'). לאחר שהקבצים עברו בהצלחה בחינה, אנחנו יכולים להורות בצינור לבצע Deploy של החבילות בשרת "מראה" של פרודקשן להתקין את החבילות ולהריץ בדיקות שונות נוספות. לאחר שגם כאן הבחינות עוברות, אפשר להורות בצינור להטמיע את החבילות החדשות בשרתי הפרודקשן באופן אוטומטי או לפי הוראה של המפתחים/מנהלים.
המעבר ממצב תכנות ועבודה "קלאסית" למצב CI/CD לוקח אמנם זמן ותכנון מראש, אולם מהרגע שעוברים – רואים את התוצאות בזמן קצר מאוד. כיום, כשחברות רבות מעדיפות לדוגמא לתת שרותי SAAS/PAAS ללקוחות, הם (הלקוחות) מבקשים לעיתים תוספות שונות, הן ב-API והן בפונקציונאליות. בעבר תשובה ללקוח כזה היתה משהו כמו "תודה על הפידבק, ניקח זאת בחשבון ואולי נוסף לגירסה שתצא בשנה הבאה", כיום אם החברה מוצאת שהרחבה כזו חשובה – אפשר להוסיף קוד שנותן פונקציונאליות נסיונית (ולהצהיר על כך ללקוחות שמדובר בתוספת שהיא BETA) תוך זמן קצר יותר מבעבר ואז לפי הפידבק שניתן מהלקוחות ואפשר להוסיף/לשנות דברים. כך לדוגמא גוגל, אמזון ומיקרוסופט עובדים בכל מה שקשור לשירותים חדשים בענן.
בסופו של יום, לקוחות דורשים מיצרניות התוכנה והשירותים דברים רבים והם מעוניינים במענה מהיר ואם הם לא מקבלים, הם לא מתביישים להתחיל לבדוק את הפתרונות של המתחרים (תשאלו את Pay pal) ואף לעבור למתחרים, מה שעלול לגרום הפסדים כספיים. עבודה ב-CI/CD יכולה לעזור בקיצוץ הזמנים באופן ניכר.
מה לגבי מתחרים ל-Jenkins? ישנם לא מעט מתחרים ל-Jenkins בשוק (הנה לדוגמא טבלת השוואה קצרה בין ל-Jenkins ו-2 פתרונות אחרים מובילים, החלק של Open Source לא כל כך עדכני לגבי המתחרים), אך הבעיה הראשונה של רובם שהם פתרונות SAAS, כלומר שהמערכת אינה נמצאת אצלך בשרתים אלא אצל חברה אחרת ואתם משלמים לה. זה יכול להיות פתרון טוב אם הקוד כולו מהרגע הראשון הוא קוד פתוח, אולם מצד שני – אני לא מכיר הרבה חברות שיש להן קוד סגור שמעוניינות לבצע Build אצל חברות זרות. יחד עם זאת, כמובן – יש ויש.
מבחינת תאימות פלטפורמות – Jenkins הוא קוד פתוח מ-א' ועד ת' והוא רץ יפה מאוד על Windows (לא צריכים Windows Server), מק וכמובן לינוקס. הוא תומך בכל שפה, ויש לו יותר מ-1200 תוספים שונים שכוללים תמיכה בכל SCM, בכל קומפיילר, אותנטיקציה, אחסון וכו'. יחד עם זאת, כדאי לקחת בחשבון שלא כדאי "לערבב" – אם לדוגמא הקוד שלכם כתוב ב- #C, הקימו את Jenkins על Windows, אך אם אתם כותבים בשפות אחרות שרצות על לינוקס, עדיף להרים את ה-Jenkins על לינוקס הואיל ותחזוקת האבטחה הרבה יותר קלה.
לסיכום: CI/CD אינם "אופנה חולפת". יותר ויותר חברות משתמשות בה – מגוגל, פייסבוק, מיקרוסופט, אמזון, פייפאל ושלל חברות נוספות משתמשות בה. יש בשיטה הזו הרבה מאוד יתרונות לעומת השיטה הקלאסית ועקומת הלימוד ומעבר אינה כה גדולה (המאמץ הכי גדול הוא בכתיבת הסקריפטים בפעם הראשונה כדי לבנות/לבדוק/להפיץ/להטמיע וכו'), אין צורך בהשקעה רצינית בתשתית וניתן תוך זמן קצר (יחסית, תלוי בחברה, נהלים וכו') לעבור לעבוד בדרך זו.
[stextbox id="info" caption="הערת מפרסם"]הח"מ פרילאנסר שמחפש עבודות בתחום לינוקס, Devops, ודברים הקשורים ל-Software Defined Storage, וירטואליזציה וכו'. מי שמעוניין בפרטים – אפשר למצוא אותם כאן.[/stextbox]