Centrilogic

Centrilogic is a global provider of IT transformation solutions that empower organizations to…

Follow publication

CODEOWNERS in Azure Repos?

Many of you are probably familiar with the CODEOWNERS file in GitHub.

In case you are not familiar, lets start with a little information on the subject.

CODEOWNERS

In GitHub you can create a file called CODEOWNERS in your repo to specify who the code owners are for this repo. With this file in place and branch protection set to use CODEOWNERS.

Branch Protection

The people or teams listed in this file are automatically requested to review any PR’s on this repo. You can have multiple Code Owners and code owners for different folders/files/file extensions.

For example by adding this content to the CODEOWNERS file in the main branch you are saying, to merge into the main branch the developer Team must approve the PR. However if there is a change to any file with a .sql extension someone from the dba team needs to approve.

*  @myorg/developer
*.sql @myorg/dba

You can learn more about GitHub CODEOWNERS here.

Azure Repos

Azure Repos does not have a CODEOWNERS file, however we can still accomplish the same thing using an Azure Repos branch policy called Automatically included reviewers.

Note: Branch Policies in Azure Repos are the same as Branch Protection in GitHub. It’s how we define the rules that govern how can we push code into a branch.

Branch Policies in Azure Repos?

In Azure Repos go to Project Settings — Repos — Repositories, this will show a list of all the repos in your Team Project.

Select the Repo you want to add a Branch Policy for, then switch to the Policies tab.

The top half of the page is Repository Policies. We want Branch Policies, which is at the bottom of the page. Scroll down and select the branch you want to update.

Another way to get here: Under Repos, select your repo then select Branches on the navigation bar on the left. From the list of branches click on the context menu for the branch you want, and select Branch Policies.

Automatically included reviewers

On the branch policies page, we are interested in the section under the heading Automatically included reviewers.

Branch Policies

The plus button on the right lets you add rules.

In the example below, I’m defining a reviewer policy that ensures when a file matching *.sql is changed, someone from the DBA team must approve any PR containing this change, before changes can be merged into this branch.

Reviewer Policy

Each rule added is similar to an entry in the CODEOWNERS file in GitHub.

Like the CODEOWNERS file I can add multiple reviewers based on different folders and file types.

Reviewers

The above example is the GitHub CODEOWNERS equivalent of this:

*  @myOrg/developer
*.sql @myOrg/dba
azure-pipelines*.yml @myOrg/pipelines

If I make a change to any file other than azure-pipelines*.yml or a *.sql file the PR will require someone on the Developer team to approve.

However if a change is made to a pipeline.yml or sql file, the PR will require those teams as well.

You can find the official documentation for this policy here.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Centrilogic
Centrilogic

Published in Centrilogic

Centrilogic is a global provider of IT transformation solutions that empower organizations to realize their full digital potential. Armed with capabilities that span the stack, we build and manage end-to-end digital solutions that help companies reshape the role of their technolo

Dave Lloyd
Dave Lloyd

Written by Dave Lloyd

I have been writing software and teaching/coaching developers for 40 years. I love sharing knowledge and experience.

No responses yet

Write a response

Not sure I agree that this doesn't apply to project work. We run about 20 software development projects in parallel a week. There is no possible way we could do this by "taking orders" for features. We start every engagement by understanding the…

--

I am going to sound a bit negative, but I read a lot of these types of articles, and after 30 years of working in Software it never fails to amaze me that these generalized, "rational", "pragmatic" solutions still get spoken off as the great panacea.

--

Hi, Ryan Dawson,it's my great honor to read your article Too Much Product Roadmap May Kill You — Here’s a Better Strategy. Can i translate it into Chinese so that more people can read it ?
I will attach the original author and the original link. thank you !

--