| Category Attribute | Link |
|---|---|
| Stage | Manage |
| Maturity | Not applicable |
| Labels | groups |
Thanks for visiting this category page on Subgroups within GitLab. This page belongs to the Spaces group of the Manage stage, and is maintained by Luca Williams who can be contacted directly via email. You can also open an issue and @mention them there. Please add the group::spaces label for wider visibility.
This vision and direction is a work in progress and sharing your feedback directly on issues and epics on GitLab.com is the best way to contribute to this vision. If you’re a GitLab user and would like to talk to us about any of the topics covered below, we’d especially love to hear from you.
Groups are a fundamental building block (a small primitive) in GitLab for project organization and managing access to these resources at scale. Like folders in a filetree, they organize like resources into one place - whether that’s a handful of projects all belonging to a backend team, or organizing a group of user researchers into one place to make access control and communication easier.
Since groups cover multiple projects, we also scope a number of features at the group level like epics, contribution analytics, and the security dashboard.
In 2020, our goal is to improve groups with improvements to access control, enhancements to the user experience, and by extending subgroups to be able to meet two important use cases: one to help Enterprise organizations thrive on GitLab.com, and one to support teams of people.
With the proliferation of Cloud services and more companies taking advantage of managed infrastructure, SaaS products need to work well for large customers. Historically, Enterprise customers have gravitated toward Self-Managed GitLab as their favored solution. Now that we've grown with our customer base, we need to focus on the importance of providing a SaaS platform which can not only safely and securely house our customers and users, but also deliver a rich and fulfilling Enterprise experience that looks and feels exactly like their own private instance of GitLab whilst simultaneously reducing the load, cost and cycle time of having to manage and configure their own infrastructure.
We seek to solve a number of problems with the current SaaS experience:
To solve the isolation challenge, we introduced the concept of group managed accounts in 12.1. This is a useful tool that creates a "group-level user", which requires that a person use a particular user account to interact with a specific group. This is very useful for organisations who want to require a separate account for work in the group - this is a typical use case for GitLab.com, where a top-level group may represent a company. Group Managed Accounts currently requires SSO/SAML to be configured.
Group Managed Accounts are a fantastic start towards improving Enterprise isolation, security and privacy. In order to better accommodate Enterprise customers, we need to build an additional, secure layer around Groups, Projects and the teams of people working in them in order to give them the space they need to spread out, work, create and communicate with each other and Group Managed Accounts is the first step to do that. The next step is for us to work on extending Group Managed Accounts and iterate from there.
We are essentially moving towards a new, top-level isolated type of group which allows multiple parent groups within it. Eventually, we hope to take this concept beyond solving for isolation and better administration - it can offer a way to bring instance-level features to the top-level group and introduce a collaboration platform across many groups and projects.
Some ideas of what this could look like includes features such as group-level activity feeds; Instance-level (top-level group) epics and issues; Full and autonomous user management and unified access control; Strong privacy features and autonomous data protection; Productivity highlights and hotspots in your organisation; Configurable and informative dashboards; A blog platform; Scheduling; Integrated chat functionality and more. The goal is to move even further towards a single application by enriching the user experience in such a way that you never need to leave GitLab to get the job done.
Groups are used by all GitLab users, no matter what role. However, heavier users of Subgroups in terms of organisation and management of projects and users consist of:
You can see the upcoming work for the first phase of addressing the aforementioned Isolation problem here. Please review this epic for a higher level view of the roadmap.
We introduced the first iteration of Group Managed Accounts as a concept specific to SAML SSO. Our next important step is to extend this "group-level user" idea to other groups without requiring the use of this authentication strategy. We will do this by introducing a cleaner, more elegant way for Group Owners to easily create and manage users at the parent group level without the need for SSO/SAML enforcement, and also provide a clear login experience for those group-managed users.
You can follow along with the progress of this effort here. We aim to deliver this MVC by 12.10 and will be focusing on only this work for that milestone.
As Subgroups are a GitLab-specific concept, it's considered a non-marketing category without a maturity level that can be compared to other competing solutions.
🚨 GitLab Support Engineering: Isolation & Control Requirements
