Organization - Iteration plan and considerations

Problem

There are several possible paths to reach the end goal of having an Organization established on both GitLab.com and for self-managed users. We need to identify the best possible approach moving forward.

Possible approaches

Approach 1: Top-level groups turn into Organizations

In this scenario, we would convert the currently existing top-level groups into Organizations.

Advantages

• A lot of functionality currently tied to existing top level groups already equates to a Organization level feature

Disadvantages

Impact on self-managed users

Self-managed users have the Admin panel available to them at the moment. What would their transition into an Organization world look like?

• We could introduce a feature flag to allow self-managed users to keep the old functionality until everything is migrated to the Organization level on GitLab.com.
• Once that is done, we could switch on the feature flag and expose them to the new experience, which will basically be the old experience just in a new place.
• For self-managed users wanting to explore the new experience while we are working on it, we could already enable the feature flag.

Impact on GitLab.com users

• GitLab.com users would go from having no admin experience to the MVC.
• We would build out the functionality in top-level groups iteratively.

Possible migration scenario

• No migration necessary.
• Additional functionality becomes available in top-level groups over time until it is on par with the admin panel experience for self-managed users.

Approach 2: Organization is built on top of top-level groups

In this scenario, top-level groups become groups. You would lose your billing functionality on the level, and it would move into Organization.

Advantages

Disadvantages

• Adding a higher level creates the problem of migrating that functionality higher up.

Impact on self-managed users

Self-managed users have the Admin panel available to them at the moment. What would their transition into a Organization world look like?

Impact on GitLab.com users

Possible migration scenario

• Originally a default Organization is created that hosts all top-level groups

  • More Organization can be generated after the introduction and top-level groups can be migrated to their respective Organization

• Default Organization has a URL /default/xxxxxx, but can be reached without /default as well

  • Similar to how it works today when a project is migrated
  • User gets message to change to /default when accessing from the other version
  • Stats could be collected about how many requests are running on the default Organization without a real namespace
  • These users could be pinged specifically to change
  • Over time, everything would be migrated
  • Then you can change to a new Organization

Open Questions

• Are URLs changing with the introduction of a Organization?
  • Some part of the infrastructure refers to the URLs
• Are URLs changing when top-level groups move from one Organization to another?
• How will inheritance and aggregation work within the Organization?