הדגמה: תהליך פיתוח משולב GitLab ו- Taiga

בתקופה האחרונה ישנה התעניינות גוברת בכלי ניהול משימות אלטרנטיביים  ל- Jira העובדים על שרת פרטי (on-premises) ו/או בענן, ומתחברים ל- git או ל- GitLab.
אחד הכלים שיכול להתאים לכך הוא Taiga – מוצר שאנו תומכים בו ומשמשים גם כנציג הרשמי של היצרן בחו"ל ובישראל (היחידים בישראל).

במאמר להלן אדגים flow בסיסי, המשלב בין שני הכלים.
זהו flow טיפוסי, הניתן לשינוי. בחרתי תהליך בסיסי כדי להמחיש את החיבור ביניהם.

איך יראה תהליך העבודה יחד?

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

הצעה לתהליך עבודה המשלב GitLab ו- Taiga (לחצו להגדלה)

הסבר לתרשים:

החלק הסגול (העליון) הוא האיזור הקשור לניהול המשימה , ומבוצע ב- Taiga. השתמשנו ב- flow המגיע כברירת-מחדל של משימה מסוג Story

Ready –> In Progress –> Ready for test –> Done

(הכלי תומך באפשרות לשנות את שמות המצבים ואת ה- flow).

טבעי שהמשימה תועבר בין כמה משתמשים בתפקידים שונים – כגון מפתח ובודק.

החלק הצהוב שייך למפתח, ומפעיל פעולות של git ו- GitLab  (ובעקיפין גם של Taiga ו- GitLab CI/CD).

האיזור התכול מבוצע מתוך עמדת המפתח (אפשר לחילופין גם לבצע ישירות מה- browser באמצעות WebIDE של GitLab )

החלק התחתון הוא איזור ה- CI/CD שמבוצע ע"י GitLab runner (לרוב באופן אוטומטי, לאחר שבונים קונפיגורציה מתאימה)

הסבר לתהליך המוצג בתרשים:

1. The group leader creates a Story in Taiga to develop a feature (or a Bug to fix a bug) and assigns it to a developer. Story is now in Ready status.
2. The developer starts working. He moves the task to In Progress status, then creates a git branch and clones or pulls the repo to his workstation (he can also works direct on the browser using GitLab's WebIDE).
3. After the feature is developed/the bug is fixed, the developer pushes his work to the GitLab server, which triggers a CI pipeline.
4. If the pipeline succeeds, the developer creates a Merge Request, thus starting a code review.
5. As a result of the code review, the developer may be requested to do a number of changes before the Merge Request is merged, with each change triggering a CI pipeline.
6. At last, the Merge Request is merged into the master branch, and again a CI pipeline runs to check the merge result.
7. Now it's time of the QA tester to make sure everything is OK. He moves the status to Ready for test.
8. Some changes may be needed on the master branch, after which the software is marked as a new baseline and a CD process has finished successfully – it's time to mark the story as Done.

זכרו שלתרשים המוצג כאן יכולים להיות הרבה וריאציות. אנו הצגנו כאן משהו ראשוני שיכול להיות בסיס להתחלה ולשינויים.

לסיכום:

• ניתן לחבר בין Taiga ל- GitLab . ניתן אף לחבר אותם ל- GitLab CI/CD לצרכי אוטומצית בדיקות/בניות/הפצה
• גם ניתן לשכלל את האינטגרציה ולפתח אוטומציות ל- use cases ספציפיים (למשל הוספת קישור אוטומטי ב- Taiga כאשר מציינים Task-id בצד של GitLab). על כך נכתוב אולי בהמשך (הצטרפו לרשימה למטה כדי לעקוב אחר עדכונים)

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

• כדאי להכיר: Taiga (אתר בעברית)
• מאמר: סקירת הפיצ'רים הקיימים ב- GitLab CI/CD (עברית)
• דמו טכני של GitLab CI/CD
• רשימה מלאה של כל הפיצ'רים הקיימים ב- GitLab , מסודרים לפי Edition ו- Category
• מאמר: "הרביעיה הקלאסית" למפתחי תוכנה (עברית)
• רשימת קורסים שאנו מעבירים על GitLab, Bitbucket, git, Jira, Jenkins
• אתר היצרן Taiga