מיגרציה מ- Bitbucket אל GitLab בחברת AppsFlyer – הקלטה חדשה מכנס GitLab

לפני כשבוע התקיים כנס GitLab Contribute בסן-פרנסיסקו.

בין הדוברים היה אלעד ליב מחברת AppsFlyer, אותו אירחנו אותו ל- GitLab Meetup שארגנו (והתארחנו במשרדי החברה) לפני כשנה.

חברת AppsFlyer עוסקת בניתוח פרסום במובייל , ולאחרונה גייסו 210 מליון דולר בסיבוב השקעות רביעי.

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

כמפיצים של GitLab בארץ ובעולם, לקחנו את הוידאו, הוספנו כתוביות וכן סיכום לטובת כל מי שירצה לקרוא לצד הצפיה בוידאו.

(וזו הזדמנות להזכיר שישנו וידאו נוסף בעברית שאנו הקלטנו לפני כשנה במהלך המיטאפ. בוידאו בעברית יש פירוט מעמיק יותר של היבטי הארכיטקטורה – וניתן לצפות בו כאן).

לצפייה מיידית:

(ניתן להגדיל למסך מלא בלחיצה על הכפתור השני מימין בסרגל הכלים)

הנה הסיכום :

המצב שהיה בעבר בחברה:

• התחילו עם Bitbucket Cloud (ענן) ועם Mercurial , כירושה הסטורית מאז הקמת החברה.
• לא רצו להשאר בפתרון בענן ציבורי , שחשוף לנפילות DDOS והפיכת הקוד הקנייני שלהם לפתוח בקלות
• רצו פתרון מאחורי VPC
• סבלו מבעיות latency שנגרמו בגלל Bitbucket
• ביטבאקט הגיע כ "קופסא שחורה" – ואם משהו לא עבד בו, לא ניתן היה לדעת האם זה בגלל המוצר עצמו או בגלל הקונפיגורציה – זה הרגיש להם כקופסא שחורה.

בהתחלה ניסו GitHub Enterprise ולא רצו – כי מגיע כמכונה וירטואלית (VM) כ"קופסא שחורה" שלא ידוע מה יש בה; המחיר היה גבוה מאוד , וכן התרשמו שהחזר ההשקעה (ROI) יהיה מאוד נמוך.

לבסוף בחרו ב- GitLab.

למה GitLab  ?

• בגלל הבשלות של המוצר ועושר הפיצ'רים
• בגלל התפתחות המוצר והגדילה בכמות הפיצ'רים וכמות המשתמשים והלקוחות בעולם
• המוצר ה-  "DevOps-י " הכי נחמד
• שקיפות – הכל שקוף כברירת מחדל : הפיתוח, הקוד , תהליכי הפיתוח, הדיונים ועוד

נקודות שלקחו במהלך תכנון המיגרציה:

• תמיכה ב- API   כדי לתמוך באותם תהליכים שכבר בנו
• ארכיטקטורה שתתמוך בגדילה לצד גדילת החברה
• איך מחנכים את המשתמשים לעבוד עם המוצר החדש?
• האם יש לנו מספיק כלים לתמוך במיגרציה?

לאחר בחינה – הגיעו למסקנה שבכולם GitLab עמד בהצלחה

מיגרציה:

• רצו לשמור את כל ההסטוריה, כולל כל ה- commits וה- tags
• בנו tool בעצמם – שמעביר את כל ה- repo אחת-אחת . כלי קל לשימוש ובטוח לשימוש (לא דורס). נתנו לבעלי ה- repo להעביר בעצמם (self-service).
• שמרו על שקיפות לאורך התהליך כדי להשיג אמון  של המשתמשים . הסבירו איך עובד התהליך , מה צפוי, מתי סוגרים את ה- repo הישנים וכו' (הגדירו deadlines), ומה היתרונות הצפויים ב GitLab .

הקפידו לתעד את הכל כדי שהכל יהיה ידוע וברור:

• איך עושים את המיגרציה
• איך עובדים עם הכלי החדש
• איך יעבדו התהליכים לאחר מעבר לכלי החדש
• בעיות שעלולות לצוץ (troubleshooting)

גם ניצלו את ההזדמנות לעשות קצת נקיון ולהעיף דברים לא נחוצים.

אלעד המליץ על כלים:

• כלי שעוזר במיגרציה (fast-export)
• השתמשו גם באתר הזה https://ohshitgit.com/ – הרבה טיפים ומקרי קצה כשמשתמשים ב- git CLI  ואיך לפתור זאת

ארכיטקטורה:

• השרטוט מוצג בוידאו בדקה 13:00
• הארכיטקטורה עושה שימוש ב-  Route 53, HashiCorp Consul, S3, GCP, AWS, Redis
• אלעד הדגיש כלל ידוע: הקמת backup ללא נסיון שחזור לא נחשב backup !!!
• כיום הם מבצעים גיבוי שעתי
• הם בנו גיבוי ל- 2 עננים כך שהם cloud-agnostic ויכולים להרים סביבה מהר אם אחד העננים יושבת.

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

Self-Serving & Tooling

ציין שבנו כמה כלים לצורך המעבר ולנוחות בעבודה השוטפת

• בנו כלי שבדק אילו repos עברו – ושלח התראות אם מצא כאלה שטרם עברו!
• בנו רשימת shame list לכאלה שטרם עברו – כדי לדרבן אותם לעבור כבר
• בנו API Wrapper שתפקידו לזהות כפילויות קוד ולספק מעטפת מעל ה – API  של GitLab ע"מ לתת גישה מרכזית ל- meta data שמפתחים צריכים בעבודה השוטפת.

עשו שימוש נרחב ב-GitLab Hooks  – אלעד ציין לטובה את עושר האפשרויות הניתנות ואת המבחר הגדול של הדברים שניתן לעשות באמצעותם.

לסיום – סיכם ששנתיים לאחר המעבר הכל עובד יפה וממשיך לנגן. במשך הזמן הם מצאו שני באגים ב- GitLab . לאחד הם מצאו מעקף והשני נפתר ע"י חברת GitLab .

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

• הקלטת הרצאה של אלעד ב- AppsFlyer בעברית (כוללת שקפים והסבר מורחב יותר על ה- deployment שבנו והארכיטקטורה)
• אתר מידע על GitLab בעברית