Project113

Example: Multi-Team Repository

Configure a repository shared by frontend, backend, and DevOps teams with appropriate permissions for each group.

Goal

  • Frontend, backend, and DevOps teams each have their own group and role.
  • DevOps team can manage CI/CD pipelines and deployment configs.
  • Everyone can read the entire repository.
  • All changes to master go through review, with reviewers auto-assigned based on the paths changed.

Note: the platform does not restrict writes by file path. Write access is controlled per repository through roles, groups, and audiences. File patterns only apply to reviewer auto-assignment, not to who can push.

Step 1: Create Groups

Create three groups in your repository settings:

  • frontend-team — Add frontend developers as members.
  • backend-team — Add backend developers as members.
  • devops-team — Add DevOps engineers as members.

Step 2: Create Roles

Create roles with different permission levels:

  • reader — Can read the repository. Assigned to all groups.
  • developer — Can read, push, and create change requests. Assigned to frontend and backend teams.
  • devops — Can manage CI/CD, secrets, and repository settings. Assigned to the DevOps team.

Step 3: Assign Roles to Groups

Assign the reader role to all groups. Then assign the developer role to the frontend and backend groups, and the devops role to the DevOps group.

Step 4: Set Up Branch Policies

Create ref policies for master that block force pushes and restrict merges to reviewed change requests. Use CR reviewer policies to auto-assign reviewers based on the paths changed. File patterns in reviewer policies control which team gets asked to review, but they do not restrict who can push to the repository.

Step 5: Configure Audiences

Set the public audience to allow read access so anyone in the organization can browse the repository.

Result

  • Each team has a role and group matching its responsibilities; access is role-based, not path-based.
  • DevOps can manage infrastructure without touching application code.
  • All changes to master go through code review.
  • The repository is browsable by anyone in the organization.