Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Branchrichtlinien helfen Teams dabei, ihre wichtigen Branches der Entwicklung zu schützen. Richtlinien erzwingen die Codequalitäts- und Change Management-Standards Ihres Teams. In diesem Artikel wird beschrieben, wie Branchrichtlinien festgelegt und verwaltet werden. Eine Übersicht über alle Repository- und Branchrichtlinien und -einstellungen finden Sie unter Festlegen von Git-Repositoryeinstellungen und -Richtlinien.
Ein Branch, für den die erforderlichen Richtlinien konfiguriert sind, kann nicht gelöscht werden und erfordert Pullanforderungen (Pull Requests, PRs) für alle Änderungen.
Voraussetzungen
Zum Festlegen von Branchrichtlinien müssen Sie Mitglied der Sicherheitsgruppe „Projektadministratoren“ sein oder über die Berechtigungen Richtlinien bearbeiten auf Repositoryebene verfügen. Weitere Informationen finden Sie unter Festlegen von Git-Repositoryberechtigungen.
Zum Festlegen von Branchrichtlinien müssen Sie Mitglied der Sicherheitsgruppe „Projektadministratoren“ sein oder über die Berechtigungen Richtlinien bearbeiten auf Repositoryebene verfügen. Weitere Informationen finden Sie unter Festlegen von Git-Repositoryberechtigungen.
Zum Verwalten von Branchrichtlinien wählen Sie Repos>Branches aus, um die Seite Branches im Webportal zu öffnen.
Zu den Einstellungen für die Branchrichtlinien gelangen Sie auch über Projekteinstellungen>Repository>Richtlinien>Branchrichtlinien><Branchname>.
Branches, für die Richtlinien gelten, zeigen ein Richtliniensymbol an. Sie können das Symbol auswählen, um direkt zu den Einstellungen der Branchrichtlinie zu gelangen.
Zum Festlegen von Branchrichtlinien suchen Sie den Branch, den Sie verwalten möchten. Sie können die Liste durchsuchen oder im Feld Branchname suchen oben rechts nach Ihrem Branch suchen.
Wählen Sie das Symbol Weitere Optionen neben dem Branch und dann die Option Branchrichtlinien im Kontextmenü aus.
Suchen Sie Ihren Branch auf der Seite. Sie können die Liste durchsuchen oder den Branch im Feld Alle Branches durchsuchen oben rechts suchen.
Wählen Sie die Schaltfläche ... aus. Wählen Sie im Kontextmenü Branch Policies (Branchrichtlinien) aus.
Konfigurieren Sie die Richtlinien auf der Seite mit den Einstellungen für den Branch. In den folgenden Abschnitten finden Sie Beschreibungen und Anleitungen zu den einzelnen Richtlinienarten.
Konfigurieren Sie die Richtlinien auf der Seite Policies (Richtlinien). In den folgenden Abschnitten finden Sie Beschreibungen zu den einzelnen Richtlinienarten. Wählen Sie Änderungen speichern aus, um Ihre neue Richtlinienkonfiguration anzuwenden.
Sie können Azure DevOps CLI verwenden, um Richtlinien für einen Branch oder ein Repository aufzulisten oder anzuzeigen.
Auflisten von Richtlinien
Wenn Sie alle Richtlinien in einem Projekt auflisten möchten, verwenden Sie az repos policy list.
az repos policy list [--branch]
[--detect {false, true}]
[--org]
[--project]
[--query-examples]
[--repository-id]
[--subscription]
Parameter
Parameter
BESCHREIBUNG
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main.
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
query-examples
Empfohlene JMESPath-Zeichenfolge. Sie können eine der Abfragen kopieren und hinter dem --query-Parameter in doppelten Anführungszeichen einfügen, um die Ergebnisse anzuzeigen. Sie können ein oder mehrere Positionsschlüsselwörter hinzufügen, damit Vorschläge auf diesen Schlüsselwörtern basieren.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
Beispiel
Der folgende Befehl gibt alle Branchrichtlinien im main-Branch des Fabrikam-Repositorys mit der ID d28cd374-e7f0-4b1f-ad60-f349f155d47c zurück. Sie können die Repository-ID abrufen, indem Sie az repos listausführen.
In diesem Beispiel wird die folgende Standardkonfiguration verwendet: az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber".
az repos policy list --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --branch main --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- --------------------------- ------------- ------------ ------------------------------------ ---------------
3 Work item linking False True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
5 Minimum number of reviewers True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
6 Comment requirements False True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
12 Required reviewers True False d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
13 Required reviewers False True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
query-examples
Empfohlene JMESPath-Zeichenfolge. Sie können eine der Abfragen kopieren und hinter dem --query-Parameter in doppelten Anführungszeichen einfügen, um die Ergebnisse anzuzeigen. Sie können ein oder mehrere Positionsschlüsselwörter hinzufügen, damit Vorschläge auf diesen Schlüsselwörtern basieren.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
Azure DevOps CLI-Befehle werden für Azure DevOps Server nicht unterstützt.
Mindestanzahl von Reviewern erforderlich
Code Reviews sind wichtig für Softwareentwicklungsprojekte. Um sicherzustellen, dass Teams PRs überprüfen und genehmigen, können Sie die Genehmigung einer Mindestanzahl von Reviewern anfordern. Die grundlegende Richtlinie erfordert, dass eine bestimmte Anzahl von Reviewern den Code ohne Ablehnungen genehmigen muss.
Um die Richtlinie festzulegen, legen Sie unter Branchrichtlinien die Option Mindestanzahl von Reviewern erfordern auf Ein fest. Geben Sie die erforderliche Anzahl von Reviewern ein, und wählen Sie eine der folgenden Optionen aus:
Wählen Sie Anforderern die Genehmigung eigener Änderungen gestatten aus, damit der PR-Ersteller über dessen Genehmigung abstimmen kann. Andernfalls kann der Ersteller weiter mit Genehmigen für den PR stimmen. Die Stimme wird jedoch nicht auf die Mindestanzahl der Überprüfer angerechnet.
Wählen Sie Letzte Push ausführende Person daran hindern, eigene Änderungen zu genehmigen aus, um eine Aufgabentrennung zu erzwingen. Standardmäßig kann jeder, der über die Push-Berechtigung für den Quellbranch verfügt, sowohl Commits hinzufügen als auch über die Genehmigung von PRs abstimmen. Wenn Sie diese Option auswählen, wird die Stimme der Person, die den letzten Push ausgeführt hat, nicht gezählt, auch wenn sie ihre eigenen Änderungen einfach genehmigen können.
Wählen Sie Fertigstellung zulassen, auch wenn einige Reviewer „Warten“ oder „Ablehnen“ auswählen aus, um den PR-Abschluss zuzulassen, auch wenn einige Reviewer gegen die Genehmigung stimmen. Die Mindestanzahl der Reviewer muss weiterhin zustimmen.
Unter Beim Pushen neuer Änderungen:
Aktivieren Sie Mindestens eine Genehmigung für die letzte Iteration erforderlich, um mindestens eine Genehmigungsstimme für die letzte Änderung am Quellbranch zu erfordern.
Aktivieren Sie Alle Genehmigungsstimmen zurücksetzen (Stimmen werden nicht auf „Ablehnen“ oder „Warten“ zurückgesetzt), um alle Genehmigungsstimmen zu entfernen, aber die Stimmen zum Ablehnen oder Warten beizubehalten, wenn sich der Quellbranch ändert.
Aktivieren Sie Alle Codereviewerstimmen zurücksetzen, um alle Reviewerstimmen zu entfernen, wenn sich der Quellbranch ändert, einschließlich der Stimmen zum Genehmigen, Ablehnen oder Warten.
Unter Beim Pushen neuer Änderungen:
Aktivieren Sie Mindestens eine Genehmigung für jede Iteration erforderlich, um mindestens eine Genehmigungsstimme für die letzte Änderung am Quellbranch zu erfordern. Die Genehmigungen der Benutzer*innen werden nicht auf vorherige nicht genehmigte Iterationen angerechnet, die von diesen Benutzer*innen gepusht wurden. Daher ist eine weitere Genehmigung für die letzte Iteration durch eine(n) andere(n) Benutzer*in erforderlich. Mindestens eine Genehmigung für jede Iteration erforderlich ist in Azure DevOps Server 2022.1 und späteren Versionen verfügbar.
Aktivieren Sie Mindestens eine Genehmigung für die letzte Iteration erforderlich, um mindestens eine Genehmigungsstimme für die letzte Änderung am Quellbranch zu erfordern.
Aktivieren Sie Alle Genehmigungsstimmen zurücksetzen (Stimmen werden nicht auf „Ablehnen“ oder „Warten“ zurückgesetzt), um alle Genehmigungsstimmen zu entfernen, aber die Stimmen zum Ablehnen oder Warten beizubehalten, wenn sich der Quellbranch ändert.
Aktivieren Sie Alle Codereviewerstimmen zurücksetzen, um alle Reviewerstimmen zu entfernen, wenn sich der Quellbranch ändert, einschließlich der Stimmen zum Genehmigen, Ablehnen oder Warten.
Wenn Anforderer können ihre eigenen Änderungen genehmigen nicht aktiviert ist, kann der Ersteller der Pullanforderung weiter mit Genehmigen für die Pullanforderung stimmen. Die Stimme wird jedoch nicht auf die Mindestanzahl von Prüfern angerechnet.
Wenn ein Reviewer die Änderungen ablehnt, kann der Pull Request nicht abgeschlossen werden, es sei denn, Sie aktivieren Fertigstellung zulassen, auch wenn einige Reviewer „Warten“ oder „Ablehnen“ auswählen.
Sie können die Stimmen der Reviewer zurücksetzen, wenn neue Änderungen in den Quellbranch gepusht werden. Aktivieren Sie Codereviewerstimmen zurücksetzen, wenn neue Änderungen vorliegen.
Wenn alle anderen Richtlinien erfüllt sind, kann der Ersteller den PR abschließen, wenn die erforderliche Anzahl von Reviewern ihn genehmigt hat.
Sie können die Anzahl der erforderlichen genehmigenden Personen für Pull Requests mit az repos policy approver-count verwalten.
Erstellen einer Richtlinie für die Anzahl der genehmigenden Personen
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true. Erforderlich.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main. Erforderlich.
creator-vote-counts
Die Stimme des Erstellers zählen. Zulässige Werte: false, true. Erforderlich.
enabled
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true. Erforderlich.
minimum-approver-count
Mindestanzahl von genehmigenden Personen erforderlich. Beispiel: 2. Erforderlich.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Erforderlich.
reset-on-source-push
Stimmen zurücksetzen, wenn Änderungen zur Quelle gepusht werden. Zulässige Werte: false, true. Erforderlich.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
Beispiel
Im folgenden Beispiel wird die Mindestanzahl der erforderlichen Genehmigungen auf 2 für Pull Requests im main-Branch des Fabrikam-Repositorys festgelegt. Die Richtlinie gestattet Ablehnungen, d. h. Pull Requests können abgeschlossen werden, auch wenn einige Reviewer nicht für die Genehmigung stimmen, solange die Mindestanzahl für die Genehmigung stimmt. Durch Pushvorgänge in den Quellbranch werden die Stimmen nicht zurückgesetzt. Die Richtlinie gestattet es den Pull Request-Erstellern auch, ihre eigenen Pull Requests zu genehmigen.
In diesem Beispiel wird die Standardkonfiguration verwendet: az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber".
az repos policy approver-count create --allow-downvotes true --blocking true --branch main --creator-vote-counts true --enabled true --minimum-approver-count 2 --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --reset-on-source-push false --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- --------------------------- ------------- ------------ ------------------------------------ ---------------
27 Minimum number of reviewers True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Aktualisieren der Richtlinie für die Anzahl der genehmigenden Personen
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
creator-vote-counts
Die Stimme des Erstellers zählen. Zulässige Werte: false, true.
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true.
minimum-approver-count
Mindestanzahl von genehmigenden Personen erforderlich. Beispiel: 2.
org
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
reset-on-source-push
Stimmen zurücksetzen, wenn Änderungen zur Quelle gepusht werden. Zulässige Werte: false, true.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
Azure DevOps CLI-Befehle werden für Azure DevOps Server nicht unterstützt.
Auf verknüpfte Arbeitselemente überprüfen
Für die Nachverfolgung der Arbeitselementverwaltung können Sie Zuordnungen zwischen PRs und Arbeitselementen erfordern. Die Verknüpfung von Arbeitselementen bietet mehr Kontext für Änderungen und stellt sicher, dass Aktualisierungen Ihren Prozess zur Nachverfolgung von Arbeitselementen durchlaufen.
Zum Festlegen der Richtlinie legen Sie unter Branchrichtlinien die Option Auf verknüpfte Arbeitselemente überprüfen auf Ein fest. Diese Einstellung setzt voraus, dass Arbeitselemente mit einem PR verknüpft sind, damit der PR zusammengeführt werden kann. Legen Sie die Einstellung als optional fest, um zu warnen, wenn es keine verknüpften Arbeitselemente gibt, aber gestatten Sie das Abschließen des Pull Requests.
Sie können az repos policy work-item-linking der Azure CLI verwenden, um Richtlinien zum Verknüpfen von Arbeitselementen für einen Branch oder ein Repository zu erstellen und zu aktualisieren.
Erstellen einer Richtlinie zum Verknüpfen von Arbeitselementen
Verwenden Sie az repos policy work-item-linking create, um eine Richtlinie für die Verknüpfung von Arbeitselementen für ein Repository oder Branches zu erstellen.
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true. Erforderlich.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main. Erforderlich.
enabled
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true. Erforderlich.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
Aktualisieren einer Richtlinie zum Verknüpfen von Arbeitselementen
Verwenden Sie az repos policy work-item-linking update, um eine Richtlinie für die Verknüpfung von Arbeitselementen für ein Repository oder einen oder mehrere Branches zu aktualisieren.
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true.
minimum-approver-count
Mindestanzahl von genehmigenden Personen erforderlich. Beispiel: 2.
org
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
Beispiel
Im folgenden Beispiel wird die Richtlinien-ID 3 für den main-Branch des Fabrikam-Repositorys so aktualisiert, dass er aktiviert, aber optional ist. In dem Beispiel wird die Standardkonfiguration verwendet: az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber".
>az repos policy work-item-linking update --id 3 --blocking false --branch main --enabled true --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- ----------------- ------------- ------------ ------------------------------------ ---------------
3 Work item linking False True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Azure DevOps CLI-Befehle werden für Azure DevOps Server nicht unterstützt.
Kommentarauflösung überprüfen
Die Richtlinie Kommentarauflösung überprüfen überprüft, ob alle PR-Kommentare aufgelöst sind.
Konfigurieren Sie eine Richtlinie für die Auflösung von Kommentaren für Ihren Branch, indem Sie Kommentarauflösung überprüfen auf Ein festlegen. Wählen Sie dann aus, ob die Richtlinie erforderlich oder optional sein soll.
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true. Erforderlich.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main. Erforderlich.
enabled
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true. Erforderlich.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Erforderlich.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
Aktualisieren einer Richtlinie zur Kommentarauflösung
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true.
org
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
Beispiel
Im folgenden Beispiel wird die Richtlinien-ID 6 für die Kommentarauflösung im main-Branch des Fabrikam-Repositorys aktualisiert, damit sie blockiert. Kommentare müssen aufgelöst werden, bevor Pull Requests zusammengeführt werden können. In diesem Beispiel wird die Standardkonfiguration verwendet: az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber".
az repos policy comment-required update --id 6 --blocking true --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- -------------------- ------------- ------------ ------------------------------------ ---------------
6 Comment requirements True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Azure DevOps CLI-Befehle werden für Azure DevOps Server nicht unterstützt.
Einschränken von Mergetypen
Azure Repos verfügt über mehrere Mergestrategien, die standardmäßig alle zulässig sind. Sie können einen konsistenten Branchverlauf beibehalten, indem Sie eine Mergestrategie für den PR-Abschluss erzwingen.
Legen Sie Mergetypen einschränken auf Ein fest, um einzuschränken, welche Mergetypen in Ihrem Repository zulässig sind.
Einfacher Merge (No-Fast-Forward) erstellt einen Mergecommit in dem Ziel, dessen übergeordneten Elemente die Ziel- und Quellbranches sind.
Squashmerge erstellt einen linearen Verlauf mit einem einzelnen Commit im Zielbranch mit den Änderungen aus dem Quellbranch. Erfahren Sie mehr über Squashmerges und wie sie sich auf den Branchverlauf auswirken.
Rebase und Fast-Forward erstellt einen linearen Verlauf, indem Quellcommits ohne Mergecommit auf dem Zielbranch wiedergegeben werden.
Rebase mit Mergecommit gibt die Quellcommits auf dem Ziel wieder und erstellt auch einen Mergecommit.
Hinweis
Dieses Feature ist für Azure DevOps Server 2020 und spätere Versionen verfügbar.
Sie können az repos policy merge-strategy der Azure DevOps CLI verwenden, um die Richtlinie für die Mergestrategie festzulegen und zu aktualisieren.
Erstellen einer Richtlinie für eine Mergestrategie
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true. Erforderlich.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main. Erforderlich.
enabled
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true. Erforderlich.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Erforderlich.
allow-no-fast-forward
Einfacher Merge ohne Fast-Forward. Behält den nicht linearen Verlauf genau so bei, wie er während der Entwicklung stattgefunden hat. Zulässige Werte: false, true.
allow-rebase
Rebase und Fast-Forward. Erstellt einen linearen Verlauf, indem die Quellbranchcommits ohne Mergecommit auf dem Ziel wiedergegeben werden. Zulässige Werte: false, true.
allow-rebase-merge
Rebase mit Mergecommit. Erstellt einen semilinearen Verlauf, indem die Quellbranchcommits auf dem Ziel wiedergegeben werden und anschließend ein Mergecommit erstellt wird. Zulässige Werte: false, true.
allow-squash
Squashmerge. Erstellt einen linearen Verlauf, indem die Quellbranchcommits zu einem einzigen neuen Commit auf dem Zielbranch zusammengefasst werden. Zulässige Werte: false, true.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
use-squash-merge
Führen Sie immer einen Squashmerge aus. Diese Option ist für andere Mergetypen nicht verfügbar. Zulässige Werte: false, true.
Hinweis: use-squash-merge ist veraltet und wird in einer zukünftigen Version entfernt. Verwenden Sie stattdessen --allow-squash.
Beispiel
Im folgenden Beispiel wird eine erforderliche Mergestrategie für Pull Requests im main-Branch des Fabrikam-Repository festgelegt, um einen Squashmerge zuzulassen. In diesem Beispiel wird die Standardkonfiguration verwendet: az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber".
az repos policy merge-strategy create --allow-squash true --blocking true --branch main --enabled true --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- ------------------------ ------------- ------------ ------------------------------------ ---------------
29 Require a merge strategy True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Aktualisieren einer Richtlinie für eine Mergestrategie
Einfacher Merge ohne Fast-Forward. Behält den nicht linearen Verlauf genau so bei, wie er während der Entwicklung stattgefunden hat. Zulässige Werte: false, true.
allow-rebase
Rebase und Fast-Forward. Erstellt einen linearen Verlauf, indem die Quellbranchcommits ohne Mergecommit auf dem Ziel wiedergegeben werden. Zulässige Werte: false, true.
allow-rebase-merge
Rebase mit Mergecommit. Erstellt einen semilinearen Verlauf, indem die Quellbranchcommits auf dem Ziel wiedergegeben werden und anschließend ein Mergecommit erstellt wird. Zulässige Werte: false, true.
allow-squash
Squashmerge. Erstellt einen linearen Verlauf, indem die Quellbranchcommits zu einem einzigen neuen Commit auf dem Zielbranch zusammengefasst werden. Zulässige Werte: false, true.
blocking
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true.
org
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
use-squash-merge
Ob immer ein Squashmerge erfolgen soll. Diese Option funktioniert nicht für andere Mergetypen. Zulässige Werte: false, true.
Azure DevOps CLI-Befehle werden für Azure DevOps Server nicht unterstützt.
Erzwingen einer Mergestrategie
Behalten Sie einen konsistenten Branchverlauf bei, indem Sie eine Mergestrategie erzwingen, wenn ein Pull Request abgeschlossen ist.
Wählen Sie Mergestrategie erzwingen und dann eine Option aus, die erfordert, dass Pull Requests mithilfe dieser Strategie zusammengeführt werden.
No-Fast-Forward-Merge: Diese Option führt den Commitverlauf des Quellbranchs zusammen, wenn der Pull Request geschlossen wird, und erstellt einen Mergecommit im Zielbranch.
Squashmerge: Schließen Sie alle Pull Requests mit einem Squashmerge ab, und erstellen Sie einen einzelnen Commit im Zielbranch mit den Änderungen aus dem Quellbranch. Erfahren Sie mehr über Squashmerges und wie sie sich auf Ihren Branchverlauf auswirken.
Buildvalidierung
Sie können eine Richtlinie festlegen, nach der PR-Änderungen erfolgreich erstellt werden müssen, bevor der PR abgeschlossen werden kann.
Buildrichtlinien reduzieren Unterbrechungen und sorgen weiterhin dafür, dass Ihre Testergebnisse erfolgreich sind. Buildrichtlinien helfen auch dann, wenn Sie Continuous Integration (CI) in Ihren Entwicklungsbranches verwenden, um Probleme frühzeitig abzufangen.
Eine Richtlinie zur Buildüberprüfung stellt einen neuen Build in die Warteschlange, wenn ein neuer PR erstellt oder Änderungen zu einem vorhandenen PR gepusht werden, der auf den Branch ausgerichtet ist. Die Buildrichtlinie wertet die Buildergebnisse aus, um festzustellen, ob der PR abgeschlossen werden kann.
Wichtig
Bevor Sie eine Richtlinie für die Buildüberprüfung angeben können, müssen Sie über eine Buildpipeline verfügen. Wenn Sie keine Buildpipeline besitzen, finden Sie weitere Informationen unter Erstellen einer Buildpipeline. Wählen Sie den Buildtyp aus, der zu Ihrem Projekttyp passt.
Wählen Sie unter Trigger die Option Automatisch (wenn der Quellbranch aktualisiert wird) oder Manuell aus.
Wählen Sie unter Richtlinienanforderung die Optionen Erforderlich oder Optional aus. Wenn Sie Erforderlich auswählen, müssen Builds erfolgreich abgeschlossen werden, um PRs abzuschließen. Wählen Sie Optional aus, um eine Benachrichtigung über einen Buildfehler zu erhalten, aber dennoch den Abschluss von PRs zuzulassen.
Legen Sie ein Ablaufdatum für den Build fest, um sicherzustellen, dass Updates Ihres geschützten Branchs nicht die Änderungen an offenen PRs unterbrechen.
Sofort beim Aktualisieren des <Branchnamens>: Diese Option legt den Status der PR-Buildrichtlinie auf Fehler fest, wenn der Branch aktualisiert wird und stellt einen Build erneut in die Warteschlange. Diese Einstellung stellt sicher, dass die PR-Änderungen erfolgreich erstellt werden, auch wenn der geschützte Branch geändert wird.
Diese Option eignet sich am besten für Teams, deren wichtige Branches nur wenige Änderungen aufweisen. Teams, die in ausgelasteten Entwicklungsbranches arbeiten, empfinden es möglicherweise als störend, bei jedem Branchupdate auf einen Build warten zu müssen.
Nach <n> Stunden, wenn <Branchname> aktualisiert wurde: Mit dieser Option läuft der aktuelle Richtlinienstatus ab, wenn der geschützte Branch aktualisiert wird, wenn der übergebende Build älter ist als der von Ihnen eingegebene Schwellenwert. Diese Option ist ein Kompromiss zwischen den Anforderungen, dass „immer“ und „nie“ ein Build erforderlich ist, wenn der geschützte Branch aktualisiert wird. Diese Option reduziert die Anzahl der Builds, wenn Ihr geschützter Branch häufig aktualisiert wird.
Nie: Updates für den geschützten Branch ändern den Status der Richtlinie nicht. Dieser Wert reduziert die Anzahl der Builds, kann jedoch Probleme verursachen, wenn PRs abgeschlossen werden, die nicht kürzlich aktualisiert wurden.
Geben Sie einen optionalen Anzeigenamen für diese Buildrichtlinie ein. Dieser Name identifiziert die Richtlinie auf der Seite Branchrichtlinien. Wenn Sie keinen Anzeigenamen angeben, verwendet die Richtlinie den Namen der Buildpipeline.
Wählen Sie Speichern aus.
Wenn der PR-Besitzer Änderungen pusht, die erfolgreich erstellt werden, wird der Richtlinienstatus aktualisiert.
Wenn Sie über eine Richtlinie Sofort beim Aktualisieren von <Branchname> oder Nach <n> Stunden, wenn <Branchname> aktualisiert wurde verfügen, wird der Richtlinienstatus aktualisiert, wenn der geschützte Branch aktualisiert wird, sofern der vorherige Branch nicht mehr gültig ist.
Hinweis
Dieses Feature ist für Azure DevOps Server 2020 und spätere Versionen verfügbar.
Sie können den Befehl az repos policy build der Azure DevOps CLI verwenden, um die Richtlinie für die Buildüberprüfung festzulegen und zu aktualisieren.
Erstellen einer Richtlinie für die Buildüberprüfung
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true. Erforderlich.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main. Erforderlich.
build-definition-id
Die ID der Builddefinition. Erforderlich.
display-name
Anzeigename für diese Buildrichtlinie, um die Richtlinie zu identifizieren. Beispiel: Manual queue policy. Erforderlich.
enabled
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true. Erforderlich.
manual-queue-only
Gibt an, ob nur die manuelle Warteschlange für Builds zulässig ist. Zulässige Werte: false, true. Erforderlich.
queue-on-source-update-only
Gibt an, ob Builds nur bei Quellupdates in die Warteschlange gestellt werden sollen. Zulässige Werte: false, true. Erforderlich.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Erforderlich.
valid-duration
Gültigkeitsdauer der Richtlinie in Minuten. Hinweis:valid-duration muss zwischen null und einem Jahr liegen und muss null sein, wenn --queue-on-source-update-only gleich false ist. Erforderlich.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
path-filter
Pfad, auf den die Richtlinie angewendet werden soll. Unterstützt absolute Pfade, Platzhalter und mehrere durch ; getrennte Pfade. Beispiele: /WebApp/Models/Data.cs, /WebApp/* oder *.cs, oder /WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
Beispiel
Das folgende Beispiel legt eine erforderliche Buildrichtlinie für Pull Requests im main-Branch des Fabrikam-Repositorys fest. Die Richtlinie erfordert einen erfolgreichen Build der Builddefinitions-ID 1 und lässt nur das manuelle Queuing von Builds zu. In diesem Beispiel wird die Standardkonfiguration verwendet: az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber".
az repos policy build create --blocking true --branch main --build-definition-id 1 --display-name build-policy --enabled true --manual-queue-only true --queue-on-source-update-only false --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --valid-duration 0 --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- ------------ ------------- ------------ ------------------------------------ ---------------
31 build-policy True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Aktualisieren einer Richtlinien für die Buildüberprüfung
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
Anzeigename für diese Buildrichtlinie, um die Richtlinie zu identifizieren. Beispiel: Manual queue policy.
enabled
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true.
manual-queue-only
Gibt an, ob nur die manuelle Warteschlange für Builds zulässig ist. Zulässige Werte: false, true.
org
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
path-filter
Pfade, auf die die Richtlinie angewendet werden soll. Unterstützt absolute Pfade, Platzhalter und mehrere durch ; getrennte Pfade. Beispiele: /WebApp/Models/Data.cs, /WebApp/* oder *.cs, oder /WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
queue-on-source-update-only
Gibt an, ob Builds nur bei Quellupdates in die Warteschlange gestellt werden sollen. Zulässige Werte: false, true.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
valid-duration
Gültigkeitsdauer der Richtlinie in Minuten.
Azure DevOps CLI-Befehle werden für Azure DevOps Server nicht unterstützt.
Legen Sie eine Richtlinie fest, nach der Änderungen in einem Pull Request erfolgreich mit dem geschützten Branch erstellt werden müssen, bevor der Pull Request abgeschlossen werden kann.
Buildrichtlinien reduzieren Unterbrechungen und sorgen weiterhin dafür, dass Ihre Testergebnisse erfolgreich sind. Buildrichtlinien helfen auch dann, wenn Sie Continuous Integration (CI) in Ihren Entwicklungsbranches verwenden, um Probleme frühzeitig abzufangen.
Wenn eine Richtlinie zur Buildüberprüfung aktiviert ist, wird ein neuer Build in die Warteschlange eingereiht, wenn eine neue Pullanforderung erstellt wird oder Änderungen für eine vorhandene Pullanforderung gepusht werden, die auf den Branch ausgerichtet ist. Die Buildrichtlinie wertet dann die Ergebnisse des Builds aus, um festzustellen, ob der Pull Request abgeschlossen werden kann.
Wichtig
Bevor Sie eine Richtlinie für die Buildüberprüfung angeben können, müssen Sie über eine Builddefinition verfügen. Wenn Sie keine haben, finden Sie weitere Informationen unter Erstellen einer Builddefinition. Wählen Sie dann den zu Ihrem Projekttyp passenden Buildtyp aus.
Wählen Sie Buildrichtlinie hinzufügen aus, und konfigurieren Sie Ihre Optionen in Buildrichtlinie hinzufügen.
Wählen Sie die Builddefinition aus.
Wählen Sie den Typ für den Trigger aus. Wählen Sie Automatisch (wenn der Quellbranch aktualisiert wird) oder Manuell aus.
Wählen Sie die Richtlinienanforderung aus. Wenn Sie Erforderlich auswählen, müssen Builds erfolgreich abgeschlossen werden, um Pull Requests abzuschließen. Wählen Sie Optional aus, um eine Benachrichtigung über einen Buildfehler zu erhalten, aber dennoch den Abschluss von Pull Requests zuzulassen.
Legen Sie ein Ablaufdatum für den Build fest, um sicherzustellen, dass Updates Ihres geschützten Branchs nicht die Änderungen an offenen Pull Requests unterbrechen.
Sofort beim Aktualisieren von branch name: Diese Option legt den Status der Buildrichtlinie in einem Pull Request auf Fehler fest, wenn der geschützte Branch aktualisiert wird. Stellen Sie einen Build erneut in eine Warteschlange, um den Buildstatus zu aktualisieren. Diese Einstellung stellt sicher, dass die Änderungen in Pull Requests erfolgreich erstellt werden, auch wenn der geschützte Branch geändert wird. Diese Option eignet sich am besten für Teams, die wichtige Branches mit einem geringeren Änderungsaufkommen aufweisen. Teams, die in ausgelasteten Entwicklungsbranches arbeiten, empfinden es unter Umständen als störend, bei jedem Update für den geschützten Branch auf den Abschluss eines Builds warten zu müssen.
Nach n Stunden, wenn branch name aktualisiert wurde: Mit dieser Option läuft der aktuelle Richtlinienstatus ab, wenn der geschützte Branch aktualisiert wird, wenn der übergebende Build älter ist als der von Ihnen eingegebene Schwellenwert. Diese Option ist ein Kompromiss zwischen den Anforderungen, dass „immer“ ein Build erforderlich ist, wenn der geschützte Branch aktualisiert wird, und dass „nie“ einer erforderlich ist. Diese Option eignet sich hervorragend, um die Anzahl der Builds zu reduzieren, wenn Ihr geschützter Branch häufig aktualisiert wird.
Nie: Updates für den geschützten Branch ändern den Status der Richtlinie nicht. Dieser Wert reduziert die Anzahl der Builds für Ihren Branch. Es kann zu Problemen führen, wenn Sie Pullanforderungen schließen, die in letzter Zeit nicht aktualisiert wurden.
Geben Sie einen optionalen Anzeigenamen für diese Buildrichtlinie ein. Dieser Name identifiziert die Richtlinie auf der Seite Branchrichtlinien. Wenn Sie keinen Anzeigenamen angeben, verwendet die Richtlinie den Namen der Builddefinition.
Wählen Sie Speichern aus.
Wenn der Besitzer Änderungen pusht, die erfolgreich erstellt werden, wird der Richtlinienstatus aktualisiert. Wenn Sie die Buildrichtlinie Sofort beim Aktualisieren von branch name oder Nach n Stunden, wenn branch name aktualisiert wurde ausgewählt haben, wird der Richtlinienstatus aktualisiert, wenn der geschützte Branch aktualisiert wird, falls der letzte Branch nicht mehr gültig ist.
Statusüberprüfungen
Externe Dienste können die PR-Status-API verwenden, um detaillierte Status für Ihre PRs zu posten. Die Branchrichtlinie für zusätzliche Dienste ermöglicht diesen externen Diensten die Teilnahme am PR-Workflow und die Festlegung von Richtlinienanforderungen.
Externe Dienste können die PR-Status-API verwenden, um detaillierte Status für Ihre PRs zu posten. Die Branchrichtlinie für zusätzliche Dienste ermöglicht diesen externen Diensten die Teilnahme am PR-Workflow und die Festlegung von Richtlinienanforderungen.
Sie können Reviewer automatisch zu Pull Requests hinzufügen, die Dateien in bestimmten Verzeichnissen und Dateien ändern, oder zu allen Pull Requests in einem Repository.
Wählen Sie die Schaltfläche + neben Automatisch einbezogene Reviewer aus.
Füllen Sie den Bildschirm Neue Reviewerrichtlinie hinzufügen aus.
Fügen Sie Personen und Gruppen zu Reviewer hinzu.
Wählen Sie Optional aus, wenn Sie Reviewer automatisch hinzufügen möchten, aber nicht deren Genehmigung zum Abschluss des Pull Requests benötigen.
Oder wählen Sie Erforderlich aus, wenn Pull Requests nicht abgeschlossen werden können, bis Folgendes zutrifft:
Jede Person, die als Reviewer hinzugefügt wird, genehmigt die Änderungen.
Mindestens eine Person in jeder Gruppe, die als Reviewer hinzugefügt wurde, genehmigt die Änderungen.
Wenn nur eine Gruppe erforderlich ist, genehmigt die von Ihnen angegebene Mindestanzahl von Mitgliedern die Änderungen.
Geben Sie die Dateien und Ordner an, für die die automatisch einbezogenen Reviewer benötigt werden. Lassen Sie dieses Feld leer, wenn Sie die Reviewer für alle Pull Requests im Branch benötigen.
Wählen Sie Anforderern die Genehmigung eigener Änderungen gestatten aus, wenn Besitzer von Pull Requests über die Genehmigung ihrer eigenen Pull Requests abstimmen können, um diese Richtlinie zu erfüllen.
Sie können eine Aktivitätsfeednachricht angeben, die im Pull Request angezeigt wird.
Wählen Sie Speichern aus.
Hinweis
Dieses Feature ist für Azure DevOps Server 2020 und spätere Versionen verfügbar.
Sie können den Befehl az repos policy required-reviewer der Azure DevOps CLI verwenden, um die erforderliche Reviewerrichtlinie festzulegen und zu aktualisieren.
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true. Erforderlich.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main. Erforderlich.
enabled
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true. Erforderlich.
message
Aktivitätsfeednachricht, die im Pull Request angezeigt wird. Erforderlich.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Erforderlich.
required-reviewer-ids
E-Mail-Adressen der Reviewer, getrennt durch ;. Beispiel: john@contoso.com;alice@contoso.com.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
path-filter
Pfade, auf die die Richtlinie angewendet werden soll. Unterstützt absolute Pfade, Platzhalter und mehrere durch ; getrennte Pfade. Beispiele: /WebApp/Models/Data.cs, /WebApp/* oder *.cs, oder /WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
Beispiel
Im folgenden Beispiel wird Jamal Hartnett als erforderlichen Reviewer für Pull Requests im main-Branch des Fabrikam-Repositorys festgelegt. In diesem Beispiel wird die Standardkonfiguration verwendet: az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber".
az repos policy required-reviewer create --blocking true --branch main --enabled true --message "Please review." --repository-id d28cd374-e7f0-4b1f-ad60-f349f155d47c --required-reviewer-ids fabrikamfiber4@hotmail.com --output table
ID Name Is Blocking Is Enabled Repository Id Branch
---- ------------------ ------------- ------------ ------------------------------------ ---------------
35 Required reviewers True True d28cd374-e7f0-4b1f-ad60-f349f155d47c refs/heads/main
Aktualisieren einer erforderlichen Reviewerrichtlinie
Blockieren, wenn die Richtlinie nicht erfüllt ist. Zulässige Werte: false, true.
branch
Branchname, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Der --repository-id-Parameter ist erforderlich, um den Branchfilter zu verwenden. Beispiel: --branch main.
branch-match-type
Verwenden Sie das branch-Argument, um die Richtlinie anzuwenden. Wenn der Wert exact ist, gilt die Richtlinie für einen Branch, der genau dem Argument --branch entspricht. Wenn der Wert prefix ist, gilt die Richtlinie für alle Branchordner, die dem Präfix im Argument --branch entsprechen. Zulässige Werte: exact, prefix. Standardwert. exact.
Aktivieren Sie die Richtlinie. Zulässige Werte: false, true.
message
Aktivitätsfeednachricht, die im Pull Request angezeigt wird.
org
Azure DevOps-Organisations-URL. Sie können die Standardorganisation mit az devops configure -d organization=<ORG_URL> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen. Beispiel: https://dev.azure.com/MyOrganizationName/.
path-filter
Pfade, auf die die Richtlinie angewendet werden soll. Unterstützt absolute Pfade, Platzhalter und mehrere durch ; getrennte Pfade. Beispiele: /WebApp/Models/Data.cs, /WebApp/* oder *.cs, oder /WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=<NAME_OR_ID> konfigurieren. Erforderlich, wenn nicht als „Standard“ konfiguriert oder über „git config“ übernommen.
repository-id
ID des Repositorys, nach dem die Ergebnisse mit exakter Übereinstimmung gefiltert werden sollen. Beispiel: --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
required-reviewer-ids
E-Mail-Adressen der Reviewer, getrennt durch ;. Beispiel: john@contoso.com;alice@contoso.com.
subscription
Der Name oder die ID des Abonnements. Sie können das standardmäßig verwendete Abonnement mittels az account set -s <NAME_OR_ID> konfigurieren.
Azure DevOps CLI-Befehle werden für Azure DevOps Server nicht unterstützt.
Wählen Sie Reviewer für bestimmte Verzeichnisse und Dateien in Ihrem Repository aus.
Diese Reviewer werden automatisch zu Pull Requests hinzugefügt, die Dateien entlang dieser Pfade ändern. Sie können auch eine Aktivitätsfeednachricht angeben.
Wenn Sie Erforderlich auswählen, kann der Pull Request nicht abgeschlossen werden, bis Folgendes zutrifft:
Jeder Benutzer, der als Reviewer für den Pfad hinzugefügt wird, genehmigt die Änderungen.
Mindestens eine Person in jeder Gruppe, die dem Pfad hinzugefügt wurde, genehmigt die Änderungen.
Die Anzahl der Reviewer, die für jede zum Pfad hinzugefügte Gruppe angegeben ist, genehmigt die Änderungen.
Wählen Sie Optional aus, wenn Sie Reviewer automatisch hinzufügen möchten, aber nicht deren Genehmigung zum Abschluss des Pull Requests benötigen.
Sie können die Option Anforderer können ihre eigenen Änderungen genehmigen auswählen.
Wenn alle erforderlichen Reviewer den Code genehmigen, können Sie den Pull Request abschließen.
Umgehen von Branchrichtlinien
In manchen Fällen müssen Sie die Anforderungen der Richtlinie möglicherweise umgehen. Mithilfe von Umgehungsberechtigungen können Sie Änderungen direkt zu einem Branch pushen oder Pull Requests abschließen, die keine Branchrichtlinien erfüllen. Sie können einem Benutzer oder einer Gruppe Umgehungsberechtigungen erteilen. Sie können die Umgehungsberechtigungen auf ein ganzes Projekt, ein Repository oder einen einzelnen Branch anwenden.
Zwei Berechtigungen ermöglichen es Benutzern, die Branchrichtlinien auf unterschiedliche Weise zu umgehen:
Richtlinien beim Abschließen von Pull Requests umgehen gilt nur für den Abschluss von Pull Requests. Benutzer mit dieser Berechtigung können Pull Requests abschließen, auch wenn die Anforderungen nicht die Richtlinien erfüllen.
Richtlinien bei Pushvorgängen umgehen gilt für Pushvorgänge aus lokalen Repositorys und für Bearbeitungen, die im Web vorgenommen wurden. Benutzer mit dieser Berechtigung können Änderungen direkt zu geschützten Branches pushen, ohne die Richtlinienanforderungen zu erfüllen.
Weitere Informationen zur Verwaltung dieser Berechtigungen finden Sie unter Git-Berechtigungen.
In TFS 2015 bis TFS 2018 Update 2 können Benutzer mit der Berechtigung Ausgenommen von Richtlinienerzwingung die folgenden Aktionen durchführen:
Sie können Richtlinien überschreiben und eine Pullanforderung abschließen, auch wenn die aktuelle Gruppe von Branchrichtlinien nicht erfüllt wird.
Pushen Sie direkt in einen Branch, auch wenn für diesen Branch Branchrichtlinien festgelegt sind. Wenn Benutzer*innen mit dieser Berechtigung einen Push durchführen, der die Branchrichtlinie überschreiben würde, umgeht der Push automatisch ohne Zustimmungsschritt oder Warnung die Branchrichtlinie.
Wichtig
Seien Sie bei der Gewährung der Möglichkeit zum Umgehen von Richtlinien umsichtig, insbesondere auf der Repository- und Projektebene. Richtlinien sind der Grundstein für eine sichere und konforme Quellcodeverwaltung.
Pfadfilter
Verschiedene Branchrichtlinien bieten Pfadfilter. Wenn ein Pfadfilter festgelegt ist, gilt die Richtlinie nur für Dateien, die dem Pfadfilter entsprechen. Wenn Sie dieses Feld leer lassen, bedeutet dies, dass die Richtlinie für alle Dateien im Branch gilt.
Sie können absolute Pfade (der Pfad muss entweder mit / oder einem Platzhalter beginnen) und Platzhalter angeben.
Beispiele:
/WebApp/Models/Data.cs
/WebApp/*
*/Models/Data.cs
*.cs
Sie können mehrere Pfade angeben, indem Sie ; als Trennzeichen verwenden.
Beispiel:
/WebApp/Models/Data.cs;/ClientApp/Models/Data.cs
Pfade mit dem Präfix ! werden ausgeschlossen, wenn sie sonst enthalten wären.
Beispiel:
/WebApp/*;!/WebApp/Tests/* enthält alle Dateien in /WebApp mit Ausnahme der Dateien in /WebApp/Tests
!/WebApp/Tests/* gibt keine Dateien an, da zunächst nichts einbezogen wird
Die Reihenfolge der Filter ist wichtig. Filter werden von links nach rechts angewendet.
Kann ich Änderungen direkt in Branches pushen, die über Branchrichtlinien verfügen?
Sie können Änderungen nicht direkt zu Branches pushen, die Branchrichtlinien erfordern, es sei denn, Sie verfügen über die Berechtigung für die Umgehung von Branchrichtlinien. Änderungen an diesen Branches können nur über Pull Requests vorgenommen werden. Sie können Änderungen direkt in Branches mit optionalen Branchrichtlinien pushen, wenn diese keine erforderlichen Branchrichtlinien aufweisen.
Was ist die automatische Vervollständigung?
Pull Requests in Branches, für die Richtlinien festgelegt wurden, verfügen über die Schaltfläche Automatische Vervollständigung festlegen. Wählen Sie diese Option aus, um den Pull Request automatisch abzuschließen, sobald er alle Richtlinien erfüllt. Die automatische Vervollständigung ist nützlich, wenn Sie keine Probleme mit Ihren Änderungen erwarten.
Wann werden die Bedingungen der Branchrichtlinien geprüft?
Branchrichtlinien werden auf dem Server neu ausgewertet, wenn Besitzer von Pull Requests Änderungen pushen und wenn Reviewer abstimmen. Wenn eine Richtlinie einen Build auslöst, wird der Buildstatus auf „Warten“ festgelegt, bis der Build abgeschlossen ist.
Kann ich XAML-Builddefinitionen in Branchrichtlinien verwenden?
Nein, Sie können keine XAML-Builddefinitionen in Branchrichtlinien verwenden.
Welche Platzhalterzeichen kann ich für erforderliche Codereviewer verwenden?
Einzelne Sternchen * entsprechen einer beliebigen Anzahl von Zeichen, einschließlich Schrägstrichen / und umgekehrten Schrägstrichen \. Fragezeichen ? vergleichen jedes einzelne Zeichen.
Beispiele:
*.sql entspricht allen Dateien mit der SQL-Erweiterung.
/ConsoleApplication/* entspricht allen Dateien unter dem Ordner ConsoleApplication.
/.gitattributes entspricht der Datei .gitattributes* im Stammverzeichnis des Repository.
*/.gitignore entspricht jeder .gitignore-Datei im Repository.
Wird bei den Codereviewerpfaden die Groß-/Kleinschreibung beachtet?
Nein, Branchrichtlinien beachten nicht die Groß-/Kleinschreibung.
Wie kann ich mehrere Benutzer als erforderliche Reviewer konfigurieren, aber nur einen von ihnen zur Genehmigung erfordern?
Sie können die Benutzer zu einer Gruppe hinzufügen, und dann die Gruppe als Reviewer hinzufügen. Jedes Mitglied der Gruppe kann dann genehmigen, um die Richtlinienanforderung zu erfüllen.
Ich verfüge über Berechtigungen zur Umgehung der Richtlinie. Warum werden immer noch Richtlinienfehler im Pull Request-Status angezeigt?
Konfigurierte Richtlinien werden bei Änderungen an Pull Requests immer ausgewertet. Für Benutzer, die über Berechtigungen zur Umgehung der Richtlinie verfügen, ist der gemeldete Status der Richtlinie nur „beratend“. Wenn der Benutzer mit Umgehungsberechtigungen zustimmt, blockiert der Fehlerstatus nicht den Abschluss des Pull Requests.
Warum kann ich meine eigenen Pull Requests nicht abschließen, wenn „Anforderern die Genehmigung eigener Änderungen gestatten“ festgelegt ist?
Sowohl die Richtlinie Mindestanzahl von Reviewern erfordern als auch die Richtlinie Automatisch einbezogene Reviewer verfügt über die Option Anforderern die Genehmigung eigener Änderungen gestatten. In jeder Richtlinie gilt die Einstellung nur für diese Richtlinie. Die Einstellung hat keinen Einfluss auf die anderen Richtlinien.
In Ihrem Pull Request sind z. B. die folgenden Richtlinien festgelegt:
Mindestanzahl von Reviewern erfordern erfordert mindestens einen Reviewer.
Automatisch einbezogene Reviewer erfordert Sie oder ein Team, in dem Sie sich befinden, als Reviewer.
Automatisch einbezogene Reviewer hat Anforderern die Genehmigung eigener Änderungen gestatten aktiviert.
Mindestanzahl von Reviewern erfordern hat Anforderern die Genehmigung eigener Änderungen gestatten nicht aktiviert.
In diesem Fall erfüllt Ihre Genehmigung Automatisch einbezogene Reviewer, aber nicht Mindestanzahl von Reviewern erfordern, sodass Sie den Pull Request nicht abschließen können.
Es kann auch andere Richtlinien geben, z. B. Letzte Push ausführende Person daran hindern, eigene Änderungen zu genehmigen, die Sie daran hindern, Ihre eigenen Änderungen zu genehmigen, selbst wenn Anforderern die Genehmigung eigener Änderungen gestatten festgelegt ist.
Was passiert, wenn der Pfad in Pfadfiltern nicht mit / oder einem Platzhalter beginnt?
Ein Pfad in Pfadfiltern, der nicht mit / oder einem Platzhalter beginnt, hat keine Auswirkungen, und der Pfadfilter wird so ausgewertet, als ob dieser Pfad nicht angegeben wäre. Ein solcher Pfad kann nicht mit dem / übereinstimmen, mit dem der absolute Dateipfad beginnt.