וידאו: הסבר והדגמה על GitLab CI/CD Catalog

בהקלטה הבאה אירחתי את דב הרשקוביץ, מנהל מוצר בחברת GitLab ,
שהציג את אחת היכולות הבולטות במהדורה GitLab 17.0 שיצאה ממש לאחרונה –
GitLab CI/CD Catalog

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

חלק ממלל ההקלטה ישנו כאן מתחת לוידאו.

הסברים והדגמה של GitLab CI/CD Catalog:

חברת ALM-Toolbox היא הנציגה הרשמית של GitLab בישראל (ובמדינות נוספות) מאז 2016
ובעלת נסיון רב במוצר הן בצד המקצועי/טכנולוגי והן בצד המסחרי (מכירת רישוי והתנהלות נכונה וחסכונית עם רשיונות המוצר).
החברה מציעה מגוון פתרונות רחב סביב המוצר, כולל תכנון והקמת סביבות, שירות מנוהלים על ענן פרטי, יעוץ, מכירת רישוי, חיבור לכלים משלימים (כגון Kubernetes, OpenShift, Vault, SonarQube, Terraform, Jira), הדרכות ועוד.
החברה עזרה עד כה למאות חברות מכל העולם בפתרונות סביב GitLab , ועמדה במבחני ההסמכה הטכניות והרשמיות של היצרן מאז 2017 ועד היום.
לפרטים נוספים צרו קשר: gitlab@almtoolbox.com או טלפונית: 072-240-5222

לנוחיותכם, אנו מצרפים גם את המלל של ההקלטה:

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

אנחנו יודעים כמה דברים: אנחנו יודעים שאף אחד לא מתחיל לבנות pipeline מאפס, מ-scratch.
תמיד מחפשים קודם משהו שמישהו עשה, כדי להיעזר בו, איזושהי תבנית, template, שאפשר לעשות לו customizing ולהתאים לנו.

[תמיר] זו בעצם תבנית או קומפוננטה שאפשר להשתמש בה?

[דב] כן. בקטלוג יש קומפוננטות וחלקים קטנים שבונים את הקטלוג. למעשה, זה CI templates שכולם מכירים, אבל הקטלוג בא לפתור 3 דברים משמעותיים.

הראשון, Discoverability : "מה יש לי שאוכל בכלל להשתמש בו?"
הרבה פעמים רואים שלקוחות בונים את האותו template שוב ושוב, כי הם לא יודעים שמישהו כבר בנה את זה, אולי בחברה אחרת ואולי אפילו מישהו מהצוות שלהם, ואז הם מתחילים לחפש. הקטלוג מהווה מקום מרכזי שבו אפשר לחפש את כל ה templates  והקומפוננטות הניתנים לשימוש.
הדבר השני, הוא, "שלאחר שכבר מצאתי את התבנית או הקומפוננטה שאני רוצה להשתמש בהם, איך אני עושה את זה?" איך אני משתמש במה שמצאתי ויודע שהוא עושה את מה שהוא צריך לעשות? 

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

Reusability

דבר שלישי, reusability : היכולת להקפיץ את זה, כדי שכל הצוות שלי או אפילו כל העולם יוכל להשתמש בזה.
כמו שאתם רואים, אני ממש רץ לתוצר הסופי להראות איך זה נראה, כי הכי קל לראות את זה בעיניים. 
בגדול, הקטלוג מורכב משני דפים מרכזיים. דף ראשון, index page שמכיל את כל מה שיש לקטלוג להציע, נכון לאותו הרגע.

 ניתן לראות שיש לי 187 קומפוננטות. למעשה, יש הרבה יותר אבל על זה אדבר עוד מעט. אלו הקומפוננטות שאני ואתה יכולים לראות. כל שורה פה, היא למעשה repository שבתוכו יש קומפוננטה אחת או יותר. אני יכול לראות כאן את מספר הקומפוננטות. אני יכול לראות שיש כאן שיש שורה בשם components שאומרת יש בפרויקט הזה 3 קומפוננטות. למעשה, מה שאנחנו רואים זה פרויקטים שמכילים בתוכם את הקומפוננטות. זה האינדקס פייג, שעוזר לגלות מה יש בעולם. לצורך העניין, אם אני עובד על גוגל, ורוצה לראות מה שיש בגוגל, אני לוחץ על גוגל ורואה את מה שמוצע, cloud storage, GKE ועוד. אני רואה שיש לי כל מיני קומפוננטות.
אגב מכל מני מקורות ואנשים. אני יכול למצוא כמה קומפוננטות לאותה מטרה מכמה יוצרים. זה, אני חייב לציין, זה משהו שכולם יכולםי לתרום. אנחנו כן מנסים לאט לעבוד עם —– כדי שאנשים יבינו מה יותר אמין. לדוגמא, כשאנחנו רואים שיש badge שכתוב עליו created and maintained by gitlab partner. יש קומפוננטות שממש יוצרו ספציפית ע"י גוגל, וכשנכנסים רואים שהן של גוגל. אז אנחנו מנסים לעזור, יש עוד קומפוננטות שיוצרו ע"י לדוגמא גיטלאב, נחפש, הנה, זה לדוגמא נby gitlab. ועוד מעט נוסיף פילטרים שתוכלו לסנן, כרגע זה מוצר ראשוני. 

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

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

[תמיר] למי לדעתך זה יותר מיועד, למפתחים או לאנשי DevOps, או לגוף אחר?

[דב] תלוי. יש לנו שתי פרסונות מרכזיות. אחת, אנשי הDevOps, שהתפקיד שלהם לדאוג שיהיה תמיד templates שהמפתחים שלהם יוכלו להשתמש בהם, בתור per service. יש את האדם או הצוות שאחראי לנהל את כל האירוע ושהקומפוננטות יהיו published, ויש את הצד השני של המפתח שרוצה להשתמש ב pipeline, זה המשתמש consumer שמסתכל ורואה מה יש בקטלוג שהוא יכול להשתמש בו. חשוב לציין, שהוא מאוד פופולרי. הקטלוג, יש לו שתי ארכיטקטורות. מה שרואים עכשיו, זה קטלוג שנמצא ב.com, ואנחנו רואים שיש בו 187 קומפוננטות. כמו שאמרתי, תכלס יש הרבה יותר אבל אני פשוט לא רואה אותן. אם אני לקוח של .com, ויש לי קומפוננטה אבל אני לא רוצה שאף אחד יראה אותה חוץ מאנשים ספציפיים בארגון שלי, אני יוכל למצוא את הקומפוננטה בתוך repository מיוחד, לתת הרשאות לאנשים המתאימים. לכן, מה שאנחנו רואים בקטלוג זה רק מה שיש לנו הרשאה לראות.בפועל, אנחנו כן עוקבים אחרי, רק כמות הקומפוננטות, יש לנו בערך 400-500 קומפוננטות published. 187 קומפוננטות הן רק אלה שהן published, ויש עוד 300-400 קומפוננטות שחברות עשו להן published אבל אני לא יכול לראות בלי הרשאה. ההרשאה זה לפי permission שלי, אז אין חשש שתזלוג ותופץ איזושהי קומפוננטה. אם אני אדאג לתת permission מתאים בתוך repository ולעשות published, רק האנשים הספציפיים יוכלו לראות את זה. 

לכן יש את ה-tab הזה של הyour groups, שרק לי יש את ההרשאות אליו. יכול להיות שלעוד אנשים יש את ההרשאות האלה, כי הgroup הזה הוא public, אבל יש לי קשר ישיר לפרויקט כי אני אחד מ members באופן ישיר של הפרויקט. בפרויקטים אחרים אני לא שייך לmembers הם פשוט public. פרויקטים שאני קשור אליהם באופן ישיר, אם הם private אף אחד לא יכול לראות חוץ ממני, והם מופיעים כאן.
Self manage customers גם מקבלים את הקטלוג, אבל הוא יהיה ריק, כי אין לו גישה ל.com. אין לו גישה לשלוף את הקומפוננטות מה/com, נכון להיום.
מה שרוב הארגונים עושים זה לקיים קטלוג פנימי. אם הם עושים dot com הם יכולים לגשת לשם, ואם הם בself manage instance הם יכולים לנהל את זה בצורה פנים ארוגנית, והכול עובד. אפשר לעשות publish למה שאתה והמפתחים שלך יותר, וזו צורה של internal catalog.

[תמיר] אם אני ב-GitLab Self managed , אני יכול לייבא קומפוננטות?

[דב] אפשר לעשות mirroring, אפשר לעשות include דרך remote. ה- best practice אומר שאם אתה self manage costumer אל תתנה את ה—- באישזהו third party, גם אם זה GitLab. יכול להיות outage, אנשים יכולים לעשות שינויים.

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

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

אז דיברנו על הדף הראשון של ה-index page, ונניח שמצאתי את הקומפוננטה הרצויה לי, בדף השני detail page  והוא נותן לי יותר אינפורמציה על ה- repository ועל הקומפוננטות שבתוכו, יש הסבר מפורט שהעמוד מראה לך. יש עוד tab שנקרא components tab והtab הזה משודרג באופן אוטומטי ועוזר מאוד ללקוחות להבין איך להשתמש בקומפוננטות. בגדול, אנחנו רואים פה את הsyntax ואיך לקחת את הקומפוננטה, להעתיק אותה ולהדביק לקטלוג הרצוי, ומה הinput parameters שיש לקומפוננטה. על זה נדבר בהמשך, אבל בגדול זו הדרך להעביר קלטים ופרטמטרים לקומפוננטה. אפשר לראות כאן מה הפרטמטרים, אם יש להם איזה default value ואם חייבים להגדיר אותם באת הקריאה או שהם אופציונלים. אם ממש ניכנס לתוך הקומפוננטה, ניכנס לתוך הrepository, הקומפוננטות תמיד יושבות בתוך template" זו הקומפוננטה ואתם רואים שזו ההגדרה והנה הinputs. אנחנו לוקחים את הדבר הזה ולמעשה מסדרים אותו יפה בטבלה, באופן אוטומטי. כך, בכל פעם שמישהו מעדכן את הקומפוננטה, הוא לא צריך לדווח על זה כי זה קורה באופן אוטומטי. פה אתם רואים ממש את כל הקונפיגורציה של הקומפוננטה עצמה.

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

[תמיר] יכול להיות שהפתרון הזה עוזר לטרנד מהזמן האחרון של לתת פתרון למפתחים שנקרא platform engineering? איזשהו self service משוכלל?

[דב] זו המטרה. שיהיה מאוד קל למישהו פשוט לראות מה יש, גם בתוך הארגון, ופשוט לא לדבר עם ה—— או עם הdevops אלא לבדוק את הקומפוננטות, זה מה שיש לי וככה אני משתמש בהן וזהו. זו בגדול, המטרה. Colllab—- platform, זה הרעיון.

[תמיר] מצוין