#Gitlab youtrack integration how to
#Gitlab youtrack integration code
#Gitlab youtrack integration series

Note: YouTrack integration is supported only under PractiTest’s Enterprise license. The same is applied to requirements that can be imported into PractiTest from YouTrack. Any updates made to an issue in YouTrack will be synchronized and updated in PractiTest, and vise The Issues imported into PractiTest will automatically be linked back to the original issue in YouTrack. This integration in order to report bugs directly into YouTrack from within a PractiTest Test Run.Īfter the YouTrack integration is configured by your account manager, each issue from YouTrack can be imported to PractiTest. The integration between PractiTest and YouTrack helps you share the information between 2 systems by allowing you to import and link Issues from YouTrack as Issues in PractiTest. If anyone has any advice or pointers, I’m all ears.PractiTest and YouTrack Two-Way Integration – Intro

#Gitlab youtrack integration how to

In essence, I’m looking for advice on how to organize a GitLab instance. Do they all get lumped together in this model?

#Gitlab youtrack integration code

Still, they write their integrations as Apache Camel / java code that runs in Openshift containers, so they kind of count as microservices / miniature systems. 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.I’m estimating that we have around 200+ distinct systems here on campus, from network infrastructure to departmental applications and everything in between. Then our teams would get their own groups, and have the systems assigned to the team groups. 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.

Currently we have our team groups, and then projects under those.

In my mind, I’m thinking that we need to re-organize our internal GitLab Groups.

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. 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.

#Gitlab youtrack integration series

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.

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.

So here’s my questions, as someone who is not as familiar with GitLab: In the long term, we are also looking at leaving YouTrack, and moving our issues/backlog/task tracking into something else - likely GitLab. We are keeping GitLab and moving to an Ultimate license.

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