Pflicht-Reviewer in Azure Repos setzen Sie richtig ein, indem Sie fachlich notwendige Personen oder Gruppen gezielt einbinden und davon trennen, wer pushen, mergen und Regeln umgehen darf. So wird der Pull Request an den richtigen Stellen geprüft, ohne Berechtigungen und Review-Pflichten zu vermischen.
In Azure Repos greifen Pflicht-Reviewer nur dann sauber, wenn Sie den Zweck der Regel vorab festlegen: Geht es um Fachprüfung, um Schutz sensibler Änderungen oder um einen geregelten Freigabepfad auf Haupt-Branches? Branch Policies wirken auf den Ziel-Branch eines Pull Requests und sollten deshalb aus der Schutzbedarfs-Sicht des Ziel-Branches geplant werden, nicht aus Gewohnheiten einzelner Teams.
Für den Einstieg reicht meist diese Reihenfolge:
- kritische Ziel-Branches bestimmen
- reviewpflichtige Rollen benennen
- sensible Änderungsbereiche abgrenzen
- Ausnahmen knapp halten
Azure DevOps Services und Azure DevOps Server folgen dabei demselben Grundprinzip. Unterschiede im Detail sollten Sie später je nach Produktstand Ihrer Umgebung prüfen.
Pflicht-Reviewer versus Mindestzahl an Reviewern
Der Kernunterschied ist schlicht: „Require a minimum number of reviewers“ verlangt eine bestimmte Zahl an genehmigenden Stimmen, benennt aber keine konkreten Personen. „Automatically included reviewers“ fügt dagegen bestimmte Personen oder Gruppen automatisch zu einem Pull Request hinzu. Beides ergänzt sich, ersetzt sich aber nicht. Microsoft beschreibt diese Richtlinien in den Branch-Policy-Seiten und in den Sicherheitshinweisen für Repositories und Pull Requests, jeweils gelesen am 01.11.2026.
Für den Betrieb ist die Folge wichtig: Wenn Sie nur eine Mindestzahl setzen, ist nicht sichergestellt, dass bei Änderungen an IAM-, Netzwerk-, Plattform- oder Pipeline-Dateien auch wirklich die zuständigen Rollen im Review landen. Dann können formal genug Stimmen vorliegen, obwohl fachlich die falschen Personen geprüft haben.
Zur Reviewer-Policy gehören mehrere Detailoptionen, die Sie bewusst entscheiden sollten:
- „Allow requestors to approve their own changes“
- „Prohibit the most recent pusher from approving their own changes“
- „Allow completion even if some reviewers vote to wait or reject“
- bei neuen Pushes „Require at least one approval on the last iteration“
- außerdem das Zurücksetzen von Freigaben oder sämtlichen Reviewer-Votes nach Änderungen
Eine Iteration ist der Stand eines Pull Requests nach neuen Commits oder Updates. Gerade diese Optionen entscheiden darüber, ob ein Review eher als formale Hürde oder als belastbarer Freigabepfad wirkt.
Microsoft nennt für Haupt-Branches in „Secure repositories in Azure Repos and GitHub“, gelesen am 01.11.2026, als Sicherheits-Baseline unter anderem: mindestens zwei Reviewer, verknüpfte Work Items, Build Validation, Kommentarauflösung und automatisch hinzugefügte Reviewer für sensible Pfade.
Wichtig ist die Einordnung: Solche Policies sind Governance-Entscheidungen. Sie steuern Freigabepfade, ersetzen aber keine sauberen Berechtigungen auf Repository- und Branch-Ebene. Wer direkt pushen oder Regeln umgehen darf, ist deshalb ein eigener Themenblock.
Für größere Organisationen gilt praktisch: Planen Sie Mindestzahl und Pflichtrollen zusammen. Sonst erfüllen Teams die Regel auf dem Papier, während inhaltlich nicht die richtigen Stellen prüfen.
Automatisch hinzugefügte Reviewer mit Path-Filtern
Path-Filter machen aus der Reviewer-Regel ein Zuständigkeitswerkzeug. Die Policy „Automatically included reviewers“ fügt Personen oder Gruppen nur dann in einen Pull Request ein, wenn neben dem Ziel-Branch auch bestimmte Pfade betroffen sind. Microsoft nennt diese Policy in „Branch policies overview“ und „Branch policies“, jeweils gelesen am 01.11.2026.
Der praktische Wert liegt in sauber geschnittenen Verantwortungsbereichen. Nicht jede Änderung braucht dieselben Prüfer. Relevant wird das vor allem dort, wo ein Repository Produktcode und zentrale Betriebsartefakte zusammenführt.
Geeignet sind Path-Filter typischerweise für:
- Infrastruktur-Definitionen
- Pipeline-Dateien
- Verzeichnisse mit Rollen-, Rechte- oder Richtlinienbezug
- zentrale Vorlagen und gemeinsam genutzte Konfiguration
Damit die Regel verlässlich greift, muss die Ordnerstruktur diese Zuständigkeiten auch abbilden. Wenn sensible Dateien über viele Stellen verteilt sind, steigt der Pflegeaufwand, und die Zuordnung wird schwerer nachvollziehbar. Ein Pfad-Filter ist technisch präzise, organisatorisch aber nur so gut wie die Namens- und Ablagekonventionen im Repository.
Für den Betrieb heißt das: Legen Sie die Pfade knapp fest, dokumentieren Sie Ausnahmen sparsam und prüfen Sie die Regeln nach Umbenennungen oder Reorganisationen erneut. Eine breit geratene Zuordnung erzeugt unnötige Reviews; eine zu enge übersieht Änderungen.
Wenn Sie den gesamten Regelbaukasten noch einmal einordnen möchten, hilft die Systematik der Branch Policies. Für größere Umgebungen ist außerdem relevant, dass sich Policies laut Microsoft Learn in „Branch policies“, gelesen am 01.11.2026, auch per „az repos policy“ oder über die API verwalten lassen; den technischen Rahmen dazu finden Sie bei Pull Requests per REST API.
Sensible Pfade: Infrastruktur, Authentifizierung, Pipelines
Als sensible Pfade gelten in vielen Repositories vor allem vier Bereiche:
- Infrastrukturdefinitionen
- Konfiguration für Authentifizierung und Autorisierung
- Build- und Release-Pipelines
- sicherheitsrelevante Vorlagen und zentrale Konfigurationsdateien
Gerade dort sollten nicht nur „irgendwelche“ Reviewer stimmen. Änderungen in diesen Pfaden betreffen oft nicht nur eine Fachfunktion, sondern Berechtigungen, Bereitstellung, Geheimnisnutzung oder die Lieferkette des Codes. Ein kleiner Eingriff an einer Pipeline oder Rollenlogik kann deshalb weiter reichen als eine gewöhnliche Änderung im Produktcode.
Zugleich sollten Sie sensible Pfade nicht zu breit schneiden. Wenn zu viele Ordner unter dieselbe Reviewer-Regel fallen, landen sehr viele Pull Requests bei denselben Stellen. Das vergrößert Review-Queues und senkt oft die Signalqualität, weil Prüfer immer häufiger Änderungen sehen, für die ihre besondere Zuständigkeit gar nicht gebraucht wird.
Für besonders kritische Verzeichnisse ist eine Kombination mehrerer Schutzmechanismen oft sinnvoll: automatisch hinzugefügte Reviewer, Mindestzahl an Reviewern, Build Validation, verknüpfte Work Items und Kommentarauflösung. Diese Policy-Arten nennt Microsoft Learn in „Branch policies overview“ sowie „Secure repositories in Azure Repos and GitHub“, jeweils gelesen am 01.11.2026. Wenn Sie Status-Prüfungen ergänzend einsetzen wollen, finden Sie die Einordnung in unserem Beitrag zu PR-Status als Richtlinie.
Die Policy „Limit merge types“ sollten Sie davon getrennt betrachten: Sie steuert die Historie, ist laut Microsoft in „Secure repositories in Azure Repos and GitHub“, gelesen am 01.11.2026, aber kein direkter Sicherheitsmechanismus. Wenn Ihr Audit-Modell auf die genaue Commit-Folge angewiesen ist, kann Microsoft Merge-Commit-Strategien statt Squash nahelegen. Die Unterschiede dazu haben wir in einem eigenen Überblick zu Merge-Strategien zusammengefasst.
Wichtig im Betrieb: Prüfen Sie diese sensiblen Pfade nach Reorganisationen im Repository erneut. Ordnerumzüge, neue Verzeichnisse oder umbenannte Vorlagen fallen sonst leicht unbemerkt aus Ihren Regeln heraus.
Fallstricke: Gruppen, Unverfügbarkeit, eigene Freigabe
Schwieriger als die Technik ist oft die Betriebsregel dahinter. Wenn Sie Gruppen als Pflicht-Reviewer eintragen, muss intern dennoch klar sein, wer Reviews annimmt, wer vertreten darf und wann eskaliert wird. Sonst steht im Pull Request zwar die richtige Gruppe, aber niemand fühlt sich zuständig.
Typische Bruchstellen sind:
- Gruppen mit zu breitem Zuschnitt
- ungepflegte Mitgliedschaften nach Teamwechseln
- fehlende Vertretung bei Urlaub oder Bereitschaft
- stillschweigende Ausnahmen bei Zeitdruck
Gerade bei geschützten Ziel-Branches sollten Sie diese Fragen vorab klären und nicht erst im stockenden Pull Request.
Heikel sind außerdem die Freigabeoptionen der Reviewer-Policy. Microsoft nennt in „Branch policies“ (gelesen am 01.11.2026) unter anderem „Allow requestors to approve their own changes“, „Prohibit the most recent pusher from approving their own changes“ und für neue Pushes „Require at least one approval on the last iteration“. Eine Iteration ist der Stand eines Pull Requests nach weiteren Commits oder Updates. Wenn Freigaben nach neuen Pushes nicht passend behandelt werden, bleibt leicht ein altes „Approve“ an einem inzwischen geänderten Stand hängen.
Für den Alltag ist deshalb weniger die Frage wichtig, ob eine Policy existiert, sondern ob sie zu Ihrem Freigabemodell passt:
- Darf der Ersteller überhaupt als gültige Stimme zählen?
- Soll der letzte Push eine erneute unabhängige Prüfung auslösen?
- Was passiert bei Abwesenheit eines Pflicht-Reviewers?
Vieles davon lösen Sie nicht mit einer weiteren Ausnahme, sondern mit einer klaren PR-Vorlage mit Zuständigkeiten.
Häufige Fragen
Reichen Pflicht-Reviewer allein für einen sauberen Freigabepfad?
Nicht immer. Pflicht-Reviewer sorgen dafür, dass bestimmte Personen oder Gruppen im Pull Request auftauchen. Ob der Freigabepfad im Alltag trägt, entscheidet aber oft an angrenzenden Regeln.
Wichtig sind vor allem drei Punkte:
- Wer darf Policies umgehen?
- Welche Stimmen bleiben nach neuen Pushes gültig?
- Welche Ziel-Branches sind überhaupt geschützt?
Gerade auf Haupt-Branches entsteht sonst leicht ein formaler Review-Prozess, der in Sonderfällen doch umgangen wird. Microsoft empfiehlt in „Secure repositories in Azure Repos and GitHub“, gelesen am 01.11.2026, für main unter anderem eine kleine Admin-Gruppe für die Berechtigungen zum Umgehen von Policies beim Abschließen von Pull Requests und beim Pushen.
Wann helfen Pflicht-Reviewer nicht weiter, obwohl sie korrekt eingerichtet sind?
Ein typischer Fall sind Pull Requests mit Merge-Konflikten. Dann ist nicht die Reviewer-Regel das Nadelöhr, sondern der technische Zustand des Pull Requests. Ein Merge-Konflikt bedeutet, dass Quell- und Ziel-Branch dieselben Stellen unterschiedlich ändern und Git das nicht automatisch zusammenführen kann.
Wenn Reviews dadurch stocken, sollten Sie zuerst den Konflikt bereinigen und erst dann über zusätzliche Review-Regeln nachdenken. Für die praktische Seite hilft oft ein sauberer Ablauf zum Lösen von Merge-Konflikten.
Was sollten Sie bei KI-Review in Azure Repos zusätzlich prüfen?
Neben der Rolle im Freigabepfad auch den Betriebsrahmen. Microsoft Learn beschreibt in „Copilot code reviews“, gelesen am 01.11.2026, Grenzen wie nur aktive Pull Requests ohne Merge-Konflikte, Repository-Größe bis 10 GB sowie Obergrenzen bei geänderten Dateien und Änderungen. In „Copilot code reviews FAQ“, gelesen am 01.11.2026, weist Microsoft zudem darauf hin, dass die Datenresidenz nicht an die Datenresidenzgrenzen der Azure-DevOps-Organisation gebunden ist.
Für Datenschutz, DORA, NIS2 und Mitbestimmung ist das eine Prüffrage, keine pauschale Aussage. Klären Sie den geplanten Einsatz mit Rechtsabteilung, Datenschutzbeauftragten oder Betriebsrat.
Was ist bei Azure DevOps Server gesondert zu beachten?
Bei Server-Umgebungen sollten Sie nicht von demselben Funktionsstand wie in Azure DevOps Services ausgehen. Microsoft dokumentiert KI-Review für Azure DevOps Server nach den am 24.10.2026 geprüften und am 01.11.2026 erneut gelesenen Seiten nicht.
Wenn Ihre Organisation die Plattform grundsätzlich neu bewertet, hilft eher die größere Entscheidung zwischen Betriebsmodellen und Werkzeugpfaden als nur eine einzelne Reviewer-Regel. Dafür passt der Überblick zu Azure Repos oder GitHub.
Wer außerdem beobachten will, wie ein geplanter Coding-Agent mit bestehenden Branch Policies und PR-Status zusammenspielen soll: Polier ist in Entwicklung und am 01.11.2026 noch nicht verfügbar; den Stand finden Sie im öffentlichen Changelog.
Nächster Schritt
Setzen Sie Pflicht-Reviewer nicht als Einzelmaßnahme auf, sondern als überprüfbare Regel für besonders schutzbedürftige Ziel-Branches. Entscheidend ist am Ende weniger die Menge der Häkchen als eine klare Zuordnung: Wer muss fachlich prüfen, und an welchen Pfaden soll das zuverlässig greifen?
Zum Schluss noch der Blick nach vorn: Wenn Sie beobachten möchten, wie Polier mit bestehenden Policies zusammenspielen soll, finden Sie den geplanten Stand zu Sicherheit und Daten, zu Abo und Zugang und später zu gemessenen Ergebnissen aus Realruns. Polier ist in Entwicklung und am 01.11.2026 nicht verfügbar.