I am wathcing " Webinar - Intro to GitLab" at (919) Webinar - Intro to GitLab - YouTube
The presenter indicated several times that when creating an issue, it can be a User story, a bug…when I visit the create an issue in our Gitlab on-prem, I can only chose between 2 types “Issue” or “Incident”, am I missing other types because it is on-prem? Thanks
1 Like
Issues are for user stories / bug reports / technical debt / etc. and Incidents are for outages, performance degradation, etc. in production systems.
To distinguish between different sorts of issues, you can use two things:
- Labels defined in a project or a group, or
- Templates defined in a repository (or a group, for paid tier accounts).
But how you use those two features is entirely up to you, and the workflow you choose to implement.
Thanks snim2, I used another platform before joining a new company using Gitlab. In that platform, they call it work item, when we create a work item we can chose between different options (Bug, US, Task, Test Case…) which is very useful for efforts planning, analytics and reporting on different levels. So when I heard the guy in the video, I thought that it was the same principle, that is why I posted this thread. Please tell me, how this unique “issue” item can allow see different graphs such as Dev velocity, Burndown graph…if all items are “issue”. Yes Labels can help in search operations, organization but not sure how it can be used for example for efforts planning, story points, priorities…
You can read a bit more about burndown charts here.
However, GitLab doesn’t tie the user into a particular workflow, so I think you’ll find it more flexible than the system you are used to, but also that it takes a bit of effort to set things up the way you want them.
Sarah, why do think other platforms
tie the user into a particular workflow
This is not the case, you have out-of-the-box types of work items to declare and you can add your own types with all properties and configuration as well as chose to link them to analytics (all is done visually and drag and drop or update/enhance an existing work item). As a beginner in Gitlab, I see that this is a lot of efforts not a bit as you say and might lead to a lot of errors unles you are expert in Gitlab and Markdown …, so instead of concentrating on how to go quickly and do our job, we need to spend a lot of time on customizing Gitlab. I would suggest that Gitlab team, provide at least the main work items types for the most used methodologies Scrum, Agile, Kanban such as (User Stories, Bug, test case, feature…). This is my humble opinion as I have already worked with 2 other platforms that makes SREs, Devops Engineers and managers easier.
Also, the terminology Gitlab uses “Issue” is not quite appropriate. A User Story or Test case is not an issue, also, how do we define a developmenty task in Gitlab and link it to a user story!!!
I don’t like the fact that GitLab suggests using Issues for user stories, when an Issue must be associated to a specific project.
At the same time, a GitLab project has 1 repository, therefore we have to use GitLab projects not for our business project but for code projects.
For example, if our Business Project Foo has several microservices:
A microservice A would be a gitlab project under the subgroup Foo
A microservice B would be a gitlab project under the subgroup Foo
etc.
Now I want to create a user story for our business project Foo that is cross-repository because it requires technical changes in both microservices A and B…
I can’t do that with GitLab, it’s not really designed for that.
I can move the concept of user story to epic, but then I cannot associate epics directly to a sprint/iteration/milestone.
However I look at it, I cannot really use GitLab for project management, and it’s a pity because I really like it for CI/CD and source code management.
Any advice?
I wrote the following asking for help before I look for other tools user story - GitLab limitations for Agile Software Development - Software Engineering Stack Exchange
@diegosasw one alternative would be to use a specific project just for issues, and turn off repository-related features for that project. The other option would probably be to use a third-party solution with an integration (I think Jira would be one candidate here?).
1 Like