תהליך הפיתוח עם GitLab – חלק א'

Getting your Trinity Audio player ready...

GitLab היא מערכת מבוססת web הבנויה מעל Git, ומאפשרת יכולות ניהול קבצים וגירסאות, ניהול ומעקב אחר משימות, הרצת בניות ובדיקות ועוד. בשונה מכלים אחרים המשלימים את Git (דוגמת GitHub ו- BitBucket), זוהי מערכת הבנויה בקוד פתוח.

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

המאמר יחולק לשני חלקים:

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

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

המאמר מבוסס חומרים מאתר GitLab ומנסיון אישי של עבודה עם המוצר אצלנו בפיתוח מוצרים שלנו בחברת ALMtoolbox.

קריאה מהנה.

GitLab Flow

ה- FLOW הוא תהליך משלב הרעיון עד שלב ההבאה ל- production, והוא בעצם מייצג תהליך פיתוח נפוץ ומקובל בפיתוח תוכנה. התהליך מבוסס Git בחלקים של ה- version control ובחלקים נוספים.
מטרת התהליך שיוצג הוא שקבוצת הפיתוח תעבוד בצורה אפטיבית – גם מהירה וגם איכותית.

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

הסבר על השלבים בפיתוח:

1. רעיון (IDEA): בד"כ נהוג לדון בכל רעיון חדש. לצורך זה (וביחוד אם אתם צוות מבוזר שלא יושב במקום אחד), ישנו הכלי Mattermost שמגיע יחד עם GitLab (החל מגירסא 8.13) . זהו כלי הודעות /צ'אט (ChatOp) בקוד פתוח וחינמי. לחילופין ניתן להשתמש ב- Slack (הנפוץ יותר), ולחבר אותו ל- GitLab (ישנה אינטגרציה מובנית ב- GitLab).
2. משימה (ISSUE): לאחר פיתוח הרעיון, הגיע הזמן לחלק אותו למשימות ולשתף בכך את אנשי הצוות כמו גם אנשים חיצוניים. לצורך כך ישנו ה- Issue Tracker. לחילופין ניתן גם להשתמש ב- JIRA או בכלים דומים (לחלקם אינטגרציה מוכנה. ניתן גם לפתח אינטגרציה מאחר ול- GitLab ישנו API עשיר).
3. תכנון ותעדוף משימות (PLAN): לשם כך ישנו ה- Issue Board (עם דוגמאות בהמשך). גם כאן, בדומה לסעיף הקודם, ניתן להתממשק ל- JIRA , ל- Taiga או לכלים דומים (בין אם הם תומכים ב- Agile או לא).
4. שלב כתיבת הקוד (CODE).
5. שלב ביצוע commits למערכת בקרת תצורה: GitLab מבוסס על Git כידוע, כך שניתן להשתמש בכל היכולות של Git (אם אתם כבר עובדים עם Git, אתם יכולים להמשיך להשתמש בו באותו אופן בו אתם כבר עובדים כיום). בנוסף, מקבלים את היכולות הנוספות של GitLab, כגון הממשק המעוצב יפה, הגנה על ענפים (branches), הפעלת hooks כאשר מתרחשים אירועים במערכת, ועוד ועוד.
6. בניה ובדיקות (TEST). ניתן להשתמש ב- GitLab CI שמציע יכולות עשירות של Continuous Integration, והכל מאותו ממשק ועם אינטגרציה מובנית לקוד ולמשימות.
   לחילופין – אם אתם משתמשים ב- Jenkins, ניתן לחבר בינו ל- GitLab בצורה יפה.
7. סקירת הקוד (REVIEW): כאן יש יכולות מתקדמות של Code Review והשוואת קוד; ניהול Merge Requests (הדומים ל- Pull Requests בכלים אחרים) ועוד.
8. שלב ההיערכות (STAGING).  זה הזמן להעביר את הקוד לסביבה מתאימה (יכולה להיות גם סביבת אינטגרציה או סביבת QA) כדי לבדוק שהכל עובד לפי התכנון (ולתקן מה שצריך). למעשה, GitLab מאפשר מימוש של Continuous Integration \ Delivery \ Deployment מתוך ממשק יחיד ומשותף (החל מגירסא 8.10) – זהו דבר ייחודי ל- GitLab.
9. השלב המבצעי (PRODUCTION): כאשר כל הבדיקות הסתיימו בהצלחה והכל עובד כפי שצריך – זה הזמן להעביר את הכל לסביבת ה- production (לעתים נקראת גם סביבה מבצעית או סביבת ייצור). ב- GitLab ניתן לעשות זאת כפי שמתואר בסעיף הקודם
10. ולבסוף – איסוף פידבק (FEEDBACK) ותחקור. זה הזמן להסתכל לאחור בצורה רטרוספקטיבית ולבדוק מה עבד טוב ומה טעון שיפור. לצורך כך ישנו ב- GitLab כלי בשם Cycle Analytics המאפשר לדעת כמה זמן הושקע בכל שלב בתהליך הנ"ל.

הערות:

• התהליך הוא כמובן מחזורי, וכמובן יתכן ויהיו כמה איטרציות של ביצוע שלב מסויים לפני מעבר לשלב שבא אחריו. תדירות התהליך והקצב שלו, קשורים בין השאר לתהליכי הפיתוח דוגמת Agile \ SCRUM\ Waterfall , ומשתנים מארגון לארגון.
• בחברות מסויימות יתכן סדר שונה של התהליך. יתכן גם שחלק מהשלבים לא יהיו בתהליך שמאמצת החברה.

כעת אעבור לסקירה על הכלים שמגיעים עם GitLab לצורך תמיכה בתהליך הנ"ל.

GitLab Issue Tracker

מערכת GitLab מציעה כלי לשיתוף רעיונות ומשימות (לשימוש אישי / צוותי / ארגוני או אפילו לשיתוף אנשים מחוץ לארגון). הנה צילומסך לדוגמא:

פתיחת Issue , המייצג רעיון או משימה, היא דרך מצויינת לפתח רעיון חדש ולעקוב אחריו בהמשך הדרך. הדבר שימושי גם עבור:

• שיחה על אותו רעיון (ניתן להזמין אנשים להשתתף בדיון ע"י mentioning@ – בדומה לפייסבוק ולינקדאין)
• להציע רעיונות לפיצ'רים
• ניהול משימות
• הכנסת קטעי קוד לתוך השיחה במסגרת ה- issue (אפשרי ע"י GitLab)
• לשאול שאלות / לדווח על באגים / לבקש סיוע (תמיכה)

כל פרוייקט ב- GitLab מציע Issue tracker.

GitLab מציע ממשק פשוט נוח לכתיבת משימות ולשיתוף משימות. ניתן למשל להשתמש ב Markdown כדי להדגיש טקסט, כדי להגדיר רשימת To-Do פנימית ל- issue כלשהו (כולל צ'קבוקסים) ועוד.

להלן דוגמא למסך יצירת Issue. הסברים על השדות מייד לאחריו:

ה- Issue tracker מציע כמה שדות שימושיים:

• סימון ה- issue כסודי (ל- GitLab מערכת הרשאות פנימית. סימון הכפתור אומר שיוכלו לצפות בו רק משתמשים עם הרשאות Reporter ומעלה)
• תאריך הגשה / סיום (due date). ניתן גם לאגד כמה משימות יחד לתאריך אחד משותף, ע"י שימוש ב- milestones (הסבר מפורט ודוגמאות יגיעו בחלק ב').
• הקצאת המשימה למישהו ספציפי (assignee) שיהיה אחראי עליה. הוא בתורו יכול להעביר זאת למישהו אחר, וחוזר חלילה. השדה שימושי גם לביצוע סינון מאוחר יותר (למשל: לראות את כל המשימות שמוקצות עבורי או עבור חבר צוות מסויים)
• labels: ניתן לשים תגיות שמאפשרות לקשר את המשימה לנושא מסויים, למצב מסויים, לגירסא מסויימת וכד'. ניתן להקצות labels איך שרוצים, ולהקצות לכל אחד צבע שונה.החל מגירסא 8.13 (שיצאה באוקטובר האחרון) ניתן גם להקצות group labels – מה שמאפשר לשתף תגיות בין כמה פרוייקטים שונים (ולחסוך את היצירה שלהם לכל פרוייקט בנפרד – מה שגם מונע טעויות אנוש)
• משקל (weight): זהו שדה שמיועד לניהול תעדוף, חוּמרה של תקלה; ציון /משקל לקושי היישום וכד' . ההגדרה של משמעות כל משקל היא פנימית בין המשתמשים (ניתן כמובן להגדיר זאת במערכת).

GitLab Issue Board

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

בלוח יש רשימות (בהתאמה ל- labels המוגדרים). בכל רשימה מוצגים ה- issues המתאימים לה. כל issue מוצג ככרטיס. ניתן גם להזיז (drag and drop) את הכרטיסים בין הרשימות (מה שגם יעדכן את ה- labels בהתאם).

בלוח יש גם פילטרים שניתן להפעיל ע"מ לצמצם את כמות המשימות המוצגת.

הנה הדגמה קצרה כיצד הוא נראה:

החל מגירסא 8.13 שיצאה באוקטובר, ובגירסא הארגונית בלבד, ניתן גם להשתמש ב- Multiple Issue Board לכל פרוייקט. הדבר מאפשר לארגן משימות ע"פ תהליכים שונים. למשל: ניתן ליצור לוח אחד לכל הארגון, ולוח נוסף המיועד רק עבור צוות UX. כאשר מזיזים או מעדכנים issue כלשהו שמופיע בכמה לוחות, הוא יעודכן אוטומטית בכל הלוחות.

להלן הדגמה קצרה:

 

עד כאן חלק א'.

בחלק ב' שיצא בשבועות הקרובים, אפרט על יכולות ה- Review, על יכולות הבניה והאינטגרציה הרציפה ועוד. ניתן להירשם לרשימת התפוצה שלנו כאן כדי לקבל מייל כאשר יצא חלק ב')

מערכת GitLab מבוססת קוד פתוח, ומגיעה בגירסא חינמית או בגירסא ארגונית (Enterprise Edition) במחיר נמוך, הכוללת תמיכה מהיצרן ויכולות רבות נוספות (החל מ 39$ לשנה למשתמש).

מידע נוסף על GitLab ניתן לקרוא באתר שלנו כאן.

על הכותב: תמיר גפן הוא המייסד של ALM-Toolbox ובעל רקע ב- ALM , בניהול תצורה ובניהול שינויים, ב- DevOps, תכנון תהליכי פיתוח תוכנה ואדמיניסטרציה של מערכות הפעלה.

חברת ALM-Toolbox היא המפיצה הרשמית של GitLab בישראל, ומתמחה במתן שירותי יעוץ ל- GitLab , וביניהם:

• תכנון מערכת GitLab והטמעתה בשרתי הארגון, בענן פרטי או ציבורי
• סיוע בהתאמה בין תהליכי הפיתוח בארגון לבין התהליכים המוצעים ב- GitLba
• אינטגרציה לכלים משלימים דוגמת  Taiga , JIRA , Jenkins ועוד
• פיתוח אינטגרציות ותוספות מותאמות לצרכי הלקוח
• הדרכות GitLab ו- Git
• יעוץ לגבי רישוי

ניתן לפנות אלינו במייל או טלפונית (072-2405222) ולקבל רשיון התנסות ל- 30 יום ל- GitLab .

המאמר פורסם לראשונה ב-2 לנובמבר 2016