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

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

אחד הכלים שיכול להתאים לכך הוא OpenProject – מוצר שאנו תומכים בו ומשמשים גם כנציג הרשמי של היצרן בישראל ובחו"ל.

במאמר להלן אדגים flow בסיסי, המשלב בין שני הכלים.

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

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

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

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

הסבר לתרשים:

החלק הסגול (העליון) הוא האיזור הקשור לניהול המשימה , ומבוצע ב- OpenProject . השתמשנו ב- flow המגיע כברירת-מחדל של משימה מסוג Task (שהינה חלק ממה שקרוי "Work Package") :

New –> In Progress –> Developed –> In Testing –> Tested –> Closed

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

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

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

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

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

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

1. The group leader creates a Task in OpenProject to fix a bug or develop a feature and assigns it to a developer. The task is now in New 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. When developers finished to develop the task he moves the status to Developed.
7. At last, the Merge Request is merged into the master branch, and again a CI pipeline runs to check the merge result.
8. Now it's time of the QA tester to make sure everything is OK. He moves the status to In Testing.
9. Some changes may be needed on the master branch, after which the software is marked as a new baseline and the task is marked as Tested (and then Closed by the tester or the group leader after a CD process has finished successfully)

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

לסיכום:

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

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

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