סיפור לקוח: רום גייגי מ- Pecan AI מספר על השימוש ב- GitLab ו- GitLab CI
יצא לי לארח את רום גייגי, ראש צוות DevOps מחברת Pecan (ואחד מלקוחותינו) לשיחה קצרה על GitLab ומדוע בחרו להשתמש בו וב- GitLab CI/CD .
השיחה הוקלטה והיא זמינה לצפיה כאן:
הטקסט המלא:
תמיר: אני מארח כאן את רום גייגי, רש"צ DevOps מחברת Pecan AI, שמשתמש ב GitLab
כבר מספר שנים. רום, אני אשמח לשמוע פידבק על GitLab ו GitLab CI .
רום: תודה רבה. קודם כל, GitLab מבחינתי זה מוצר מדהים. היתרון המשמעותי שלו מול המתחרה GitHub הוא בעיקר – hosted self על kubernetes בנוסף כל העדכונים של גיטלאב שיוצאים מגיעים בסופו של דבר ל-Self-managed, מה שמייצר יותר תחושת אבטחה וביטחון,
ונותן לאדם שקט וידיעה שהוא מנהל את הפרויקטים של עצמו, מאחורי VPN. כך אף אחד לא יכול לגשת אליהם ללא הרשאה.
תמיר: זה בעצם נותן לך שליטה מלאה?
רום: כן. אני גם בוחר מתי לעשות את העדכונים. בהתחלה היה מאתגר לעשות אותם, עד שיצרנו לעדכונים אוטומציה שפועלת כל שבוע כדי לבדוק אם יצא עדכון חדש, להריץ tests ולהעביר לproduction – מה שפתר את כל הבעיות.
היום אני אפילו נהנה לעדכן, כי אני מקבל פיצ'רים כמעט בחינם.
תמיר: חמים מהתנור.
בזכות האוטומציה, גם ה Security מתעדכן?
רום: כן. זו הסיבה שהעדכון קורה פעם בשבוע ולא פעם בחודש, כי ה- major releases של GitLab יוצאים פעם בחודש אבל לפעמים יש security patches דחופים שיוצאים בתדירות גבוהה יותר. חוץ מזה, ברגע שאנחנו יצרנו את ה-CI שלנו, בעצם קיצרנו את זמן הגעת הקוד לproduction, וגם פישטנו את היכולת של מפתחים לקחת פרויקט חדש ולהכניס אליו את ה- CI וכך להביא אותו לproduction מהר. כיום, כמעט לכל הפרויקטים שלנו יש את אותם שלבים לכל אורך חיי ה- CI שלהם, בין אם זה commit ,commit for merge request, ,merge train או להוסיף טסטים, מה שמאוד עזר לנו לפני שאנחנו מגיעים ל- production , או בזמן ה- production כשלהוציא גרסה ולעדכן את כל הרכיבים.
תמיר: אז אתה בעצם נותן למפתחים שירות עצמי, Self-service?
רום: אנחנו עובדים היום עם Cookie cutter כך שברגע שמפתח מחליט לייצר service חדש, ה-CI כבר קיים שם, ואם הם רוצים עוד חלקים יש לנו GitLab templates שיושבים ב- repo מסויים, ומי שרוצה יכול להשתמש בהם כדי להוסיף או להוריד עוד stages ל- pipeline שלו.
כך חוסכים הרבה קוד, הרבה ידע שהמפתחים לא באמת היו צריכים. כל מה שצריך זה להעתיק ולהדביק את התבניות שחוזרות על עצמן עבור כל פרויקט.
תמיר: לא צריכים להמציא את הגלגל.
רום: בדיוק. כמעט הכל אותו דבר, זה עוזר לנו מאוד.
בנוסף, בגלל שהכול מרוכז במקום אחד, אם נמצאת בעיה אפשר לסדר אותה באופן רוחבי.
לדוגמא, הייתה לנו בעיה של cache ב-Docker , ובמקום לעבור על כל פרויקט ולתקן אחד-אחד, סידרנו את זה במקום אחד – וקיבלנו את זה בכל שאר המקומות – זה היתרון האדיר של GitLab.
יצאו גם עכשיו components חדשים ל- CI שאני רוצה לנסות ועדיין לא היתה לי ההזדמנות ( CI Catalog).
ל- GitLab יש הרבה tools מגניבים כמו premium, secret detection, סאס ודאס בultimate, לבדוק vulnerabilities ו S bombs שמאוד עוזרים.
חוץ מזה, ה- API של GitLab מאוד נוח, וכל מה שחיכינו לו עד היום מ- GitLab או merge request שפתוחים, היום אנחנו יכולים לעשות את זה לבד בסקריפט פשוט של Bash או Python שסוגר לנו את הפינה. היו לנו בעיות עם לבוא ולהתחיל חוק ל repositories או ל groups.
בGitLab יש Feature Request שפתוח כבר כמה זמן, ולא יכולנו לחכות אז פשוט פיתחנו לעצמנו והגדרנו את ה rules הבסיסיים, בשביל שbranch יכנס לmaster, והחלנו את זה בזכות Cron job פשוט.
תמיר: אני מניח שאתה מדבר על merge request approvals?
רום: כן.
תמיר: יש עוד יכולות ב- GitLab שאתם משתמשים בהם, כמו artifact?
רום: ברור. היום, כל ה- CI pipelines שלנו רצים על תמונות שאנחנו יצרנו, ואנחנו משתמשים ב- registry של GitLab כדי לשמור עליהם כמה שיותר קרוב. זה דבר אחד שאנחנו משתמשים.
אנחנו משתמשים בו, ב- tags ובreleases של GitLab.
בArtifact אנחנו פחות משתמשים היום, אלא מנהלים את זה במקום אחר, אבל בכל התהליך של הוצאת package וזריקתו לכלי הבא, זה הכול ב- GitLab וזה מאוד נוח לניהול.
תמיר: יפה. תודה רבה רום! היה מאוד מעניין.
