Project organization

We are developing application which consists of back-end written in Java and front-end written in Angular. Both front-end and back-end is developed with one team consisting of UI/UX, Front-End Developers, Back-End Developers, QA, devops engineer.

We would like to have different repos for back-end and front-end projects but we want to have one backlog where every User story is documented and moved across boards (ToDo, In Progress, Acceptance, Done)

How should we organize this in GitLab with Group/Subgroup/Epic/Issues?

I could not find the answer in the GitLab documentation and guides.

This is a difficult one to answer in the docs, as there is generally no one solution to fit everybody’s needs - and the GitLab issue management is flexible enough to cater for different paradigms.

Were I to do it - I might have a hierarchy something like this:

application
├── backend
│   ├── component-a
│   └── component-b
└── frontend
    ├── component-x
    └── component-y

You can create your issues directly on the appropriate components, have frontend- or backend-wide epics at that level and overall epics at application level. You can also manage your labels/milestones/iterations at the application level, too.
What’s more - if you create your issue boards at the application level, you’ll see all of the issues from the lower projects in one board.

I like this approach because:

  • Issues are close to the code
  • Epics can describe features which can then be broken into issues by the team
  • Everything is nicely visible at logical levels

Hope this works for you!

1 Like

Thank you for the quick reply.

Based on your structure User Story = Group Level Epic?
For instance: “As an admin I should be able to define customers” translates to Group Level epic which consists of 2 issues one in backend project and one in frontend project. I simplified your structure here (component level is not necessary)

Yup - that’s how I’d see it. If your license level gives you the ability to nest epics you could group them further - but you could also use labels to do that…
In this way - a backend MR could close/update the backend issue, leaving the frontend to work on their change.

You might want to keep frontend and backend as subgroups with just a single project in each - in case you need to subdivide them one day, it’d make things a bit easier… (at the same time, simpler is often better, too!)

1 Like