סיפור לקוח: על השימוש ב- GitLab בחברת AT&T

• במסגרת מפגש שארגנו מוקדם יותר החודש, אירחנו את דני אלינסון מחברת AT&T,
  שהציג את חווית השימוש שלהם ב- GitLab .

צילמנו זאת בוידאו הבא- ויש גם תמלול של הדברים שנאמרו (בהמשך המאמר).

)

תמלול:

[דני אלינסון מ-AT&T]
במסגרת הרבע שעה שיש לי אני אנסה לשתף אתכם בחוויה שלי כלקוח של GitLab.
אני בעצם כ-20 שנה בתחום של ה-source controls. מכיר הרבה source controls שונים, של Microsoft, של IBM. רוב השנים התעסקתי עם ClearCase.
ב-6 שנים האחרונות אני ב-AT&T לפני זה עבדתי ב-IBM, Comverse, Technomatics, Nokia Siemens, וב-6 שנים האחרונות אני ב-AT&T.

כשהגעתי ל-AT&T אז באמת הכלי המרכזי שם היה ClearCase,
ועם הזמן ראינו דרישה שמגיעה מלמטה מאנשים שרצו כלי קצת יותר מהיר,
יותר טרנדי והתחילו לצוץ כמו פטריות אחרי הגשם קבוצות וצוותים שמרימים לעצמם כל מיני שרתים פיראטיים, אחד מנסה Subversion, אחד מנסה מנסה להרים git.
כל אחד ששמע משהו באינטרנט מנסה להרים בעצמו.
מהר מאוד הבנו שאנחנו צריכים לקחת שליטה על הדברים האלה ולהרים כלי מרכזי תחת צוות ה- ALM,
שירכז את הדברים כדי שהדברים יהיו מסודרים, ומגובים בצורה מאוד אחראית.

ההתחלה עם git

הכלי הראשון של גיט שניסינו היה Gitolite. זה כלי lightweight חינמי שניסינו אותו וראינו שהוא נחמד, אבל
עם הזמן התעורר צורך ביותר פיצ'רים, ולתמוך ביותר מגזרים. מדובר בחברה גדולה, במאות עובדים, מאות פרויקטים, אז אתה באמת צריך כלי שיהיה חזק ושתיהיה חברה טובה מאחוריו.
בימים האלה, 2012, היה צריך לשכנע את ההנהלה שגיט זה משהו שמתאים ל-enterprise,
ועד היום יש חברות כאלה שצריך לשכנע אותם. בדבר הזה.
מה שהתחלתי… אני עוד מהימים האלה שלהתקין את GitLab זה היה בחלקים, היה לפי הוראות. היום ההתקנה הרבה יותר פשוטה וקלה ובעזרת קונטיינרים. זה one-click ששואלים שאלות, וזה מתאים.

סביבת GitLab

אני אשתף אתכם בסביבה שיש לנו, זה  מכונת VM  עם RedHat 6, הוא פלקסיבילי במובן שאם צריך להגדיל את ה-memory, ואת ה-CPU אז זה מה שעשינו, התחלנו בכמות מסוימת של cores, ושל memory, ועם הזמן ראינו שיש יותר ויותר יוזרים, יותר ויותר פרויקטים, הלכנו ל-IT ואמרנו "וואלה, תכפילו לנו את ה-CPU, תכפילו לנו את ה-memory"
ובאמת באתר של GitLab יש טבלה כזאת שכתוב מה הדרישות מערכת, וזה בסדרי גודל,
אם אתם מכפילים את ה-memory ואת ה-CPU אתם יכולים לתמוך במקום ב-100 יוזרים – לתמוך ב-1000 ו-10,000 יוזרים וזה מה שראינו בפועל, שהשרת מאוד מאוד סטבילי ואמין.
כמעט ולא נתקלנו במצבים כמו downtime.

פיצ'ר מאוד חזק ב- GitLab זה ה- monitoring, שמאפשר ויסות ומעקב אחרי יוזרים.
יש לפעמים יוזר נודניק שתוקף את השרת בצורה חזקה עם קבצי ענק binaries,
אתם יכולים לעקוב אחרי הדברים האלה ולעלות על זה מהר.
מבחינת הוקים (hooks), אין תחליף לזה שהכלי יושב אצלכם, אין סכנה של downtime ברשת,
כמו שיש ב- GitHub בענן למשל.

Security ואבטחת מידע

Security : יש הרבה חברות שצריכות שהשרת ישב אצלם מאחורי ה- firewall שלהם,
אז אין תחליף לזה שהשרת יושב אצלכם ואתם יכולים לשלוט ב- hooks.

אני כתבתי הוקים שאתם יכולים לשלוט ב- comments, בפורמט של הקומנטים, של היוזרים, אתם יכולים לשלוט ב-file size אתם לא רוצים שאנשים ידחפו כל מיני binaries ודברים ענקיים כאלה אתם יכולים לשלוט על הדברים האלה. יש קסטומיזציה פר פרויקט, והשרת באמת יציב.

ואיך אנחנו יודעים שהוא טוב? אנחנו רואים באמת שאנשים כשיש להם את הבחירה…
AT&T היא חברת ענקית, אין לה בעיית תקציב כשיש 2 חברות גדולות שמתחרות אחת בשנייה, AT&T אין לה מגבלת תקציב. היא לא מתלבטת, היא פשוט קונה את שתיהן.
אז יש בחברה גם GitHub, גם GitLab, גם Atlassian Bitbucket,
ובאמת הבחירה המועדפת ע"י יוזרים כשהם צריכים לבוא ולבחור משהו זה GitLab שלנו, גיטלב שיושב בדומיין שלנו, ומה הסימן לזה?
הסימן לזה שיש לנו הסכם שירות איתם, לא ניכנס לפרטים זה כבר עניין של מו"מ כל חברה תעשה את ההסכם שלה, אבל אחת לשנה אנחנו עוברים על רשימת היוזרים,
מעיפים יוזרים שעזבו את החברה או לא פעילים, ככה מיישרים את המספרים ואנחנו רואים איך בזמן מאוד קצר כמות היוזרים עולה. באמת המספר חוזר להיות גבוה. אנשים תמיד חוזרים לשרת הזה.

תמיכה ב- LDAP וב- Active Directory

פיצ'ר שאנחנו מאוד אוהבים ומשתמשים בו זה העניין של התמיכה ב- LDAP (ו- Active Directory)
וגם תמיכה ביוזרים רגילים שזה לא LDAP והשילוב ביניהם.
מצד אחד אתה צריך כן LDAP להיות כפוף ל- policies של ה-IT, מצד שני אתה רוצה להמציא יוזרים יוניקים שלך,
שה-password שלהם לא expired, שאתה יכול לאפשר כניסה מבחוץ, מחוץ ל-firewall,
במקום שאנחנו נשתמש בשירותים של האמריקאים כל הזמן.
הרבה פעמים יש יוזרים אמריקאים שנכנסים מבחוץ ל-firewall שלנו, יש לנו ב- firewall פורט 443 שפתוח, ומאפשר כניסה בפרוטוקול HTTPS  ל- GitLab ואנחנו באמת רואים שזה שימושי ואנחנו שולטים ברמת ה-permissions של היוזרים האלה, זה דבר נוסף שגיטלב מאפשר.
זה לא רק יוזר שהוא read-only או read-write יש פה המון רמות שונות של permissions
אם זה guest, reporter , developer, master — זה משהו מאוד פלקסבילי שיכול לתת פה התאמה לכל צוות.

Merge Requests

דיברנו על Merge Request (שקול ל- Pull Request) ו-Issues אז כל צוות מממש בדרך שלו את העניין הזה.
יש אנשים שנועלים את ה-branch master, ויכול להיות לך רק יוזר אחד שהוא מאסטר בצוות, הוא זה שמותר לו לעשות accept ל-merge request, ויש קבוצות שמעדיפות שזה יהיה פתוח וכל היוזרים יכולים לעשות accept ל-merge request.
כמובן לא כולם משתמשים בכל הפיצ'רים , יש קבוצות שמעדיפות לפתח ישירות כבר על ה-branch המרכזי,
ככה הם מקבלים פידבק יותר מהיר, יותר אג'ילי בצורה הזאת.

Web Interface

דברים נוספים שיש לנו: יש לנו web interface מאוד חזק. כל העניין של עריכה מה-web. נושא ה- commits באמת זה משהו חזק.
האצלת סמכויות, יש פה הרשאות לפי קבוצות, לפי פרויקטים, זה משהו מאוד טוב.

אנחנו התחלנו בגרסה 5 עברנו ל-6  אח"כ עשינו upgrade ל-7 . בכל שלב כזה היינו צריכים סוג של שיתוף פעולה [מהיצרן], למרות שאת רוב הדברים ברמה הטכנית אנחנו יודעים לעשות, בתכלס מי שקצת חזק טכנית יכול להרים לעצמו יופי של שרת git.
אבל עדיין, כשאתה בא לחברה אתה רוצה שיהיה מאחוריך חברה חזקה וגדולה שאתה יכול להגיד "זאת חברה שנותנת לי שירות" ובאמת כל הרושם שלי מהאינטראקציה מול ההנהלה של GitLab
בנושא של מתן שירות ו-support זה משהו יוצא מן הכלל.
כל פעם שהייתי צריך משהו, לשאול שאלה, אותו בנאדם בהולנד או בסן פרנסיסקו, איפה שהוא יושב,
התגובה היתה מאוד מהירה והוא היה קם ב-6 בבוקר כדי לתת לי מענה.

הרבה פעמים הם פנו אליי, לראיין אותי איך אני עובד כי מאוד עניין אותם באמת צורת העבודה שלי, וככה ללמוד מזה כדי לפתח את הדברים שלהם.
ובאמת אתם רואים כל 22 לחודש, כמו שעון, יוצא להם Release Notes עם גרסה חדשה של תיקוני באגים ופיצ'רים חדשים, באמת יש הרגשה כאילו אתם נכנסים למועדון,
אתם התחלתם להיות משתמשים של GitLab, יש פורומים, זה לא סתם שב- Stack Overflow רואים את הפעילות הזאת כי באמת אתם כאילו חלק ממועדון, זה משהו שלא מרגישים בכלים אחרים.

הזכרתי כבר פלקסביליות, אם אנחנו משווים את זה ל- Gerrit. גריט הוא מאוד strict. הוא יודע להתמודד יפה עם commit אחד, עם Push אחד, ברגע שזה מתחיל להיות קצת יותר מזה זה פחות מנגן, יש לנו גם משתמשים כאלה, והם מתלוננים כל הזמן, פה GitLab באמת, אתם בסוף מחליטים באיזה צורה הקבוצות יעבדו.

המעבר מ- ClearCase ל- GitLab

[שאלה מהקהל] תוכל לספר על על המעבר מ- ClearCase ל- GitLab ?

AT&T השקיעה המון ב- ClearCase. זו אחת החברות אם לא מספר אחת בארץ מבחינת התשתיות, שהשקיעה כסף מבחינת שרתים, Solaris .
יש שם ארונות שלמים של ClearCase הם עשו שם פרויקט מאוד רציני ב-ClearCase מבחינת תשתיות,
ואני בתור איש של ClearCase אין לי מילה רעה אחת להגיד על ClearCase –
זה אחלה כלי, אבל זה שני דברים שונים באמת, זה דווקא חוזקה של חברה שיש לה שני כלים.

על מעבר בין כלים ומיגרציה

אם אתה שואל על migration, על מעבר מ-ClearCase יצא לי לעשות לא מעט migrations כאלה, גם בחברות שונות, מה שחשוב לשים פה לב זה על שיתוף פעולה.
לשתף פעולה עם אנשי המפתח שזה פרודקט ו-development, זה חשוב מאוד לתאם את השעות, ושזה לא יעלה להם על גרסה מסוימת.
הכי טוב זה להתחיל מהפרויקטים הקטנים, להתחיל מהפרויקטים בסדר גודל קטן-בינוני.
הרבה פעמים אם יש אפשרות להשאיר legacy, להשאיר ב-ClearCase, בכלי הישן, וגרסאות עתידיות חדשות לקחת את ה-snapshot האחרון של הסורסים, ובצורה פשוטה לעשות להם import לגיטלאב, ליצור יוזרים, לתת איזה זמן ביניים כזה.
לפעמים יש צורך לתפור "סקריפטולוגיה", לפעמים יש קצת עבודה במקביל,
איזו תקופת ביניים שאומרים שחלק מהפיתוח עדיין ימשיך ב-ClearCase למשל infra, כל מיני infra למינהם עדיין ממשיכים ב-ClearCase בוא ניקח את ה-latest ונעשה איזשהו סקריפט שישתול את זה באיזשהו branch בגיטלב, שאנשים יוכלו לקחת את זה אליהם, לעשות merge משם אז כל מיני פתרונות מהסוג הזה שמתאימים.

לסיכום + טיפים:

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

אתה בא לחברה שהמון שנים עם ClearCase, ואתה קצת חושש משינויים ואתה רואה שאת כל השנים הארוכות שהם עבדו ב-ClearCase אפשר לכמת לעניין של מספר שבועות, מספר חודשים שאני חושב ש-90% ומשהו מהחברה פשוט עוברת לגיטלב.

תודה לדני!

פרסום ראשון: 24/5/2017

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

• עמוד GitLab בעברית
• אתר GitLab עם מידע טכני