Bitbucket Cloud Teams

 

Bitbucket Cloud teams allow you to collaborate and manage multiple projects, repositories, and users as you create amazing software. With a team, you can:

  • Create and share access to your team's repositories.
  • Create projects to organize and focus your teams work.
  • Set specific permissions for different roles or feature teams.
  • Manage your team's costs with a single user plan.
  • Integrate your team's projects with services like JIRA Software and HipChat.

How teams work

There's different components to your team: users, groups, and repositories. Let's take a look at what those are and their relationship to each other.

Your team owns your repositories.

 

 

All teams have user groups. Groups specify default permissions for your team's repositories.


Add users to the team's groups, giving them access permissions for repositories.

 

Now that you understand the relationship between users, groups, and repositories, let's see at what they look like in Bitbucket.

Every team has two user groups by defaultan Administrators user group and a Developers user group. Here's an example of what one of your user groups will look like. You can see the group's access permissions and the users part of that group. Learn more about user groups.

Let's take a look at the access page of a repository. The team's groups were added to the repository with their default permissions, but you can change a group's access at any time. Learn more about repository access settings.

If a team member has permission to create team repositories, that user becomes an admin for each repository created.


 

How your team could work

Now that you know how teams work, let's look at some examples of how team and repository setup could work for different types of teams. Keep in mind that they are only examples and you can organize your team based on what makes sense for your organization.

Small team

Small teams (2-10 users) generally require the simplest setup. Because every team already has the Administrators and Developers user groups, you can update the permissions you want your team to have without creating any new groups. Then, all you need to do is add users to both groups to give your small team both simple access controls and flexibility.

User groups for a small team:

Group name Default repo access Team permissions
Administrators Admin Administer team, Create repositories
Developers Write Create repositories

Repository scenario for user group example:

Repo 1

John (part of Administrators) creates Repo 1.

  • Developers group has default Write access.

Repo 2

Shelly (part of Developers) creates Repo 2.

  • She has automatic Admin access on the repo she created.
  • Developers group has default Write access.

Large company with separate teams

When you have multiple software teams in a large company, you create one team for all your users so that you have only one billing account. With that one team, you can create separate user groups for all the different groups at your company. These groups could be based on roles, products, or features. This scenario bases them on feature teams and could work for a team way over 100 users.

Example user groups for a large company with separate teams:

Group name Default repo access Team permissions
Administrators Admin Administer team, Create repositories
Developers 1 Read Create repositories
Developers 2 Read Create repositories
Developers 3 Read Create repositories
Developers 4, Developers 5, etc.

Repository scenario for user group example:

Repo 1

Paula (part of Administrators) creates Repo 1.

  • She gives Developers 1 Write access.
  • Developers 1 and 2 have default Read access.

Repo 2

Paula (part of Administrators) creates Repo 2.

  • She gives Developers 2 Write access.
  • Developers 1 and 2 have default Read access.

Repo 3

Dave (part of Developers 3) creates Repo 3.

  • He has automatic Admin access on the repo he created.
  • He gives Developers 3 Write access.
  • Developers 1 and 2 have default Read access.

Medium-size team with temporary contractors

When your team is made up of full-time developers and/or temporary contractors, you may need to give different permissions to each group. For example, you can specify default access for no one in the contractors group. However, as they need access to repositories, you can go into that repository and turn on write or read access for the group that needs it. This scenario could also include more developer or external groups.

Example user groups for a medium-size team with temporary contractors:

Group name Default repo access Team Permissions
Administrators Admin Administer team, Create repositories
Developers Write Create repositories
External group None None

Repository scenario for user group example:

Repo 1

Will (part of Administrators) creates Repo 1.

  • Developers group has default Write access.

Repo 2

Julie (part of Developers) creates Repo 2.

  • She has automatic Admin access on the repo he created.
  • She gives External group Read access.
  • Developers group has default Write access.

Repo 3

Steve (part of Administrators) creates Repo 3.

  • He gives External group Write access.
  • Developers group has default Write access.

Medium-size team with non-developer users

If you don't need to place different permissions on different groups of developers, another way to set up your team's user groups is by roles. In this case, you'll most likely have less overlap between groups. You may also have very different access levels between groups if you want one group, for example developers, to have more access than other groups. This scenario could also include more users and groups.

Example user groups for a medium-size team with non-developers:

Group name Default repo access Team permissions
Administrators Admin Administer team, Create repositories
Developers Write Create repositories
Designers Read None
QA engineers Read None

Repository scenario for user group example:

Repo 1

Paul (part of Administrators) creates Repo 1.

  • Developers group has default Write access.

Repo 2

Julie (part of Developers) creates Repo 2.

  • She has automatic Admin access on the repo he created.
  • She removes access for Designers and QA engineers.
  • Developers group has default Write access.

 

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport