« לעמוד הראשי

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

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

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

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

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

gitlab taiga flow and integration

הצעה לתהליך עבודה המשלב 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 (לרוב באופן אוטומטי, לאחר שבונים קונפיגורציה מתאימה)

 

בקרוב נוציא סרטון המדגים את התהליך. לקבלת עדכון כאשר נוציא זאת, שלחו מייל לכתובת הבאה: taiga@almtoolbox.com

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

  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. The 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). על כך נכתוב אולי בהמשך (הצטרפו לרשימה למטה כדי לעקוב אחר עדכונים)

 

חברת ALM-Toolbox מציעה פתרונות מקצה לקצה בתחומי ALM, Kubernetes, DevOps, ובפרט Taiga, Jira, GitLab, Jenkins , בניית סביבות פיתוח ובדיקות והעברתם לקונטיינרים ולענן, מיגרציה בין כלים, הדרכות על הכלים, התאמת רישוי לצרכי הלקוח ומכירת רשיונות תוכנה מתאימים ועוד.
שאלות? נשמח לענות על כל שאלה – אפשר לפנות אלינו במייל devops@almtoolbox.com או טלפונית 072-240-5222

אנחנו:

  • נוכל לעזור לכם להחליט האם הכלים האלו מתאימים לצרכים שלכם
  • נוכל לבנות אינטגרציה עבורכם ולעזור לכם להגדיר flow שישלב את כל הכלים יחד, באופן שמותאם בדיוק לצרכים שלכם
  • נוכל להרים את הסביבות ונוכל להדריך אתכם בשימוש ותפעול
  • תומכים ומוכרים רשיונות של שני הכלים
  • נוכל לבנות לכם אוטומציה של בדיקות והפצות, עם CI/CD של GitLab ו- Jenkins

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