סיפור לקוח: Thomson Reuters מציגים את תהליך הפיתוח שלהם המשלב Jenkins, GitLab ו- Slack

לפני כמה שבועות קיימנו וובינר הדרכתי על GitLab, ובמסגרתנו אירחנו את מתן קידר מ- Thomson Reuters, משתמש מרוצה של GitLab, להצגת תהליך העבודה אצלם בחברה, הכולל את GitLab, Jenkins ו- Slack.

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

הדובר: מתן קידר מחברת Thomson Reuters. החברה עוסקת בפיתוח טכנולוגיה של עיבוד שפה טבעית  (NLP).

צורת השימוש ב- GitLab כפי שמשתמשים בחברה:

• שימוש ב- Source Control
• שימוש ביכולות ה- Merge Request וה- Code Review
• שימוש ב- Issue Tracking עבור ניהול משימות פיתוח ובאגים
• שימוש ב- Issue Board כדי לראות בקלות את הסטטוס של כל משימה:
  
• אינטגרציה עם Jenkins בכדי לממש CI/CD כחלק מתהליך הפיתוח
• אינטגרציה עם Slack כדי לקבל עדכונים לחדר Chat משותף

תהליך העבודה:

1. משתמש פותח issue חדש (של משימת פיתוח או באג שהתגלה)
2. מפתח לוקח על עצמו את מימוש ה- issue (דהיינו פיתוח המשימה או תיקון הבאג)
3. כאשר המפתח מרגיש שהקוד שמימש מספיק בשל, הוא פותח merge request
4. מישהו אחר מהצוות (או יותר מאחד) עושה code review על הקוד החדש
   במקביל – Jenkins מורץ לאחר פיתחת ה- merge request, ומריץ build ובדיקות
5. במידה והקוד עובר את הבדיקות של אנשי הצוות האחרים וגם עובר את הבדיקות של Jenkins – הקוד החדש ממוזג ל- master branch

הערות:

• קוד ממוזג ל- branch העליון רק לאחר שעבר את כל הבדיקות בהצלחה
• Jenkins מורץ ברגע שפותחים Merge Request (מורץ build עבור כל MR בנפרד)
• ג'נקינס משמש למעשה כאחד מחברי הצוות
• ג'נקינס עושה deploy לקוד החדש שמוזג (לאחר שאושר ומוזג)
• גם GitLab bot (כפי שהוא מוגדר ב- Slack – כפי שניתן לראות בצילום המסך להלן) נחשב כחבר צוות, ומדווח על:
  • • פתיחת issue חדש
    • Merge Request חדש במערכת
    • Merge Request שאושר (ומוזג)
      
• Merge Request הוא המונח המקביל ל- Pull Request (למי שמכיר זאת מ- GitHub ו- BitBucket)
• לחילופין, כדאי לדעת ש- GitLab מגיע גם עם כלי CI/CD וכלי ChatOp פנימיים, שאפשר להשתמש בהם כחלק בלתי נפרד מהמערכת.

תכונות שהמשתמשים אוהבים במערכת:

• האפשרות לייצר ולהשתמש בתבניות מוכנות של כאשר פותחים issue . אפשר לשלב אותן בקלות עם markdown, שהופך את הטקסט לקריא יותר וליפה ויותר
• קלות השימוש ב- Issue Tracking שמגיע built-in ב- GitLab
• חברי הצוות יותר מודעים למה שקורה בפרוייקט – גם ברמת הקוד – וזה בזכות ה- Merge Request . כל קטע קוד חדש עובר בדיקה של עוד זוג עיניים.

לסיכום – מה השיגו בחברת Thomson Reuters כתוצאה משימוש ב- GitLab:

• יותר שיתוף ידע בין חברי צוות הפיתוח
• קוד איכותי יותר (שממוזג לאחר בדיקות אוטומטיות + בדיקות code review של חברי הצוות)
• קישור בין issues ל- MR (לקוד – דרך commits). זה  מאפשר לקשר בין ה"ביזנס" לניהול הפרוייקט
• תהליך הפיתוח הפך למסודר יותר
• יותר מוּדעות למצב הפרוייקט בכל רגע נתון

והנה הקלטת סיפור הלקוח. זמן הצפיה: 11 דקות

[עדכון 12/06/2017] הקלטה של סיפור הלקוח באנגלית, במסגרת אירוע GitLab למנהלי פיתוח ו- DevOps שאירגנו:

מידע נוסף:

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