The Tuleap GitLab integration allows you to connect to any GitLab instance, in the cloud or on-premises. Imagine you use GitLab to build code that is planned and tracked into Tuleap. The GitLab integration with Tuleap makes the process of working across these two tools easier and more efficient. Check out why and how to use it.
Tuleap + Gitlab: why using both tools?
You can say Tuleap and Gitlab can be seen as “competitors” or “alternatives”. Actually, if you consider more than just both of them providing “Git” and issue tracking features, they’re quite complementary:
With Tuleap: you will gather a wide audience around one single project management tool. In addition to the development team, Tuleap is also used for overall project and program management, tests and requirements, documentation, and more…
With GitLab: your development teams will get top of the notch CI/CD pipelines and the git repository centered view they are used to with GitHub.
This means, if you use those two together, you’ll get the best of both worlds. That’s why we figured it was time to showcase our special integration to allow you to enjoy both those tools. Read on to learn more.
How Tuleap-Gitlab integration works
To get started, know that each Tuleap project can either:
- use regular Tuleap Git repositories and Tuleap Pull Requests
- use Tuleap-GitLab Integration
That being said, let’s dig into it.
Fully handled in Tuleap
Tuleap provides a dedicated GitLab plugin that will do all the heavy lifting to make things work seamlessly. On GitLab, this integration doesn’t have specific constraint; better, it runs using standard APIs available on all GitLab versions and flavors, on-premises or in the cloud.
MANAGED BY GIT ADMINS IN TULEAP PROJECTS
The installation of the Tuleap-GitLab plugin is the only action that requires a Tuleap site administrator. Everything else is in the hands of the Git administrators in Tuleap project.
Create GitLab repositories in Tuleap projects
It’s the base of the Tuleap-GitLab integration. A Tuleap Git Administrator creates a “GitLab” repository on Tuleap. This repository references the GitLab project the development team works on.
Integrated GitLab repositories will appear just like any regular git repositories, only we added a small 🦊 icon to distinguish them.
End-to-end traceability with Tuleap-GitLab integration
Regardless of where the code is stored and review, the promise of Tuleap is to keep the track of what is done, when and what for. In other words, Tuleap provide end-to-end traceability from requirements down to the code and from the code back to the requirements. This can be mandatory for regulation purpose (eg. for ISO & IEC used in cyber-physical devices development), troubleshooting, history & knowledge management, etc.
With Tuleap-GitLab integration, benefit from end-to-end traceability even outside Tuleap.
You can mention a Tuleap artifact ID in a commit message or merge request from GitLab. The Tuleap artifact (issue) ID adds a reference with details and a link back to the activity in GitLab.
Traceability isn’t about just about references, it’s about linking pieces of information together to understand why something was done. In the context of software development, what goes in production is what each individual developer understood from the requirements. To that end, developers are encouraged to reference the Tuleap artifact that corresponds to the commit been made. Depending on the context it can be a Task, a User Story or a Requirement depending on the methodology of your team.
Developers create the link between code and artifact by adding a TULEAP-XYZ in their commit messages (where XYZ is the artifact ID of the requirement). Those commit messages will analyzed by Tuleap that will:
- create on Tuleap a reference toward the commit
- add on GitLab a comment on the commit with a link back to the artifact
Referencing a Task is done a lot but might be counter productive because it forces developers to create a 1-1 relationship between their commit and tasks on board. That’s often very boring for developers and doesn’t help much for traceability because it dilutes the information. The traceability should be done close to the expression of need (so a high level object such as a User Story).
GitLab links to a Tuleap artifact
View GitLab commit linked to a Tuleap artifact
GitLab Merge Requests
Most of GitLab usage implies Merge Requests (MR). If you don’t know GitLab much, Merge Requests are the equivalent of GitHub Pull Requests. Of course, here too, you are covered with full traceability.
The typical use case is to have a User Story defined on Tuleap with development tasks on the Tuleap Taskboard. Then, on GitLab, the development will flow with either:
- A feature branch approach, then the Merge Request will roughly correspond to the user story. At this point it’s expected that the developer will integrate a reference to the user story in it’s MR (like “TULEAP-45678 Color detection of puppies”).
- Or a finer grain approach where each development task leads to a MR. Again, the developer will be able to reference the task in the MR (one task one MR). They can also decide to reference the story itself by adding the reference in the MR description “Part of TULEAP-45678”.
In both cases, when browsing the Tuleap artifacts, anyone will be able to deep dive into the code thanks to the reference to the Merge Request. And as Tuleap adds a comment with a link back to the artifact in the MR comment section, people looking at the MR will be able to connect with the specifications, the tests, etc.