Migrating to GitLab Issues from YouTrack - Advice?

Hey everyone!

My organization is looking at adjusting how we conduct business, and incorporating tools better. Prior to now, we have been running GitLab Starter and YouTrack. Our frontend and integration teams were using gitlab issues, but backend/apps folks were using YouTrack for issue/project tracking.

Well, re-organization and budgets and the like have made us re-evaluate. We are keeping GitLab and moving to an Ultimate license. In the long term, we are also looking at leaving YouTrack, and moving our issues/backlog/task tracking into something else - likely GitLab.

So here’s my questions, as someone who is not as familiar with GitLab:

  • Are there any big “Gotchas” in terms of features that we gain/lose with that move? It appears that GL Premium will let us do epics, which is awesome.
  • Anyone have advice on where to start with labels? YouTrack used a series of fields attached to its projects to indicate things like priority and component. Looking at GitLab, it seems as if scoped labels will follow that path… but they need to be set on the group/project level and are not global. It also looks like anyone with reporter status can add/remove them, unless there’s some way to secure them or make them mandatory that I’m missing.
  • In my mind, I’m thinking that we need to re-organize our internal GitLab Groups. Currently we have our team groups, and then projects under those. I’ve been thinking of switching to a model where “systems” get their own top-level groups, and then projects/subgroups under that handle individual repos/configs/automation scripts / so on. Then our teams would get their own groups, and have the systems assigned to the team groups. I’m estimating that we have around 200+ distinct systems here on campus, from network infrastructure to departmental applications and everything in between. Does this model sound like a good fit?
  • Following off of the above (which should probably be its own topic), does anyone have any advice for how to handle integrations between systems, in terms of where its code should go? Currently, our integrations dedicated team puts their code under their team, but that doesn’t necessarily link to the systems on either side. Still, they write their integrations as Apache Camel / java code that runs in Openshift containers, so they kind of count as microservices / miniature systems. Do they all get lumped together in this model?

In essence, I’m looking for advice on how to organize a GitLab instance. If anyone has any advice or pointers, I’m all ears. :slight_smile: