Should I Manage Code in a Single Organization or Multiple Organizations?

Managing code in a single or multiple organization: Which is right for you?

The process of organizing, versioning, and maintaining code repositories—otherwise known as source code management—is a key component of modern software development that speeds up and streamlines the software development lifecycle.

Typically implemented as a Git hosting service with multiple features, commercial solutions like GitHub, Azure DevOps, BitBucket, and GitLab can help you manage your code repositories more efficiently. Still, when it comes to organizing a large number of repositories, things can get complicated. This is especially true in enterprises with large development organizations working across code repositories.

DevOps is concerned with making sure developers have the access they need and that code is maintained and versioned correctly, but it is important to ensure that only the necessary people have access to code. These interdependent priorities raise an important question: Is it better to manage code in a single organization or multiple organizations within the code management software?

In this blog post, we explore the pros and cons of both with the four most popular web-based code management solutions: GitHub, GitLab, BitBucket, and Azure DevOps.

GitHub: single vs multiple organizations

When it comes to source code management and Git hosting, GitHub is arguably the most dominant player on the market. It offers multiple options for structuring organizations within your enterprise, the most popular being the ability to choose between a single or multiple GitHub organizations.

Single organization in GitHub

In a single-organization setup, all code repositories are maintained under one “GitHub organization.” Here, there are two ways to manage access to the code: direct access or team access.

With direct access, the simplest available structure, all repositories can be accessed directly by all developers—without the need for team-level permissions. This approach generally works well for small companies and startups.

In contrast, team access allows only members of certain teams to access the desired repositories, depending on the configuration.

Pros

• Easier to find resources since they all belong to the same organization.
• Better communication between developers since there is no need to specify which organization an issue exists in.
• Leaner development process due to faster development and less time spent on tedious tasks.
• Greater flexibility and granularity of access control for the organization’s owners when using a single organization with the team access feature—which is generally better for larger organizations.

GitHub itself actually advises companies to minimize the number of organizations used to manage code.

Cons

• All repositories can be accessed by the owners within the organization. Thus employees could have full access to your repository, even if unrelated to the projects they are working on.
• Allows for multiple organization owners, going against the GitHub recommendation to limit this number.

Multiple organizations in GitHub

In a multiple-organization setup, all code repositories are maintained under multiple “GitHub organizations.” Just as with a single organization, each organization within this setup can use direct or team access independently.

Pros

• Better security isolation—a data breach in a small organization within a multi-organization setup will likely leak less sensitive information.
• Ability to configure separate policies best suited to each organization.

Cons

• Limited flexibility, with each organization likely needing to follow many overarching corporate rules. For example, if management needs to enable SSO, every organization will need to enforce this individually, resulting in more administrative work and a greater chance of human error.
• Harder to share information between members of different organizations and to share resources between developers. A developer cannot even “mention” another team member (using the @ sign) in a private repository if the team member is not part of that organization. Developers thus cannot notify team members immediately to request reviews and comments, nor can a review request be sent to someone who is not part of the same organization on the pull request for a private repository.

Additional considerations when managing organizations in GitHub

Multiple organizations using varied access

It is also possible to set up GitHub using multiple organizations that implement different access methods. This allows you to benefit from the ease of communication a single organization offers, without having to share repositories for global access.

Lift in governance

When using organization-level policies and configuration, governance efforts will be duplicated for every added organization. Though this offers greater flexibility to customize policies and configurations, it also involves the responsibility of managing multiple organizations.

GitLab: single vs multiple organizations

As of the writing of this post, the GitLab organization feature is still in development. By using a top-level namespace, however, you can replicate a single organization setup; for a multi-organization setup, you can use multiple accounts.

GitLab uses namespaces to manage projects and repositories, allowing you to organize and categorize projects—which can be a part of one or many namespaces. Namespaces based on your username are for personal use. Group/subgroup namespaces help teams manage multiple projects. Each subgroup has its own settings and URL and can inherit the parent group settings.

(Note: Subgroups are sometimes referred to as “groups” as well, and the two terms should be considered synonymous within the context of this article.)

Next, let’s take a look at how to implement single- and multiple-organization setups in GitLab.

Single organization with namespace access in GitLab

Here, you can use a single top-level namespace group with namespaces access. This single-organization setup is very common in small and mid-size companies.

Pros

• Facilitates communication and collaboration between developers due to having one organization, as with GitHub. Tagging a co-worker or requesting a code review is easy. You can also use namespaces that provide a high level of configuration for access management and other settings.
• Eliminates redundant work between accounts and requires less management since namespaces can inherit the parent group settings.

Cons

• Challenging to organize development teams, projects, and repositories when a company may have thousands of developers and hundreds of repositories. Solid group and namespace management knowledge is a must for ensuring this approach will work.

Multiple organizations in GitLab

The other option for organizing codebases in large organizations is to use multiple company accounts/organizations. This can be done with or without group namespaces, depending on how many developers and repositories will be used in each account.

Pros

• Better security segmentation, similar to GitHub. If a security incident occurs and sensitive information is stolen, having multiple small accounts can limit the attacker’s ability to move easily between organizations, thus limiting the blast radius.

Cons

• Harder to collaborate and share resources, similar to GitHub. 
• Duplicated account and permissions management, meaning additional work required by your team and additional administration for other organizational settings.

BitBucket: single vs multiple organizations

BitBucket, a popular code management platform from the makers of Jira and Confluence, offers users the ability to manage their code in workspaces, projects, and user groups.

BitBucket organizes projects and code in its software through: 

• Workspaces: A container for projects and repositories
• Projects: A way to organize repositories and apply a configuration to them
• User groups: A means for managing multiple users

Because BitBucket does not have the concept of an organization built into the software as GitHub does, in this section, we will be mapping workspaces to organizations.

Single organization in BitBucket

With a single organization, repositories are located in the same workspace for the entire company. These are then divided into projects.

Pros

• Good communication and visibility, making it easy for developers to share data, tag each other, and request code reviews.

Cons

• May be challenging to create a proper structure since you can only organize your repositories using projects, which may prove difficult for enterprises.

Multiple organizations in BitBucket

When using a multi-organization setup, the company’s many repositories are divided into multiple workspaces.

Pros

• Better security isolation, with less data being leaked if a security incident should occur.
• Reduced or equal visibility of repositories and assets for other developers in the company. With multiple organizations, most developers won’t have access to view and edit other organization code and assets. Though this means information will be less transparent between teams, it can serve as an advantage when working on sensitive matters or when you need to keep information isolated from other parts within a large company.

Cons

• Duplication of administrative work due to too many workspaces, much like with GitHub and GitLab.
• Poorer collaboration and reduced visibility due to isolation.
• Can be more expensive to have multiple workspaces/organizations for small teams due to BitBucket’s fee structure, whereby a workspace is charged a minimum flat fee of $15/month for up to 5 users.

Azure DevOps: single vs multiple organizations

Much like the other code management platforms, Azure DevOps enables teams to organize user permissions and other configurations. Azure DevOps recommends creating a team for each distinct product or feature team.

The platform also implements the project concept through a container for repositories, CI/CD, and backlogs.

Let’s review how to manage code in Azure DevOps via a single organization and multiple organizations.

Single organization with one project and multiple teams in Azure DevOps

This is the recommended setup for getting started with Azure DevOps. It is generally the ideal setup for small organizations.

Pros

• Improved collaboration and visibility, with developers able to communicate better and more easily see the work being done.
• Less administrative work, as most administration can be done centrally and shared between teams.
• Less context switching with one organization and just one project, since developers won’t need to browse between organizations all the time.

Cons

• Security risk, since assets and code within one organization can be locked down at the team level but are fully open by default, This means the person managing assets and teams in Azure DevOps needs to create the proper access controls.
• Harder to scale and stay organized as the number of individual contributors grows.

Single organization with multiple projects and teams in Azure DevOps

In this scenario, unlike the previous setup, the company can move its various repositories under different projects. This would likely be the ideal solution for a medium- to large-size organization.

Pros

• Flexibility, with the ability to configure each team’s projects based on their specific needs and processes.
• Easier to scale the number of contributors due to the level of granularity offered.
• Improved collaboration and visibility, which can also be adjusted to hide assets between projects.
• Easier to organize and scale multiple repositories.

Cons

• More administrative work when handling multiple projects.

Multiple organizations in Azure DevOps

In this final setup, the company uses many organizations to manage the development effort. Within each of these organizations, there can be multiple projects and teams.

Pros

• Information is segmented to effectively limit an attack’s blast radius in case of a breach, just as with the other providers.
• Easier migration from the legacy Team Foundation Server (TFS), with Azure DevOps itself recommending this setup for this purpose.

Cons

• Poorer collaboration and visibility, with developers experiencing more context switching. This means more time wasted and less code written.
• More administrative work involved. Many of the organization-level configurations need to be selected, edited, and customized multiple times—leading to work being duplicated.

Conclusion 

The decision to manage code in a single organization or across multiple organizations depends on the specific size, requirements, and objectives of your development team and the company as a whole.

GitHub, GitLab, BitBucket, and Azure DevOps offer different options for managing code for larger organizations, each with its own advantages and disadvantages. It is essential to evaluate these approaches carefully and choose the one that best aligns with your team's requirements. It is also important to consider the recommendations from the solution providers themselves; for instance, GitHub advises limiting the number of organizations.

For most solutions, managing code in a single organization can facilitate collaboration and improve visibility with less administrative work. Managing code across multiple organizations, on the other hand, can provide better isolation but may lead to administrative overload. It is up to each development team to determine which approach works best for them.

Need help managing your organizations? View all of your organizations in one place with Arnica. Get the flexibility you need to manage your policies and rules with ease, from the organization level all the way down to the branch level. Book your free demo today.