Branch Policies als Code in Azure DevOps lassen sich als deklarativ gepflegte Konfiguration verwalten statt nur per Klick in der Oberfläche. Dafür nennt Microsoft für Azure Repos die az repos policy-Befehle und die REST API; Quelle: Microsoft Learn, „Branch policies“ sowie „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026.
Eine Branch Policy ist eine Regel für einen Ziel-Branch wie main. Ein Ziel-Branch ist der Branch, in den ein Pull Request zusammengeführt werden soll.
Für den Betrieb ist das vor allem dann nützlich, wenn Sie Regeln nicht je Repository einzeln nachpflegen wollen. Änderungen werden damit nachvollziehbarer, wiederholbar und besser in einen Review-Prozess eingebettet.
Dieser Beitrag betrachtet Azure DevOps Services. Im Mittelpunkt stehen drei praktische Fragen:
- Wann die CLI ausreicht,
- wann die REST API mehr passt,
- und wie Sie Abweichungen von einer gewünschten Baseline erkennen.
Warum Policies als Code konfigurieren
Der Ausgangspunkt ist nüchtern: In Azure Repos sind Branch Policies für Mindestanzahl an Reviewern, verknüpfte Work Items, Kommentarauflösung, erlaubte Merge-Typen, Build Validation, Status Checks und automatisch einbezogene Reviewer jeweils standardmäßig ausgeschaltet. Das dokumentiert Microsoft Learn in „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026.
Genau deshalb lohnt sich ein Ansatz „als Code“ oder als deklarativ gepflegte Konfiguration. Sie rollen dieselben Regeln über viele Repositories hinweg konsistent aus, können Änderungen im Pull-Request-Review nachvollziehen und wenden die gewünschte Baseline nach Projektneuanlagen erneut an, statt jede Einstellung wieder durch die Oberfläche zu klicken.
Für main ist der Governance-Aspekt meist der wichtigste. Microsoft empfiehlt in seiner Sicherheitsbaseline unter anderem:
- die Berechtigungen zum Umgehen von Policies beim Abschließen von Pull Requests und beim direkten Push auf eine kleine Admin-Gruppe zu beschränken,
- mindestens zwei Reviewer zu verlangen,
- Reviewer für sensible Pfade automatisch einzubeziehen,
- verknüpfte Work Items zu prüfen,
- Build Validation zu setzen,
- und Kommentarauflösung zu verlangen.
Quelle dafür ist Microsoft Learn, „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026. Wenn Sie den Punkt zu Ausnahmen sauber fassen möchten, ist der Beitrag zu Bypass-Berechtigungen der naheliegende nächste Schritt.
Wichtig ist dabei die Einordnung der Merge-Typen: Diese Einstellung dient laut Microsoft der Historien-Governance, nicht einer direkten Sicherheitskontrolle. Wenn Ihr Audit-Modell auf die genaue Commit-Reihenfolge angewiesen ist, empfiehlt Microsoft Merge-Commit-Strategien statt Squash; ebenfalls Quelle: „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026.
Policies als Code helfen außerdem gegen stilles Auseinanderlaufen zwischen Projekten. Wenn ein Repository eine erforderliche Statusprüfung hat und ein anderes nicht, fällt das in der UI oft erst spät auf. Falls Sie die einzelnen Policy-Typen und ihre Wirkung zuerst im Detail einordnen möchten, lesen Sie die Erklärung der Branch Policies.
Die az repos policy-Befehle im Überblick
Die az repos policy-Befehle passen vor allem dann, wenn Sie Policies gezielt setzen oder ändern wollen, ohne dafür erst ein eigenes Tool zu bauen. Gemeint ist hier die Azure DevOps CLI: eine Befehlszeilen-Erweiterung, mit der Sie Azure-DevOps-Funktionen skriptbar ansprechen.
Praktisch ist das für wiederkehrende Standardfälle, zum Beispiel:
- ein neues Repository auf einen vorgegebenen Mindeststandard zu bringen,
- für einen Ziel-Branch dieselben Policy-Arten mehrfach auszurollen,
- oder einzelne Einstellungen nach einem internen Änderungsbeschluss kontrolliert anzupassen.
Der Nutzen liegt weniger in „mehr Funktion“ als in klarer Ausführung. Sie übergeben bekannte Parameter, führen den Schritt reproduzierbar aus und können ihn in bestehende Betriebsabläufe einhängen. Für Teams mit vielen gleichartigen Repositories ist das oft der einfachste Einstieg in Policies als Code.
Weniger gut passt die CLI, wenn Ihr Soll-Zustand erst aus mehreren Quellen zusammengesetzt wird oder wenn Sie Abweichungen systematisch bewerten wollen. Sobald Inventarisierung, Quervergleiche oder eigene Freigabelogik hinzukommen, wird die Arbeit über die REST API meist passender.
Für die CLI lohnt sich deshalb ein enger Zuschnitt:
- Standards setzen,
- klar benannte Änderungen ausrollen,
- Ergebnisse protokollieren,
- und Ausnahmen bewusst separat behandeln.
So bleibt der Befehlsweg überschaubar und wartbar, statt schrittweise ein halbes Governance-System in Skripte zu verlagern.
REST API als Alternative
Die REST API wird interessant, sobald Ihre Policy-Verwaltung Teil eines größeren Betriebsmodells wird. Dann geht es nicht mehr nur darum, einzelne Regeln zu setzen, sondern um Lesen, Vergleichen und gezieltes Nachführen. Microsoft nennt dafür die REST API ausdrücklich in Microsoft Learn, „Branch policies“ sowie „Securely use Git pull requests and branch policies to protect your important branches“, gelesen am 01.11.2026.
Ein praktischer Vorteil liegt in der vollständigen Erfassung des Ist-Zustands. Sie können Richtlinien projekt- und repositoryübergreifend inventarisieren und daraus einen belastbaren Vergleich mit Ihrem Soll-Zustand ableiten. Inventarisieren heißt hier: vorhandene Einstellungen systematisch erfassen, statt sie nur stichprobenartig in der Oberfläche zu prüfen.
Das passt vor allem, wenn Sie Fragen beantworten müssen wie:
- Welche Repositories weichen von der Baseline ab?
- Wo fehlt eine bestimmte Policy-Art noch vollständig?
- Welche Einstellungen wurden außerhalb des vorgesehenen Änderungswegs angepasst?
- Welche Projekte brauchen wegen anderer Schutzbedarfe bewusst eine Ausnahme?
Nützlich ist die API auch, wenn Sie die Feinheiten einzelner Richtlinien gezielt auswerten wollen. Bei der Reviewer-Policy gehören dazu laut Microsoft Learn, „Branch policies“, gelesen am 01.11.2026, Optionen wie „Allow requestors to approve their own changes“, „Prohibit the most recent pusher from approving their own changes“ oder „Require at least one approval on the last iteration“. Gerade diese Details entscheiden in der Praxis oft stärker über die Wirkung als der bloße Hinweis, dass eine Reviewer-Policy existiert.
Für die Betriebsseite ist die REST API deshalb weniger ein Ersatz für gute Standards als ein Werkzeug für Transparenz, Auswertung und kontrollierte Änderung.
Drift Detection und Review von Änderungen
Der saubere Zielzustand ist nicht, Policies einmal zu setzen und dann zu vergessen. Sinnvoller ist ein Modell, in dem Sie regelmäßig gegen einen definierten Soll-Zustand prüfen. „Drift“ meint hier die Abweichung zwischen der gewünschten und der tatsächlich gesetzten Konfiguration.
Ein praxistauglicher Ablauf besteht aus drei Schritten:
- Ist-Zustand auslesen,
- mit der Baseline vergleichen,
- Abweichungen nachvollziehbar in einen Review-Prozess geben.
Für diesen Soll-Zustand eignet sich eine versionierte Beschreibung nach Repository-Klasse oder Schutzstufe. Typische Zuschnitte sind etwa main, Release-Branches oder Repositories mit besonders sensiblen Codepfaden. Versioniert heißt hier: Die gewünschte Konfiguration wird in einem nachverfolgbaren Stand gepflegt, damit Änderungen später eindeutig nachvollziehbar bleiben.
Reviewbar wird das Thema erst dann wirklich, wenn UI-Änderungen nicht der Normalfall sind. Besser ist, Anpassungen an der Baseline per Pull Request vorzunehmen. So sehen Plattform-, Security- und Repository-Verantwortliche gemeinsam, welche Schutzwirkung sich ändert und welche Ausnahme bewusst beschlossen wurde.
Besondere Aufmerksamkeit verdienen Optionen, deren Wirkung in der Oberfläche leicht untergeht. Microsoft nennt in „Branch policies“, gelesen am 01.11.2026, unter anderem Feinheiten wie die Frage, ob bei neuen Pushes mindestens eine Freigabe auf der letzten Iteration nötig ist oder ob alle Freigaben zurückgesetzt werden.
Auch die Kommentarauflösung sollte in diesem Modell nicht nur als gesetzte Policy verstanden werden, sondern als eigener Prüfschritt vor dem Abschließen eines Pull Requests. Die Policy-Art nennt Microsoft Learn in „Branch policies overview“, gelesen am 01.11.2026. Offene Review-Threads sind damit nicht bloß „noch etwas Diskussion“, sondern ein sichtbarer Teil Ihrer Merge-Prüfung.
Wenn Sie zusätzlich PR-Statuswerte verwenden, trennen Sie technische Prüfungen sauber vom Reviewer-Votum: Menschliche Freigaben bleiben menschliche Freigaben, maschinelle Ergebnisse landen in Status Checks.
Häufige Fragen, die Sie dazu stellen könnten
Reicht eine Kommentarfunktion als Pflichtprüfung im Pull Request?
Nein. Für den Betrieb zählt nicht, ob etwas „Review“ heißt, sondern ob Azure Repos es als Richtlinie auswerten kann. Eine Kommentarfunktion gibt Hinweise im Pull Request, ersetzt aber weder eine erforderliche Freigabe noch automatisch einen blockierenden Status.
Für eine belastbare Trennung hilft ein einfaches Modell:
- Menschen geben Review-Voten ab,
- technische Prüfungen melden Status,
- Diskussionen werden vor Abschluss bereinigt.
Wenn Sie diese Trennung im Prozess sauber aufbauen wollen, ist der Beitrag zu PR-Status als Richtlinie der passende nächste Schritt.
Wie halten Sie den Pull-Request-Ablauf auch organisatorisch sauber?
Nützlich ist ein Ablauf, der schon vor dem eigentlichen Review Ordnung schafft. Dazu gehören Entwürfe für unfertige Änderungen, klar angelegte Pull Requests und ein sichtbarer Umgang mit offenen Diskussionen. Ein Entwurf ist ein Pull Request, der noch nicht zur inhaltlichen Prüfung gedacht ist.
Praktisch sind dabei drei Fragen:
- Ist die Änderung überhaupt reviewbereit?
- Ist der Zweck des Pull Requests klar beschrieben?
- Sind offene Threads wirklich abgearbeitet?
Dafür passen die Beiträge zu Draft-Pull-Requests, Pull Requests sauber anzulegen und offenen Threads vor dem Abschluss.
Wann sind Service Hooks statt weiterer Policies sinnvoll?
Immer dann, wenn Sie Ereignisse aus Pull Requests in andere Abläufe geben wollen. Ein Service Hook ist eine Ereignisbenachrichtigung, die Azure DevOps bei bestimmten Änderungen auslöst.
Das ist vor allem nützlich für nachgelagerte Reaktionen, etwa Benachrichtigung, Dokumentation oder die Übergabe an eigene Prüfstrecken. Für die Einordnung hilft der Beitrag zu Service Hooks für Pull Requests.
Was ist bei agentischer PR-Automatisierung zusätzlich zu prüfen?
Hier geht es schnell um Datenschutz, Auftragsverarbeitung, DORA, NIS2 und Mitbestimmung. Diese Fragen sollten Sie mit Ihrer Rechtsabteilung oder dem Datenschutzbeauftragten prüfen.
Wenn Sie einen entstehenden Ansatz für Azure DevOps Services beobachten möchten: Polier von ballmüller solutions ist in Entwicklung und noch nicht verfügbar. Den jeweils beschriebenen Stand finden Sie auf der Sicherheits- und Datenseite, auf der Paket- und Anmeldeseite, auf der Seite für spätere Messwerte und im öffentlichen Änderungsprotokoll.
Nächster Schritt
Beginnen Sie nicht mit allen Repositorys zugleich. Sinnvoller ist ein kleiner, verbindlicher Standard für wenige Branch-Klassen, den Sie technisch eindeutig beschreiben und organisatorisch klar verantworten.
Bewährt hat sich dafür ein kurzer Arbeitsrahmen:
- Schutz-Branch und Ausnahmekreis festlegen,
- Policy-Änderungen nur über einen geregelten Änderungsweg zulassen,
- Verantwortlichkeiten für Prüfung und Freigabe benennen,
- die Wirksamkeit der Baseline in festen Abständen kontrollieren.
So wird aus einzelnen Schaltern in Azure Repos ein wartbarer Betriebsgegenstand.
Wenn Sie agentische PR-Automatisierung in Azure DevOps Services beobachten, gilt mit Stand 01.11.2026: Polier von ballmüller solutions ist in Entwicklung und noch nicht verfügbar.