Code Review lässt sich teilweise automatisieren: Maschinen prüfen im Pull Request vor allem Regeln, die klar beschrieben, wiederholbar und für jede Änderung gleich auswertbar sind. Menschen bleiben für Absicht, Design, Auswirkungen und Risiko zuständig.
Für Teams mit Azure DevOps ist das vor allem eine Frage des Prüfmodells. Ein Pull Request bündelt Änderung, Diskussion und Freigaben vor dem Merge. Sinnvoll wird Automatisierung dort, wo Sie Kriterien vorab in Regeln übersetzen und in Branch Policies, Builds, Status Checks und Kommentare einordnen.
Hilfreich ist dabei diese Trennung:
- regelbasierte Prüfungen,
- KI-Hinweise,
- menschliche Entscheidung.
Wichtige Details liegen oft in den Einstellungen, etwa bei Pflicht-Reviewern oder bei Reviewer-Stimmen nach neuen Pushes.
Wenn Sie den Stand von Polier verfolgen möchten: Polier von ballmüller solutions ist in Entwicklung und am 01.11.2026 noch nicht verfügbar. Den Stand finden Sie im Changelog, Fragen zu Sicherheit und Daten mit Status und Datum auf der Übersichtsseite, vorläufige Angaben zu Paketen und Anmeldung auf der Preisseite; belastbare Messwerte würden erst nach realen Läufen unter Proof erscheinen.
Was Maschinen heute gut prüfen können
Maschinen sind im Pull Request dort nützlich, wo das Prüfergebnis eindeutig ausfällt: bestanden oder nicht bestanden. Das betrifft vor allem technische Mindestkriterien, die sich für jede Änderung gleich anwenden lassen.
Typische Beispiele sind:
- Build erfolgreich oder fehlgeschlagen,
- Tests bestanden oder fehlgeschlagen,
- statische Analyse mit klaren Regeln,
- bekannte Schwachstellen in Abhängigkeiten,
- Statusmeldungen aus angebundenen Prüfsystemen.
Ein Status Check ist dabei ein technisches Signal eines Dienstes an den Pull Request, etwa aus Build, Test oder einer externen Prüfung.
In Azure Repos ist dafür vor allem die Kombination aus Build validation und Status checks relevant. Beide gehören zu den Branch Policies; diese Richtlinien sind in Azure Repos standardmäßig ausgeschaltet und müssen bewusst gesetzt werden (Microsoft Learn, „Branch policies and branch policy settings“, gelesen am 01.11.2026; sowie „Branch policies overview“, gelesen am 01.11.2026).
Wichtig ist die Grenze: Solche Prüfungen bewerten, ob definierte Regeln eingehalten sind. Sie bewerten nicht, ob eine Änderung fachlich passend ist, ob ein Entwurf verständlich bleibt oder ob ein Risiko im gegebenen Kontext akzeptabel ist.
Für die Praxis heißt das: Formulieren Sie zuerst wenige, klare Mindestregeln für jeden Pull Request. Geeignet sind Regeln, die ohne Ermessensspielraum auskommen:
- baut die Änderung,
- laufen die vereinbarten Tests,
- liefern Scanner oder Analyzer einen festgelegten Status,
- liegt das Ergebnis rechtzeitig vor der Freigabe vor.
Wo Teams viele Repositories verwalten, lassen sich solche Standards nicht nur in der Oberfläche pflegen, sondern auch über az repos policy oder die REST API steuern (Microsoft Learn, „Branch policies and branch policy settings“, gelesen am 01.11.2026). Das ist vor allem für einheitliche Mindestprüfungen über mehrere Projekte hinweg relevant.
Was menschlich bleiben sollte: Design, Absicht, Risiko
Nicht jede gute Änderung ist an Regeln erkennbar. Im Pull Request gibt es Fragen, die erst mit Systemkenntnis, Produktverständnis und Verantwortung sauber beantwortet werden können.
Dazu gehören vor allem:
- passt die Lösung zur beabsichtigten Architektur,
- liegt die Änderung an der richtigen Stelle im System,
- bleiben Folgen für Betrieb, Wartung und Fehlersuche beherrschbar,
- sind Randfälle, Rückbau und spätere Erweiterungen mitgedacht,
- ist das Risiko für das betroffene System angemessen beurteilt.
Solche Punkte sind kontextabhängig. Ein Muster, das in einem Repository vernünftig ist, kann in einem anderen problematisch sein. Das gilt besonders bei Berechtigungen, Datenflüssen, Schnittstellen und Änderungen in sensiblen Modulen. Ein Werkzeug kann Auffälligkeiten markieren. Ob daraus ein tragfähiger Einwand wird, entscheiden Menschen.
Wichtig ist daher die Trennung zwischen Hinweis und Urteil. Ein Kommentar beschreibt eine Beobachtung oder Rückfrage. Die eigentliche Review-Entscheidung bleibt bei Personen, die Zielbild, Nebenwirkungen und Prioritäten der Änderung kennen.
Für kritische Branches empfiehlt Microsoft als Ausgangspunkt unter anderem: die Berechtigungen Bypass policies when completing pull requests und Bypass policies when pushing nur einer kleinen Admin-Gruppe zu geben, mindestens zwei Reviewer zu verlangen und Reviewer für sensible Pfade automatisch einzubeziehen (Microsoft Learn, „Secure repositories with branch policies and pull requests“, gelesen am 01.11.2026).
Kurz gesagt: Menschen reviewen nicht nur Code. Sie verantworten Absicht, Tragweite und Freigabe.
Pull Requests sinnvoll schichten statt alles in einen Review zu legen
Ein Pull Request wird leichter entscheidbar, wenn nicht alle Prüffragen im selben Schritt auflaufen. Sonst konkurrieren formale Mängel, offene Rückfragen und echte Freigabeentscheidungen in einer einzigen Diskussion.
Sinnvoll ist deshalb eine feste Reihenfolge je Branch:
- technische Nachweise,
- Klärung offener Punkte,
- Review-Entscheidung nach Teamregel.
Zur ersten Schicht gehören nur Dinge mit eindeutigem Ergebnis. In Azure Repos sind das vor allem Build validation und Status checks. Solche Prüfungen sollten früh sichtbar sein, damit Reviewer nicht Zeit in Änderungen investieren, die an Grundanforderungen scheitern.
Die zweite Schicht hält den Vorgang sauber. Dafür sind in Azure Repos besonders Check for linked work items und Check for comment resolution nützlich. So bleibt vor dem Abschluss erkennbar,
- wozu die Änderung gehört,
- welche Diskussionen noch offen sind,
- ob Rückfragen wirklich bearbeitet wurden.
Erst danach sollte die eigentliche Freigabe zählen. Bei Require a minimum number of reviewers steckt der relevante Teil oft in den Optionen: Dürfen Anfordernde selbst zustimmen? Darf der zuletzt Pushende freigeben? Sollen neue Pushes frühere Zustimmungen relativieren? Diese Details verändern den Review-Prozess stärker als die bloße Zahl der Reviewer (Microsoft Learn, „Branch policies and branch policy settings“, gelesen am 01.11.2026).
Wichtig für die Steuerung: Diese Policies sind in Azure Repos jeweils standardmäßig ausgeschaltet. Wer ein mehrstufiges Review-Modell will, muss es bewusst je Branch festlegen (Microsoft Learn, „Branch policies overview“ und „Branch policies and branch policy settings“, gelesen am 01.11.2026).
Wo KI-Review in Azure DevOps passt – und wo nicht
In Azure DevOps eignet sich KI-Review vor allem als kommentierende Zusatzprüfung im Pull Request. Sie passt dort, wo Sie Hinweise auf Auffälligkeiten, Unklarheiten oder mögliche Risiken sehen möchten, ohne daraus automatisch eine Freigabeentscheidung zu machen.
Für Azure Repos ist Copilot code review laut Microsoft in Public Preview verfügbar. Die Funktion kann pro Organization, Project oder Repository aktiviert, über einen Managed DevOps Pool ausgeführt, mit Custom Instructions gelenkt und auch automatisch gestartet werden. Seit Sprint 280 gibt es dafür die Aufwandstufen Lite und Balanced (Microsoft Learn, „Sprint 279 Update“ und „Copilot code reviews“, gelesen am 01.11.2026).
Für die Einordnung ist ein Punkt entscheidend: Das Ergebnis erscheint immer als Comment review. Damit zählt es nicht als erforderliche Reviewer-Freigabe und hält einen Merge nicht auf (Microsoft Learn, „Review pull requests“ sowie „Copilot code reviews“, gelesen am 01.11.2026).
Auch der Einsatzbereich ist begrenzt. Bewertet werden nur:
- aktive Pull Requests,
- Pull Requests ohne Merge-Konflikte,
- Repositories bis 10 GB,
- Änderungen mit bis zu 100 geänderten Dateien und 100 Änderungen.
Zusätzlich gelten Grenzen für parallele Reviews je Pull Request, je Organization und je Nutzer. Preview-Funktionen haben außerdem keine SLA und können sich ändern (Microsoft Learn, „Copilot code reviews“, gelesen am 01.11.2026).
Prüfbedarf besteht beim Datenpfad. Laut Microsoft Learn FAQ entspricht die Data Residency dieser Review-Funktion nicht den Data-Residency-Grenzen einer Azure-DevOps-Organisation; Verarbeitung kann also auch außerhalb der EU stattfinden. Laut FAQ werden Pull-Request-Inhalte nicht zum Training von Foundation Models verwendet; zur Aufbewahrung verweist Microsoft auf die Dokumentation des Dienstes (Microsoft Learn FAQ, „Copilot code reviews FAQ“, gelesen am 01.11.2026). Fragen zu Datenschutz, DORA, NIS2 oder Mitbestimmung sollten Sie mit einem Juristen oder dem Datenschutzbeauftragten klären.
Häufige Fragen, die Sie vor der Entscheidung klären sollten
Reicht ein Kommentar der KI für Governance und Audit aus?
Nicht automatisch. Für viele Teams zählt im Pull Request nicht nur der Hinweis selbst, sondern auch, wer eine Entscheidung trifft und welche Policy daran hängt. Ein Audit-Trail ist die nachvollziehbare Spur aus Regeln, Diskussion, Freigaben und Merge. Prüfen Sie deshalb getrennt:
- Welche Nachweise nur dokumentieren sollen
- Welche Nachweise den Merge wirklich steuern
- Welche Identität einen Status oder eine Freigabe setzt
Gerade in Azure Repos ist diese Trennung wichtig, weil Kommentare, Status und Reviewer-Stimmen unterschiedliche Funktionen haben.
Welche Rolle spielt die Merge-Strategie für Nachvollziehbarkeit?
Mehr, als oft angenommen. Limit merge types steuert laut Microsoft die Historie, ist aber kein direkter Sicherheitsmechanismus (Microsoft Learn, „Secure repositories with branch policies and pull requests“, gelesen am 01.11.2026). Ein Squash-Merge macht den Ziel-Branch oft kompakter, fasst aber die Commit-Folge des Quell-Branches zusammen. Wenn Ihr Nachweismodell auf der genauen Commit-Reihenfolge aufbaut, sollten Sie die Merge-Strategie bewusst prüfen statt sie nur aus Gewohnheit festzulegen.
Was heißt Public Preview für eine Auswahlentscheidung?
Vor allem: anders bewerten als einen regulären Plattformbaustein. Microsoft weist für Preview-Funktionen auf fehlende SLA und mögliche Änderungen hin (Microsoft Learn, „Copilot code reviews“, gelesen am 01.11.2026). Für Ihre Auswahl heißt das typischerweise:
- Grenzen und Ausschlüsse vorab prüfen
- keine Prozesspflicht allein auf Preview stützen
- Rollout, Betrieb und Support getrennt betrachten
Ändert sich die Lage auf Azure DevOps Server?
Kurzfristig eher nicht. Laut Microsoft-Dokumentation war Copilot code review dort am 24.10.2026 nicht verfügbar; Microsofts AI-Pfad zielt auf Azure DevOps Services. Auch die Azure DevOps MCP-Server unterstützten Azure DevOps Server an diesem Datum nicht. Wenn Sie on-premises planen, sollten Sie Ihre Roadmap getrennt für Services und Server prüfen.
Nächster Schritt
Treffen Sie zuerst eine Betriebsentscheidung, keine Tool-Entscheidung: Was soll in Ihrem Pull-Request-Prozess verbindlich blockieren, was soll nur sichtbar machen, und was darf ausschließlich von benannten Personen entschieden werden?
Prüfen Sie dafür getrennt:
- Pflichtregeln je Ziel-Branch,
- die Rolle von Kommentaren, Status und Reviewer-Stimmen,
- Datenpfade und Zuständigkeiten,
- ob Services oder Server Ihre Randbedingungen bestimmen.
Gerade bei KI-Unterstützung lohnt sich eine kurze Vorabprüfung mit Datenschutz, Informationssicherheit und – wo relevant – dem Betriebsrat; Fragen zu DORA, NIS2 und Mitbestimmung sollten Sie mit einem Juristen oder dem Datenschutzbeauftragten klären.
Polier von ballmüller solutions ist in Entwicklung und am 01.11.2026 noch nicht verfügbar.