How to reflect organizational structure in GitLab?

My company has recently adopted GitLab and we’re trying to find the best way to make it fit our workflow and organizational structure. I’d like to share our thinking so far to see if it makes sense to more experienced GitLab users and to ask how others have addressed similar situations.

I’m at a small company that makes a few different software products. These products are all under active development: none is finished yet. They are mostly independent: developed by different teams, with different schedules, and different scrums and sprint cycles. A single product’s codebase may consist of multiple services. Some services are unique to a product, and others may be shared between multiple projects.

Our services are generally something that can be packaged inside a Docker image, so we’re creating a GitLab Project for each one and using the CI/CD tools to compose them as needed. This seems to work.

We’re less certain of how to reflect our organizational structure in GitLab terms. We’re leaning towards creating a Gitlab Group for each of our products. Groups seem like the right high-level abstraction, and the fact that Epics and Issues are sorted by Group reflects the way we manage products. The fact that Projects also divide up by Group also mostly works for us, except we’re not sure what to do for code shared among multiple products. Should that go into a “common” group? If we do put shared Projects in a “common” group, can their Issues still be tracked by multiple other Groups?

This is an open-ended question, and I realize there are multiple ways to set things up. But does our general thinking seem to be in the right direction? Does anyone have anecdotes about how their organization addressed similar structures?

You can create sub-groups within a group as well. That could help with the issue thing, if you do something like:

main_group → sub_group1 → project
main_group → sub_group2 → project
main_group → sub_group_common → project

that way all issues will be visible from the main_group (I expect). If you had two main groups, I doubt very much you would be able to track them in the other main_group at least based on how you want to do it.

We organize like iwalker says above - CompanyName is Root group, subgroups are Product Line, sub-sub groups Product. Just 3 levels. Use SSO Groups to manage access is best practice (but we don’t use SSO Groups right now for a few technical limitations with our IdP/AD setup). We instead use SSO, add everyone to Guest at root, then do Direct Invites to subgroups (that way everyone has guest access/can view root and org structure and few artifacts, but only have correct perms to either their Product Line and/or Products.)