Demo: Development workflow using GitLab and Taiga

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.

One of the tools that meet those requirements is Taiga – a product we officially represent and provide support, licenses, private hosting, and training for.

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

How it looks like if they work together?

A basic GitLab – Taiga integration (click to enlarge)

Explanation of the diagram:

The upper section (in purple) is managed by Taiga – this is a typical task workflow:

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

(Taiga enables you to change the flow and names of the states)

The yellow part is where the developer works and operates git and GitLab operations (and indirectly also Taiga and GitLab CI/CD).

The blue area is the actions done from the developer’s IDE (or alternatively from the browser – using GitLab’s WebIDE)

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

Explanation of the process shown in the diagram

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 work directly 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 the time for 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.

Note: the chart shown here might have many variations. We have presented here something preliminary that can be a basis for changes and improvements.

Summary:

• You can connect Taiga and GitLab. They can also be integrated to GitLab CI/CD (or other CI tools like Jenkins) for testing, build or deployment automation purposes
• You can also refine the integration and develop automations for specific use cases (for example adding an automatic link in Taiga’s activities when specifying the Task-ID on the side of GitLab). We may write about this in the future (register yourself to our mailing list below to get future updates).