{"id":3903,"date":"2026-04-22T18:20:18","date_gmt":"2026-04-22T18:20:18","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/04\/22\/optimizing-git-policy-management-at-scale\/"},"modified":"2026-04-22T18:20:18","modified_gmt":"2026-04-22T18:20:18","slug":"optimizing-git-policy-management-at-scale","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/04\/22\/optimizing-git-policy-management-at-scale\/","title":{"rendered":"Optimizing Git policy management at scale"},"content":{"rendered":"

With just a single improvement in the REST API of Azure DevOps, we achieved a massive reduction in CPU usage and execution time when managing Git policies: 2x less CPU and 10-15x faster execution!<\/p>\n

This change is already available to all users of Azure DevOps<\/a>, and it\u2019s time to share a bit more detail: the background, what the change is, and how it helped us improve the performance.<\/p>\n

You may find this article useful if you maintain automation that manages Git policy configurations in Azure Repos<\/a> using REST API.<\/p>\n

Git policy governance at a big enterprise<\/h2>\n

Git policies are crucial for maintaining high quality of code and preventing malicious changes. They define rules enforced before code can land in repos and protected branches.<\/p>\n

Azure Repos has a rich policy engine that lets you configure things like a minimum number of reviewers, specific reviewers who must sign off when certain parts of the code are updated, checking for credentials and secrets on push, and much more.<\/p>\n

When the number of products, services and repos outgrows a certain point, ensuring the right policies are configured becomes a challenge. Human errors are unavoidable: it\u2019s very easy to misconfigure something, for example, the service\u2019s behavior when follow-up changes are pushed to an already approved pull request. Even if the initial state across the repos is correct, configuration often drifts over time when managed manually.<\/p>\n

Screenshot from Azure Repos UI showing \"Require a minimum number of reviewers\" policy that is configured to require at least one approval on the last iteration when new changes are pushed<\/a><\/p>\n

Microsoft offers a wide range of products. Our own code is exclusively hosted in Azure Repos and GitHub, across hundreds of thousands of Git repos, ranging from tiny polyrepos to the largest Git monorepos in the world.<\/p>\n

For these reasons, we and many other big enterprises rely on the REST API in Azure DevOps and GitHub to audit and mitigate policy misconfiguration and drift across the entire portfolio of repos. A dedicated service defines the target state of policies and automatically updates them when the actual state drifts from the target.<\/p>\n

Let me walk you through how the policies are stored and retrieved.<\/p>\n

How policies relate to projects, repos and branches<\/h2>\n

There are two types of Git policies in Azure Repos: push and branch policies. They can also be called repository and pull request policies.<\/p>\n

Push policies define the rules of what can enter repos and what cannot, no matter the branch. For example, if someone is trying to push new commits containing any secrets, such a push is rejected, even when pushed to a user branch.<\/p>\n

Branch policies, on the other hand, protect specific branches (like main<\/code>) and require all changes to go via pull requests. For example, they can enforce that code builds and all the tests are green before letting a change land on a protected branch.<\/p>\n

In short, different types of policies affect either entire repos or branches inside them.<\/p>\n

\"Visualization<\/a><\/p>\n

The policy engine also supports different scopes and inheritance. You can define a policy for a specific branch main<\/code> in a specific repository, or you can configure a policy that will affect all branches matching releases\/*<\/code> in all repos in a project. The support of cross-repo policies and glob patterns partially solves the maintenance burden described earlier, but is not enough, especially when the repos are spread across many different projects and Azure DevOps organizations.<\/p>\n

Two kinds of policies and support of inheritance define the architecture of how the policies are stored.<\/p>\n

Each project has its own logical container for the policies, instead of each repo or branch having its own container. This helps to power cross-repo policies as well as support branch glob patterns like releases\/*<\/code>.<\/p>\n

With that, all the policy configurations are linked to a specific project, but not a repo or branch. Then how does the engine know which ones to check for a specific operation, like a push or PR completion attempt? This is where the Scope<\/code> field comes into play.<\/p>\n

Policy scope<\/h2>\n

This is a simple string that specifies where in the inheritance hierarchy a given policy is defined<\/em>. It contains one or two parts separated by a colon:<\/p>\n