{"id":5511,"date":"2020-12-09T15:55:06","date_gmt":"2020-12-09T13:55:06","guid":{"rendered":"https:\/\/www.almtoolbox.com\/blog\/?p=5511"},"modified":"2021-04-01T20:31:01","modified_gmt":"2021-04-01T18:31:01","slug":"gitlab-taiga-flow-integration","status":"publish","type":"post","link":"https:\/\/www.almtoolbox.com\/blog\/gitlab-taiga-flow-integration\/","title":{"rendered":"Demo: Development workflow using GitLab and Taiga"},"content":{"rendered":"

Recently, there has been a growing interest in Jira -alternative project management tools that work on a private server (on-premises \/ self-hosted) or in the cloud, can be connected to git or GitLab \/GitHub and are open-source.<\/span><\/p>\n

One of the tools that meet those requirements is Taiga – a product we officially represent and provide support, licenses, private hosting, and training for.<\/span><\/p>\n

In the article below I will demonstrate a basic flow that combines both Taiga and GitLab.
\n<\/span>This is a typical, changeable flow. I chose a basic process to illustrate the connection between them.<\/span><\/p>\n

How it looks like if they work together?<\/h3>\n

 <\/p>\n

\"taiga-gitlab-flow\"<\/a>

A basic GitLab \u2013 Taiga integration (click to enlarge)<\/p><\/div>\n

 <\/p>\n

Explanation of the diagram:<\/h3>\n

The upper section (in purple) is managed by Taiga \u2013 this is a typical task workflow:<\/span><\/p>\n

Ready \u2013> In Progress \u2013> Ready for test \u2013> Done<\/span><\/p>\n

(Taiga enables you to change the flow and names of the states)<\/span><\/p>\n

The yellow part is where the developer works and operates git and GitLab operations (and indirectly also Taiga and GitLab CI\/CD).<\/span><\/p>\n

The blue area is the actions done from the developer\u2019s IDE (or alternatively from the browser – using GitLab’s WebIDE)<\/span><\/p>\n

The bottom (in grey) is the CI\/CD section, performed by GitLab CI runner (usually automatically, after setting a proper configuration)<\/span><\/p>\n

We will soon release a video demonstrating the process. For an update when we release this, send an email to the following address: taiga@almtoolbox.com<\/a><\/div>\n

Explanation of the process shown in the diagram<\/h3>\n
    \n
  1. The group leader creates a\u00a0<\/span>Story\u00a0<\/i><\/b>in Taiga to develop a feature (or a\u00a0<\/span>Bug<\/i><\/b>\u00a0to\u00a0fix a bug) and assigns it to a developer. The story is now in\u00a0<\/span>Ready\u00a0<\/i><\/b>status.<\/span><\/li>\n
  2. The developer starts working. He moves the task to\u00a0<\/span>In Progress<\/i><\/b> status, then creates a git branch and clones or pulls the repo to his workstation (he can also work directly on the browser using GitLab’s WebIDE).<\/span><\/li>\n
  3. After the feature is developed\/the bug is fixed, the developer pushes his work to the GitLab server, which triggers a CI pipeline.<\/span><\/li>\n
  4. If the pipeline succeeds, the developer creates a\u00a0<\/span>Merge Request<\/span><\/i>, thus starting a code review.<\/span><\/li>\n
  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.<\/span><\/li>\n
  6. At last, the Merge Request is merged into the master branch, and again a CI pipeline runs to check the merge result.<\/span><\/li>\n
  7. Now it’s the time for the QA tester to make sure everything is OK. He moves the status to <\/span>Ready for test<\/i><\/b>.<\/span><\/i><\/li>\n
  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 \u2013 it’s time to mark the story as\u00a0Done<\/i><\/b>.<\/i><\/li>\n<\/ol>\n

    Note: the chart shown here might have many variations. We have presented here something preliminary that can be a basis for changes and improvements.<\/span><\/p>\n

    Summary:<\/span><\/h3>\n