Gitlab as issue tracker

Among the tools of development team, you can find IDE, methodology, source code management or issue tracker. For SCM, I went first with subversion (SVN) then perforce (P4) and finally got into the most used now: git. As for issue trackers, it was redmine, bugzilla and finally Jira. As an agilist, I’m more than convinced about the very first value:

Individuals and interactions over processes and tools.

I’ve started working in an IT company that is getting reconstructed for less than a year. One of the first challenge was to re-think how we could get into a set of tools easy to use and familiar, since even all the recruitment was on progress (by the way https://jobs.lever.co/shadow). As I’m involved with developers, one of the main tools is the issue tracker. We were already using gitlab for version control, merge requests, wiki, and already using their CI/CD solution.

Why couldn’t we use gitlab as an issue tracker since it’s the everyday interface for developers? There are issues, milestones, epics, due date, weight, charts, custom labels, so why not? Now you get the why, let’s dive into the how!

Issue

There are plenty of actions for a single issue:

• describe it
• add pictures
• write comments
• notify users
• link with other issues
• set a weight
• review the history of the issue
• attach an MR to it
• add a due date
• set a milestone and an epic

There is nothing more to say, it’s pretty complete.

Issue lifecycle

A gitlab issue can be open or closed. Something interesting is that Gitlab has already implemented classic kanban states (to do, doing, done) as default labels. It was crystal clear for us to exploit this, and go further. There are two types of label, the classical one with one word, and we could use it and add “To be refined” for example. The problem is labels can be used all at the same time, and you could have a ticket with “to do”, “to be refined” and “doing” at the same time, Schrödinger’s ticket style.

The second type, and you guess it, that’s what we go with, is the scoped label set, and then : mutually exclusive labels, no more absurd state for an issue.

However, be careful, it’s just a label to sort issues (and visualise them in quite an easier way through the boards) and it has to be closed instead of having a STATUS::DONE label (don’t use STATUS::DONE), and if you have some good scripts, you can trigger the closing with a merge to the master branch for instance

Milestone as sprints

Instead of using iteration, we went directly with the milestone. From the milestone view, you’ll be able to see in a glance current MRs, to filter label.

You can obviously have a start and a due date, use the total issue weight to master your capacity, all the status of the merge requests, the completion, and the burndown and burnup charts.

Our milestones, i.e. our sprints, are named simply CW{XX}-{XX+1}_{YY}, so with a week calendar, it’s easy to know what have been done

Boards

Since issues are tied with a project (and not a group) in Gitlab, boards have to be created in proper location. When creating a board, the first filter would be directly a milestone, then add all your status label as lists (ie columns). You’ll be then able to use their combination of filters to select very specific items, like filtering by platforms or priority. Drag and drop-ing issue to a column will automatically set the right label (and since they are exclusive in a scoped label set, it also removes the former label).

Tips

• You can create a list in a board with any label or milestone, so if you change the column of a ticket, it will change the proper attribute
• Write some scripts since you’re likely to work with developers, grab a devops !
• Since there is inheritance from top to bottom in the gitlab tree (groups and projects), create labels, milestone in the proper location.
• It’s easy to set role management (not as precise as Jira for example) but you can restrict directly users in a group, sub-group and projects.
• Watch gitlab updates in case of APIs are changing and screw everything

Cons

• Sprint review when closing a sprint and starting a new one, there is no automatic action nor bulk
• Off-boarding: need to delete users in every group manually
• Roles are fixed: owner, maintainer, developer
• Cross-team projects
• Plenty of manual actions

Unfortunately, those cons are where we meet the limitation of using Gitlab as an issue tracker.

Next step to experiment

• Proper automation
• Gitlab action through slack bot
• Automatic reports
• What could the ultimate plan provide ?
• Clean our Gitlab tree in order to have the visibility from user story to technical tasks.