USA / Canada 866-503-1471

International +972-722-405-222

« לעמוד הראשי

על מסע ה- 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 מכוניות שכבר נמצאות בשטח.

devops jaguar

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

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

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

 

מעוניינים להירשם לניוזלטר שלנו ולקבל חדשות ועדכונים עתידיים מעולם ה- DevOps? שלחו לנו מייל ל- devops@almtoolbox.com  – אנו מבטיחים לא לשלוח SPAM !

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

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

 

מסע ה- DevOps שלהם

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

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

DevOps Journey Jaguar Phoenix project book

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

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

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

DevOps Journey Jaguar Gitlab qualifying laps

הם התחילו עם 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:

DevOps gitlab Jaguar

 

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

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

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

devops jaguar gitlab docker

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

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

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

devops jaguar gitlab docker aws

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

 

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

devops jaguar gitlab aws reducing delivery

ממצב של 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 החדש (ובכך להקדים יצרנים אחרים שמייצרים מכונית חשמלית)
  • חשוב לשאול "למה?" בכל שלב, ע"מ לאתגר את הלך החשיבה של הצוות, ומתוך כך להגיע לשיפורים בתהליכי העבודה.

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

 

חברת ALMtoolbox מתמחה בליווי קבוצות פיתוח ובדיקות במסע ה- DevOps ובשיפור תהליכי עבודה המשלבים כלי-עזר לפיתוח לבדיקות ול- CI , דוגמת Jira, Git, Bitbucket, GitLab, Jenkins , SonarQube, Hashicorp's Terraform, Spotinst, Rancher Labs, Artifactory, Nexus, Snyk, White Source, Coralogix, GitHub ונוספים, ביעוץ ובמכירת רישוי לכלים (רשימת הכלים המלאה נמצאת כאן).


נקודות שעלו בתיאור המסע של LandRover ובהם אנו מסייעים ללקוחות (ונוכל לסייע גם לכם):

  • תכנון מסע ה- DevOps – כולל היבטים מתודולוגים וטכניים
  • תכנון מעבר לענן ולעבודה עם קונטיינרים ו- Kubernetes
  • תכנון ובניית סביבות CI, CD, אוטומציה ובדיקות
  • בחירת כלים, בחינה כלכלית של עלויות, ומכירת רישוי במידת הצורך
  • חיבור בין הכלים – ופיתוח אינטגרציות מותאמות במידת הצורך

חברת ALMtoolbox היא המייצגת הרשמית והיחידה של GitLab בישראל ובמדינות נוספות.

לשאלות: 072-240-5222 או devops@almtoolbox.com

 

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

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

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

 

 

נסו את כל הפיצ'רים שב- GitLab ל- 30 יום , בענן או על שרת פרטי – ללא התחייבות.

להתנסות לחצו כאן. שאלות? צרו איתנו קשר

x icon svg