על מסע ה- DevOps לענן שעשו ב- Jaguar LandRover בסיוע GitLab

הפעם בחרתי לסכם הרצאה מכנס "DevOps Enterprise SUMMIT" שהיתה בלונדון בחודש שעבר, ולפני כמה ימים יצאו הקלטות מהכנס. את הכנס ארגן Gene Kim, מחבר הספר הידוע  "The Phoenix Project".
בחרתי לסכם את ההרצאה הספציפית הזו מכמה סיבות:

• מסופר בה סיפור מעניין, המספר סיפור מסע על DevOps, שכולל ניסוי וטעיה – הדובר (מנהל מחברת Jaguar LandRover) לא מסתיר דברים שניסו ונכשלו בהם.
• מדובר במערכת שמופצת למאות אלפי התקני-קצה (מכוניות)
• בהרצאה מודגם שימוש מעניין ב- GitLab , AWS, Docker, GitLab CI/CD ועוד

הקלטה של הסרטון המלא (כחצי שעה) נמצאת בסיום המאמר.

DevOps Journey at Jaguar

הדובר היה Chris Hill , ותפקידו – Head of system engineering Infotainment Jaguar Landrover .

Chris מנהל קבוצה של מפתחים שמטרתם היתה לשפר את דילבור התוכנה של המערכת שהם מפתחים – שמורכבת מ 75 מודולים, ומופצת ל 750.000 מכוניות שכבר נמצאות בשטח.

Chris הציג רכב עם בטריה חשמלית שיצא בחודש הבא – הרכב החשמלי הראשון שיגואר מוציאה (Jaguar I-PACE למי שמעוניין לרכוש – הרכב זמין בקרוב גם בארץ …) . הוא הציג את תהליכי ה- DevOps  שהם מבצעים ואת ה- "DevOps Journey" שלהם. המסע שלהם החל ב – 2016, ואורכו עד כה שנתיים – והוא טרם הסתיים. הוא הציג זאת כמסע של שינוי והשתפרות תמידית.

קבוצת הפיתוח שלו אחראית על מוצר שנקרא "Infotainment" – זהו איזור התצוגה שנמצא לצד הנהג (היכן שמופיע הסמל JAGUAR בתמונה לעיל). ה- Infotainment הוא התקן אחד מתוך 40 התקני embedded שיש בכל כלי רכב – ההתקנים מדברים ביניהם בזמן אמת.

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

על החברה (Jaguar Land Rover):

• 40.000 עובדים
• הכנסות של 24 מליארד פאונד (ליש"ט) ב 2017 (מרכז החברה בלונדון)
• 604.000 כלי רכב שנמכרו ב 2017
• 5.000 מפתחי תוכנה

מסע ה- DevOps שלהם

כך זה היה נראה בהתחלה:

(אפשר להקליק על התמונה להגדלה)

הם החלו את מסע ה- DevOps שלהם ב 2016 עם 2 עובדים  — בפורטלנד אורגון ארה"ב — והחלו אותו בקריאה של הספרים
"The Phoenix Project" (האייקון בתמונה למעלה עם איור המפעל הוא מעטיפת הספר)
ו"המטרה" של ד"ר אליהו גולדהרט ז"ל (המדבר על תורת האילוצים – קישור להרצאה מוקלטת בסוף המאמר).

(הספרים אגב מומלצים – וגם לדעתי – קראתי אותם לפני כמה שנים).

הצעד הבא היה לבנות שרת:

הם התחילו עם GitLab CI , GitLab, Git, Linux.

כריס תיאר שהעדיפו כלי open source. הוא גם תיאר שלפני כן הם עזבו את מוצרי Atlassian. לדבריו, אטלסיאן טובים ב- Jira , אבל Version Control   ו- Continuous Integration  זה לא ה- core business  שלהם, וכך גם נראים המוצרים שלהם בתחום זה.  "אטלסיאן מוכרים לפעמים חבילה מלאה של כמה כלים, ואז הלקוח נתקע עם פתרון שלא מתאים לו והוא לא רוצה בו"  – ולכן החליפו ל- GitLab.

כריס גם סיפר שעזבו את GitHub  ואת Jenkins כי העדיפו קוד פתוח ולא היו מרוצים מעליית המחירים הגדולה של Jenkins Enterprise שהיתה בשנה האחרונה (קישור לפוסט המקורי שבו אמר זאת נמצא כאן בסוף המאמר). סיפר גם שלקחו את GitLab CI משום שהוא עובד יחד עם GitLab בחבילה אחת נוחה.

ובחזרה לסיפור המסע:

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

כעת היו להם  3 פרוייקטים , והם גילו כמה בעיות חדשות:

• רק איש אחד שידע כיצד עובד ה- build ואיך להפעיל אותו וכיצד עובדות הבדיקות האוטומטיות  (שעברו לרוץ כחלק מה- CI)
• חלק מהפרוייקטים "שתו" את כל משאבי השרת – כך שלפעמים ה- Version Control לא תפקד כי כל משאבי המערכת הלכו להרצת build  (כי שניהם ישבו יחד על אותו שרת)

ולכן הם קנו עוד חומרה – והגיעו למצב של 3 שרתים ו- 3 שרתי builds:

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

כריס מתאר שבשלב זה גם קיבלו תלונות ממשתמשים (שאפילו העדיפו לחזור להריץ builds על המכונה הפרטית שלהם).

בעקבות זאת הם הגיעו להחלטה לבנות מכונות זמניות מבוססות Docker ו- GitLab Runner – ע"מ לפתור את בעית המשאבים המוגבלים של מכונות ה- builds :

תשתית מבוססת קוד

וכאן חידוש נוסף היה מבחינתם – לראשונה, כל התשתית היתה מבוססת קוד  (הם השתמשו ב- Packer של חברת Hashicorp).
בנקודה זו  גם הרצת ה- build הפכה להיות בשירות-עצמי למפתחים – והם קיבלו את היכולת להריץ זאת לעצמם בעצמם.
זה עבד היטב — התלונות על עיכובים פסקו — ונוספו פרוייקטים ומשתמשים!

ועם הגידול הגיעו בעיות חדשות… המציאות החדשה יצרה בעית capacity ומשאבים. הדבר המשמעותי שהכי הציק להם כאן היה תחזוקת החומרה (שנבעה מהפסקות חשמל ; הפסקות תקשורת; חומרה שמתקלקלת ועוד). הענין הזה הקשה עליהם מאוד – ולכן זה היה השלב שבו הם החליטו לעבור לענן:

כעת – במקום קונטיינרים זמניים שרצים על חומרה שלהם – היו להם קונטיירים זמניים מבוססי מכונות AWS EC2, ובכל פעם שנעשה git commit, שהוביל להרצת build – נוצרה מכונה זמנית חדשה (שחוסלה לאחר סיום הריצה) – וכך הם פתרו את בעית חוסר ה- capacity.
בנקודה זו היו כבר 50-60 מפתחים שהם משתמשי המערכת, ונוספו פרוייקטים – בפרט פרוייקטים גדולים שגם נתפסו כקריטיים יותר לארגון.
בנקודה זו כריס התבקש לעשות רילוקיישן לאנגליה ולהמשיך את הפרוייקט משם, סמוך למטה החברה, משום שהפרוייקט הפך לחשוב יותר מבחינת החברה.

האתגר הבא שלהם היה לשפר את הפידבק ולתת fast feedback :

ממצב של 4-6 שבועות (עד לקבלת פידבק חוזר על פיצ'ר חדש) הם קיצרו זאת ל- 30 דקות!
הם השיגו זאת ע"י ביצוע אוטומציה לכל רכיב שניתן ליישם לו אוטומציה (ובפרט ציין שהאוטומציה הקטינה את העומסים סביב ה- Code Review וה- Pull /Merge Requests).
הם פישטו את מערכת ה- build ונתנו לכל המפתחים להריץ build לעצמם בעצמם (כשירות-עצמי). כריס נתן כדוגמא סיטואציה שבה מפתח JavaScript שלא מכיר כלל Linux, יודע כיום איך להוסיף את הרכיב שלו למערכת ה- build ועושה זאת לבדו ב- 30 דקות.

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

כיום הם מצליחים לעשות deployment למכוניות עצמן בתוך שעה! מה שהיה לוקח להם 6 שבועות – לוקח כעת רק שעה – מה- build עד שהעדכון רץ בכל רכב – ויותר מזאת: ה- deploy אפשרי אפילו כאשר המכונית במצב נסיעה (ע"י החזקת מערכת דואלית [בגישת "כחול וירוק"])  ואפילו 700 פעם ביום, כולל יכולת להפיץ מכל branch שרוצים.

לסיכום – מה הוא למד:

• הודה שלמד להכיר צדדים מעולם ה- DevOps שלא הכיר קודם לכן בעולם פיתוח התוכנה (וציין במיוחד: השראה; התמדה ו- continuous improvement)
• הדגיש שחשוב למצוא יתרון תחרותי ע"פ המתחרים – ומימוש DevOps יכול להשיג את היתרון הזה כפי שהם הציגו במסירה מהירה של דגם ה- I-PACE החדש (ובכך להקדים יצרנים אחרים שמייצרים מכונית חשמלית)
• חשוב לשאול "למה?" בכל שלב, ע"מ לאתגר את הלך החשיבה של הצוות, ומתוך כך להגיע לשיפורים בתהליכי העבודה.

לסיום, הוא אמר שיש להם עוד כברת-דרך לעשות במסע. המסע עוד לא תם, וזהו מסע של שיפור מתמשך.

הקלטת ההרצאה המלאה:

(שימו לב שאפשר להפעיל כתוביות אוטומטיות בלחיצה על כפתור ה – "cc")

קישורים רלבנטים:

• מאמר עם מנהל ה- Engineering מ-  Land Rover – מדוע העדיפו את GitLab ע"פ GitHub , Jenkins ומוצרי Atlassian
• אתר GitLab בעברית
• הרצאה של ד"ר אלי גולדהארט על תורת האילוצים (עברית)
• אתר Jira בעברית
• מאמר הסבר בעברית על Review Apps – הרצת review אפליקטיבי מלא בסביבה מבודדת, בלחיצת כפתור – שימושי לאנשי QA ואנשי Product
• הקלטת וובינר Build It Yourself (עברית) – הדגמת מערכת שמאפשרת למפתחים לבנות בעצמם סביבות מורכבות מבוססות Jenkins ו- ClearCase (הרעיונות המוצגים מתאימים לכל מערכת Version Control כגון GitHub, GitLab, Bitbucket, Git)
• התרשמות ראשונה מ- Jaguar I-Pace – הרכב החשמלי הראשון של Jaguar (כתבה ב- Ynet)