Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Les stratégies de branche aident les équipes à protéger leurs branches importantes de développement. Les stratégies appliquent les standards de qualité du code et de gestion des modifications de votre équipe. Cet article explique comment définir et gérer des stratégies de branche. Pour obtenir une vue d’ensemble de toutes les stratégies et paramètres de référentiel et de branche, consultez Paramètres et stratégies de référentiel Git.
Une branche dans laquelle les stratégies requises sont configurées ne peut pas être supprimée et nécessite des requêtes pull (PR) pour toutes les modifications.
Prérequis
Pour définir des stratégies de branche, vous devez être membre du groupe de sécurité Administrateurs de projet ou disposer d’autorisations De modification au niveau du référentiel. Pour plus d’informations, consultez Définir des autorisations pour un référentiel.
Pour définir des stratégies de branche, vous devez être membre du groupe de sécurité Administrateurs de projet ou disposer d’autorisations De modification au niveau du référentiel. Pour plus d’informations, consultez Définir des autorisations pour un référentiel.
Pour gérer les stratégies de branche, sélectionnez Branches de Repos> pour ouvrir la page Branches dans le portail web.
Vous pouvez également accéder aux paramètres de stratégie de branche avec le nom de la branche >stratégies de branche >des stratégies >de référentiel ><des paramètres de projet>.
Les branches qui ont des stratégies affichent une icône de stratégie. Vous pouvez sélectionner l’icône pour accéder directement aux paramètres de stratégie de la branche.
Pour définir des stratégies de branche, recherchez la branche que vous souhaitez gérer. Vous pouvez parcourir la liste ou rechercher votre branche dans la zone nom de la branche de recherche en haut à droite.
Sélectionnez l’icône Autres options en regard de la branche, puis sélectionnez Stratégies de branche dans le menu contextuel.
Localisez dans la page votre branche. Vous pouvez parcourir la liste ou rechercher votre branche à l’aide de la zone Rechercher toutes les branches en haut à droite.
Sélectionnez le bouton .... Sélectionnez Stratégies de branche dans le menu contextuel.
Configurez des stratégies sur la page des paramètres de la branche. Consultez les sections suivantes pour obtenir des descriptions et des instructions pour chaque type de stratégie.
Configurez vos stratégies dans la page Stratégies. Consultez les sections suivantes pour obtenir des descriptions de chaque type de stratégie. Sélectionnez Enregistrer les modifications pour appliquer votre nouvelle configuration de stratégie.
Vous pouvez utiliser Azure DevOps CLI pour répertorier ou afficher des stratégies pour une branche ou un référentiel.
Répertorier les stratégies
Pour répertorier toutes les stratégies d’un projet, utilisez az repos policy list.
az repos policy list [--branch]
[--detect {false, true}]
[--org]
[--project]
[--query-examples]
[--repository-id]
[--subscription]
Paramètres
Paramètre
Description
branch
Nom de branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main.
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré comme valeur par défaut ou récupéré par le biais de la configuration Git.
query-examples
Chaîne JMESPath recommandée. Vous pouvez copier l’une des requêtes et la coller après le paramètre --query entre guillemets doubles pour afficher les résultats. Vous pouvez ajouter un ou plusieurs mots clés positionnels afin que les suggestions soient basées sur ces mots clés.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
Exemple
La commande suivante retourne toutes les stratégies de branche en vigueur dans la main branche du référentiel Fabrikam, IDd28cd374-e7f0-4b1f-ad60-f349f155d47c. Vous pouvez obtenir l’ID du référentiel en exécutant az repos list.
Cet exemple utilise la configuration par défaut suivante : 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
Afficher les détails d’une stratégie
Pour afficher les détails de n’importe quelle stratégie, utilisez az repos policy show.
az repos policy show --id
[--detect {false, true}]
[--org]
[--project]
[--query-examples]
[--subscription]
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré comme valeur par défaut ou récupéré par le biais de la configuration Git.
query-examples
Chaîne JMESPath recommandée. Vous pouvez copier l’une des requêtes et la coller après le paramètre --query entre guillemets doubles pour afficher les résultats. Vous pouvez ajouter un ou plusieurs mots clés positionnels afin que les suggestions soient basées sur ces mots clés.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
Les commandes Azure DevOps CLI ne sont pas prises en charge pour Azure DevOps Server.
Demander un nombre minimal de réviseurs
Les révisions de code sont importantes pour les projets de développement de logiciels. Pour vous assurer que les équipes examinent et approuvent les demandes de tirage, vous pouvez exiger l’approbation d’un nombre minimal de réviseurs. La stratégie de base exige qu’un nombre spécifié de réviseurs approuvent le code, sans rejet.
Pour définir la stratégie, sous Stratégiesde branche, définissez Exiger un nombre minimal de réviseurssur Activé. Entrez le nombre requis de réviseurs, puis sélectionnez l’une des options suivantes :
Sélectionnez Autoriser les demandeurs à approuver leurs propres modifications pour permettre au créateur d’une demande de tirage de voter sur son approbation. Sinon, le créateur peut toujours voter pour l'approbation du PR, mais son vote n'est pas pris en compte dans le calcul du nombre minimum de réviseurs.
Sélectionnez Empêcher le dernier pusher d’approuver ses propres modifications pour appliquer la séparation des tâches. Par défaut, toute personne disposant d’une autorisation push sur la branche source peut ajouter des commits et voter sur l’approbation de demande de tirage. La sélection de cette option signifie que le vote du pusher le plus récent ne compte pas, même s’il peut généralement approuver ses propres modifications.
Sélectionnez Autoriser l’achèvement même si certains réviseurs votent pour attendre ou rejeter pour autoriser l’achèvement de la demande de tirage, même si certains réviseurs votent contre l’approbation. Le nombre minimal de réviseurs doit toujours être approuvé.
Sous Quand de nouvelles modifications sont envoyées :
Sélectionnez Exiger au moins une approbation sur la dernière itération pour exiger au moins un vote d’approbation pour la dernière modification de la branche source.
Sélectionnez Réinitialiser tous les votes d'approbation (ne réinitialise pas les votes pour rejeter ou attendre) pour supprimer tous les votes d'approbation, mais conserver les votes pour rejeter ou attendre, chaque fois que la branche source change,
Sélectionnez Réinitialiser tous les votes du réviseur de code pour supprimer tous les votes du réviseur chaque fois que la branche source change, y compris les votes pour approuver, rejeter ou attendre.
Sous Quand de nouvelles modifications sont envoyées :
Sélectionnez Exiger au moins une approbation sur la dernière itération pour exiger au moins un vote d'approbation pour la dernière modification de la branche source. L'approbation de l'utilisateur n'est pas prise en compte pour les itérations précédentes non approuvées qu'il a poussées. Par conséquent, un autre utilisateur doit approuver la dernière itération. Exiger au moins une approbation à chaque itération est disponible dans Azure DevOps Server 2022.1 et versions ultérieures.
Sélectionnez Exiger au moins une approbation sur la dernière itération pour exiger au moins un vote d’approbation pour la dernière modification de la branche source.
Sélectionnez Réinitialiser tous les votes d'approbation (ne réinitialise pas les votes pour rejeter ou attendre) pour supprimer tous les votes d'approbation, mais conserver les votes pour rejeter ou attendre, chaque fois que la branche source change,
Sélectionnez Réinitialiser tous les votes du réviseur de code pour supprimer tous les votes du réviseur chaque fois que la branche source change, y compris les votes pour approuver, rejeter ou attendre.
Si l'option Les requérants peuvent approuver leurs propres modifications n'est pas sélectionnée, le créateur de la demande de retrait peut toujours voter pour approuver sa demande de retrait, mais son vote n'est pas pris en compte dans le calcul du nombre minimum de réviseurs.
Si un réviseur rejette les modifications, la demande de tirage ne peut pas se terminer, sauf si vous sélectionnez Autoriser l’achèvement même si certains réviseurs votent pour attendre ou rejeter.
Vous pouvez réinitialiser les votes du réviseur de code lorsque de nouvelles modifications sont envoyées à la branche source. Sélectionnez Réinitialiser les votes du réviseur de code lorsqu’il existe de nouvelles modifications.
Si toutes les autres stratégies passent, le créateur peut terminer la demande de tirage lorsque le nombre requis de réviseurs l’approuve.
Autoriser les votes inférieurs. Valeurs acceptées : false, true. Requis.
blocking
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true. Requis.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main. Requis.
creator-vote-counts
Compter le vote du créateur. Valeurs acceptées : false, true. Requis.
enabled
Activez la stratégie. Valeurs acceptées : false, true. Requis.
minimum-approver-count
Nombre minimal d’approbateurs requis. Par exemple : 2. Requis.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Requis.
reset-on-source-push
Réinitialisez les votes lorsque les modifications sont envoyées à la source. Valeurs acceptées : false, true. Requis.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré par défaut ou récupéré par le biais de la configuration git.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
Exemple
L’exemple suivant définit le nombre minimal d’approbations requises pour 2 les demandes de tirage dans la main branche du référentiel Fabrikam. La stratégie autorise les votes inférieurs, ce qui signifie que les demandes de tirage peuvent être effectuées même si certains réviseurs votent pour ne pas approuver, tant que le nombre minimal vote pour approuver. Les envois vers la branche source ne réinitialisent pas les votes. La stratégie permet également aux créateurs de demandes de tirage d’approuver leurs propres demandes de tirage.
Cet exemple utilise la configuration az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber" par défaut.
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
Mettre à jour la stratégie de nombre d’approbateurs
Autoriser les votes inférieurs. Valeurs acceptées : false, true.
blocking
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
creator-vote-counts
Compter le vote du créateur. Valeurs acceptées : false, true.
Activez la stratégie. Valeurs acceptées : false, true.
minimum-approver-count
Nombre minimal d’approbateurs requis. Par exemple : 2.
org
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré comme valeur par défaut ou récupéré par le biais de la configuration Git.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
reset-on-source-push
Réinitialisez les votes lorsque les modifications sont envoyées à la source. Valeurs acceptées : false, true.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
Les commandes Azure DevOps CLI ne sont pas prises en charge pour Azure DevOps Server.
Rechercher les éléments de travail liés
Pour le suivi de la gestion des éléments de travail, vous pouvez exiger des associations entre les demandes de tirage et les éléments de travail. La liaison d’éléments de travail fournit un contexte supplémentaire pour vos modifications et garantit que les mises à jour passent par votre processus de suivi des éléments de travail.
Pour définir la stratégie, sous Stratégiesde branche, définissez Activé pour rechercher les éléments de travail liés. Ce paramètre nécessite que les éléments de travail soient liés à une demande de tirage pour que la demande de tirage soit fusionnée. Définissez le paramètre Facultatif pour avertir s’il n’existe aucun élément de travail lié, mais autorisez l’achèvement de la demande de tirage.
Vous pouvez utiliser Azure CLI az repos policy work-item-linking pour créer et mettre à jour des stratégies de liaison d’élément de travail pour une branche ou un référentiel.
Créer une stratégie de liaison d’élément de travail
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true. Requis.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main. Requis.
enabled
Activez la stratégie. Valeurs acceptées : false, true. Requis.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré par défaut ou récupéré par le biais de la configuration git.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
Mettre à jour la stratégie de liaison d’éléments de travail
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
Activez la stratégie. Valeurs acceptées : false, true.
minimum-approver-count
Nombre minimal d’approbateurs requis. Par exemple : 2.
org
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré comme valeur par défaut ou récupéré par le biais de la configuration Git.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
Exemple
L’exemple suivant met à jour l’ID 3 de stratégie pour la main branche du référentiel Fabrikam à activer, mais facultatif. L’exemple utilise la configuration az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber" par défaut.
>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
Les commandes Azure DevOps CLI ne sont pas prises en charge pour Azure DevOps Server.
Vérifier la résolution des commentaires
La stratégie de résolution de commentaires vérifie si tous les commentaires de demande de tirage sont résolus.
Configurez une stratégie de résolution de commentaires pour votre branche en définissant Vérifier la résolutionde commentaires sur Activé. Ensuite, indiquez si la stratégie doit être obligatoire ou facultative.
Pour plus d’informations sur l’utilisation des commentaires de demande de tirage, consultez Vérifier les demandesde tirage.
Configurez une stratégie de résolution de commentaires pour votre branche en sélectionnant Vérifier la résolutionde commentaires.
Pour plus d’informations sur l’utilisation des commentaires de demande de tirage, consultez Vérifier les demandesde tirage.
Vous pouvez utiliser Azure DevOps CLI az repos policy comment-required pour définir et mettre à jour la stratégie de résolution des commentaires.
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true. Requis.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main. Requis.
enabled
Activez la stratégie. Valeurs acceptées : false, true. Requis.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Requis.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré par défaut ou récupéré par le biais de la configuration git.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
Mettre à jour la stratégie de résolution de commentaires
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
Activez la stratégie. Valeurs acceptées : false, true.
org
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré comme valeur par défaut ou récupéré par le biais de la configuration Git.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
Exemple
L’exemple suivant met à jour l’ID 6 de stratégie de résolution des commentaires dans la main branche du référentiel Fabrikam pour qu’il soit bloquant. Les commentaires doivent être résolus avant que les demandes de tirage puissent fusionner. Cet exemple utilise la configuration az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber" par défaut.
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
Les commandes Azure DevOps CLI ne sont pas prises en charge pour Azure DevOps Server.
Limiter les types de fusion
Azure Repos a plusieurs stratégies de fusion et, par défaut, toutes sont autorisées. Vous pouvez conserver un historique de branche cohérent en appliquant une stratégie de fusion pour l’achèvement des demandes de tirage.
Définissez Limiter les types de fusion sur Activé pour limiter les types de fusion à autoriser dans votre référentiel.
La fusion de base (sans transfert rapide) crée un commit de fusion dans la cible dont les parents sont la cible et les branches sources.
La fusion Squash crée un historique linéaire avec un commit unique dans la branche cible avec les modifications de la branche source. En savoir plus sur la fusion Squash et la façon dont elle affecte l’historique des branches.
Le rebasage et l’avance rapide créent un historique linéaire en relisant les commits sources sur la branche cible sans commit de fusion.
Rebaser avec le commit de fusion relit les commits sources sur la cible et crée également un commit de fusion.
Notes
Cette fonctionnalité est disponible pour Azure DevOps Server 2020 et versions ultérieures.
Vous pouvez utiliser Azure DevOps CLI az repos policy merge-strategy pour définir et mettre à jour la stratégie de stratégie de fusion.
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true. Requis.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main. Requis.
enabled
Activez la stratégie. Valeurs acceptées : false, true. Requis.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Requis.
allow-no-fast-forward
Fusion de base sans avance rapide. Conserve l’historique non linéaire exactement comme il s’est produit pendant le développement. Valeurs acceptées : false, true.
allow-rebase
Rebasez et avancez rapidement. Crée un historique linéaire en réexécutant les commits de la branche source sur la cible sans commit de fusion. Valeurs acceptées : false, true.
allow-rebase-merge
Rebasez avec commit de fusion. Crée un historique semi-linéaire en réexécutant les commits de la branche source sur la cible, et en créant ensuite un commit de fusion. Valeurs acceptées : false, true.
allow-squash
Fusion Squash. Crée un historique linéaire en condensant les commits de la branche source en un seul nouveau commit sur la branche cible. Valeurs acceptées : false, true.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré par défaut ou récupéré par le biais de la configuration git.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
use-squash-merge
Toujours la fusion Squash. Cette option n’est pas disponible pour d’autres types de fusion. Valeurs acceptées : false, true.
Remarque : use-squash-merge est déconseillée et sera supprimée dans une mise en production ultérieure. Utilisez --allow-squash à la place.
Exemple
L’exemple suivant définit une stratégie de fusion requise pour les demandes de tirage dans la main branche du référentiel Fabrikam afin d’autoriser la fusion Squash. Cet exemple utilise la configuration az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber" par défaut.
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
Mettre à jour une stratégie de stratégie de fusion
Fusion de base sans avance rapide. Conserve l’historique non linéaire exactement comme il s’est produit pendant le développement. Valeurs acceptées : false, true.
allow-rebase
Rebasez et avancez rapidement. Crée un historique linéaire en réexécutant les commits de la branche source sur la cible sans commit de fusion. Valeurs acceptées : false, true.
allow-rebase-merge
Rebasez avec commit de fusion. Crée un historique semi-linéaire en réexécutant les commits de la branche source sur la cible, et en créant ensuite un commit de fusion. Valeurs acceptées : false, true.
allow-squash
Fusion Squash. Crée un historique linéaire en condensant les commits de la branche source en un seul nouveau commit sur la branche cible. Valeurs acceptées : false, true.
blocking
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
Activez la stratégie. Valeurs acceptées : false, true.
org
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré comme valeur par défaut ou récupéré par le biais de la configuration Git.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
use-squash-merge
S’il faut toujours effectuer une fusion Squash. Cette option ne fonctionne pas pour d’autres types de fusion. Valeurs acceptées : false, true.
Les commandes Azure DevOps CLI ne sont pas prises en charge pour Azure DevOps Server.
Appliquer une stratégie de fusion
Conservez un historique de branche cohérent en appliquant une stratégie de fusion à la fin d’une demande de tirage.
Sélectionnez Appliquer une stratégie de fusion et choisissez une option pour exiger que les demandes de tirage soient fusionnées à l’aide de cette stratégie.
Pas de fusion rapide : cette option fusionne l’historique de commit de la branche source lorsque la demande de tirage se ferme et crée un commit de fusion dans la branche cible.
Fusion squash : effectuez toutes les demandes de tirage avec une fusion Squash, en créant un commit unique dans la branche cible avec les modifications de la branche source. En savoir plus sur la fusion Squash et la façon dont elle affecte votre historique des branches.
Validation de build
Vous pouvez définir une stratégie nécessitant des modifications de la demande de tirage pour générer correctement avant que la demande de tirage ne puisse se terminer.
Les stratégies de build réduisent les interruptions et conservent les résultats de vos tests. Les stratégies de génération aident même si vous utilisez l’intégration continue (CI) sur vos branches de développement pour détecter les problèmes au début.
Une stratégie de validation de build met en file d’attente une nouvelle build lorsqu’une nouvelle demande de tirage est créée ou que des modifications sont envoyées à une demande de tirage existante qui cible la branche. La stratégie de génération évalue les résultats de build pour déterminer si la demande de tirage peut être terminée.
Important
Avant de spécifier une stratégie de validation de build, vous devez disposer d’un pipeline de build. Si vous n’avez pas de pipeline, consultez Créer un pipelinede build. Choisissez le type de build qui correspond à votre type de projet.
Sélectionnez le + bouton en regard de la validation de build.
Remplissez le formulaire Définir la stratégie de génération :
Sélectionnez le pipeline debuild.
Définissez éventuellement un filtre Chemin d’accès. En savoir plus sur les filtres Chemin d’accès dans les stratégies de branche.
Sous Déclencheur, sélectionnez Automatique (chaque fois que la branche source est mise à jour) ou Manuel.
Sous Condition requise pour la stratégie, sélectionnez Obligatoire ou Facultatif. Si vous choisissez Obligatoire, les builds doivent se terminer correctement pour terminer les demandes de tirage. Choisissez Facultatif pour fournir une notification de l’échec de build, mais autorisez toujours la fin des demandes de tirage.
Définissez une expiration de build pour vous assurer que les mises à jour de votre branche protégée n’interrompent pas les modifications pour les demandes de tirage ouvertes.
Immédiatement lorsque <le nom> de la branche est mis à jour : cette option définit l’état de la stratégie de génération de demande de tirage surl’échec chaque fois que la branche est mise à jour et remet en file d’attente une build. Ce paramètre garantit que les modifications de demande de tirage sont correctement générées même si la branche protégée change.
Cette option est optimale pour les équipes dont les branches importantes ont peu de modifications. Les équipes travaillant dans des branches de développement très fréquentées peuvent trouver perturbant d'attendre une compilation à chaque mise à jour de la branche.
Après <n> heures si <le nom> de la branche a été mis à jour : cette option expire la stratégie actuelle d’état lorsque la branche protégée se met à jour si la build qui passe est antérieure au seuil que vous entrez. Cette option est un compromis entre toujours ou ne nécessitant jamais de build lorsque la branche protégée est mise à jour. Ce choix réduit le nombre de builds lorsque votre branche protégée a des mises à jour fréquentes.
Jamais : les mises à jour de la branche protégée ne modifient pas l’état de la stratégie. Cette valeur réduit le nombre de builds, mais peut causer des problèmes lors de l'achèvement de PRs qui n'ont pas été mis à jour récemment.
Entrez un nom d’affichage facultatif pour cette stratégie de build. Ce nom identifie la stratégie dans la page Stratégies de branche. Si vous ne spécifiez pas de nom d’affichage, la stratégie utilise le nom du pipeline de build.
Sélectionnez Enregistrer.
Lorsque le propriétaire de la demande de tirage envoie des modifications qui sont correctement générés, la stratégie statut est mise à jour.
Si vous disposez d’une stratégie de build Immédiatement quand le <nom> de la branche est mis à jour ou Après <n> heures si <le nom> de la branche a été mis à jour, la stratégie d’état est mise à jour lorsque le branche protégée se met à jour, si la build précédente n’est plus valide.
Notes
Cette fonctionnalité est disponible pour Azure DevOps Server 2020 et versions ultérieures.
Vous pouvez utiliser Azure DevOps CLI az repos policy build pour définir et mettre à jour la stratégie de validation de build.
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true. Requis.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main. Requis.
build-definition-id
ID de définition de build. Requis.
display-name
Nom d’affichage de cette stratégie de build pour identifier la stratégie. Par exemple : Manual queue policy. Requis.
enabled
Activez la stratégie. Valeurs acceptées : false, true. Requis.
manual-queue-only
Indique s’il faut autoriser uniquement la file d’attente manuelle des builds. Valeurs acceptées : false, true. Requis.
queue-on-source-update-only
S’il faut mettre en file d’attente les builds uniquement lors des mises à jour de la source. Valeurs acceptées : false, true. Requis.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Requis.
valid-duration
Durée de validité de la stratégie, en minutes. Note : valid-duration doit être compris entre zéro et un an, et doit être égal à zéro lorsque --queue-on-source-update-only est false. Requis.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
path-filter
Chemin sur lequel la stratégie est appliquée. Prend en charge les chemins d’accès absolus, les caractères génériques et plusieurs chemins séparés par ;. Exemples : /WebApp/Models/Data.cs, /WebApp/*ou *.cs, ou /WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré par défaut ou récupéré par le biais de la configuration git.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
Exemple
L’exemple suivant définit une stratégie de génération requise pour les demandes de tirage dans la main branche du référentiel Fabrikam. La stratégie nécessite une build réussie de l’ID 1de définition de build et autorise uniquement la mise en file d’attente manuelle de build. Cet exemple utilise la configuration az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber" par défaut.
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
Mettre à jour une stratégie de validation de build
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
Nom d’affichage de cette stratégie de build pour identifier la stratégie. Par exemple : Manual queue policy.
enabled
Activez la stratégie. Valeurs acceptées : false, true.
manual-queue-only
Indique s’il faut autoriser uniquement la file d’attente manuelle des builds. Valeurs acceptées : false, true.
org
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
path-filter
Chemins sur lesquels la stratégie est appliquée. Prend en charge les chemins d’accès absolus, les caractères génériques et plusieurs chemins séparés par ;. Exemples : /WebApp/Models/Data.cs, /WebApp/*ou *.cs, ou /WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré comme valeur par défaut ou récupéré par le biais de la configuration Git.
queue-on-source-update-only
S’il faut mettre en file d’attente les builds uniquement lors des mises à jour de la source. Valeurs acceptées : false, true.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
valid-duration
Durée de validité de la stratégie, en minutes.
Les commandes Azure DevOps CLI ne sont pas prises en charge pour Azure DevOps Server.
Définissez une stratégie nécessitant des modifications dans une demande de tirage pour générer correctement avec la branche protégée avant la fin de la demande de tirage.
Les stratégies de build réduisent les interruptions et conservent les résultats de vos tests. Les stratégies de génération aident même si vous utilisez l’intégration continue (CI) sur vos branches de développement pour détecter les problèmes au début.
Si une stratégie de validation des builds est activée, un nouveau build est mis en file d'attente lorsqu'une nouvelle pull request est créée ou lorsque des modifications sont pushées dans une pull request existante qui cible la branche. La stratégie de build évalue ensuite les résultats de la build pour déterminer si la demande de tirage peut être terminée.
Important
Avant de spécifier une stratégie de validation de build, vous devez avoir une définition de build. Si vous n’en avez pas, consultez Créer une définition de build et choisissez le type de build qui correspond à votre type de projet.
Choisissez Ajouter une stratégie de build et configurez vos options dans Ajouter une stratégiede build.
Sélectionnez la Définition de build.
Choisissez le type de déclencheur. Sélectionnez Automatique (chaque fois que la branche source est mise à jour) ou Manuel.
Sélectionnez l’exigence de stratégie. Si vous choisissez Obligatoire, les builds doivent se terminer correctement pour effectuer des demandes de tirage. Choisissez Facultatif pour fournir une notification de l’échec de build, mais autorisez toujours la fin des demandes de tirage.
Définissez une expiration de build pour vous assurer que les mises à jour de votre branche protégée ne interrompent pas les modifications pour les demandes de tirage ouvertes.
Immédiatement lorsqu’elle branch name est mise à jour : cette option définit l’état de la stratégie de build dans une demande de tirage pour qu’elle échoue lorsque la branche protégée est mise à jour. Remettre en file d’attente une build pour actualiser l’état de la build. Ce paramètre garantit que les modifications apportées aux demandes de tirage sont correctement générés, même lorsque la branche protégée change. Cette option est optimale pour les équipes qui ont des branches importantes avec un volume inférieur de modifications. Les équipes travaillant dans des branches de développement très occupées peuvent trouver perturbant d'attendre la fin d'une compilation à chaque fois que la branche protégée est mise à jour.
Après n les heures de branch name mise à jour : cette option expire l’état actuel de la stratégie lorsque la branche protégée est miseà jour si la build passée est antérieure au seuil entré. Cette option est un compromis entre toujours exiger une build lorsque la branche protégée est mise à jour et n’en nécessite jamais. Ce choix est excellent pour réduire le nombre de builds lorsque votre branche protégée a des mises à jour fréquentes.
Jamais : les mises à jour de la branche protégée ne modifient pas l’état de la stratégie. Cette valeur réduit le nombre de builds de votre branche. Cela peut poser des problèmes lors de la fermeture de requêtes pull qui n'ont pas été mises à jour récemment.
Entrez un nom d’affichage facultatif pour cette stratégie de build. Ce nom identifie la stratégie dans la page Stratégies de branche. Si vous ne spécifiez pas de nom d’affichage, la stratégie utilise le nom de définition de build.
Sélectionnez Enregistrer.
Lorsque le propriétaire envoie les modifications qui sont générées avec succès, l’état de la stratégie est mis à jour. Si vous avez choisi une stratégie de build Immédiatement quand branch name est mise à jour ou Après n les heures si branch name a été mise à jour, le statut de la stratégie est mis à jour lorsque la branche protégée est mise à jour si la build la plus récente n’est plus valide.
Vérifications d'état
Les services externes peuvent utiliser l’API d’état de la demande de tirage pour publier un état détaillé sur vos demandes de tirage. La stratégie de branche pour les services supplémentaires permet à ces services externes de participer au workflow de PR et d'établir des exigences en matière de stratégie.
Les services externes peuvent utiliser l’API d’état de la demande de tirage pour publier un état détaillé sur vos demandes de tirage. La stratégie de branche pour les services supplémentaires permet à ces services externes de participer au workflow des RP et d'établir des exigences en matière de politiques.
Vous pouvez ajouter automatiquement des réviseurs à des demandes de tirage qui modifient des fichiers dans des répertoires et des fichiers spécifiques, ou à toutes les demandes de tirage dans un dépôt.
Sélectionnez le bouton + en regard de Réviseurs inclus automatiquement.
Renseignez l’écran Ajouter une nouvelle stratégie de réviseur.
Ajoutez des personnes et des groupes auxréviseurs.
Sélectionnez Facultatif si vous souhaitez ajouter automatiquement des réviseurs, mais ne nécessitent pas leur approbation pour terminer la demande de tirage.
Vous pouvez également sélectionner Obligatoire si les demandes de tirage ne peuvent pas être terminées tant que :
Chaque personne ajoutée en tant que réviseur approuve les modifications.
Au moins une personne dans chaque groupe ajoutée en tant que réviseur approuve les modifications.
Si un seul groupe est requis, le nombre minimal de membres que vous spécifiez approuve les modifications.
Spécifiez les fichiers et dossiers qui nécessitent les réviseurs inclus automatiquement. Laissez ce champ vide pour demander aux réviseurs de toutes les demandes de tirage dans la branche.
Sélectionnez Autoriser les demandeurs à approuver leurs propres modifications si les propriétaires de demandes de tirage peuvent voter pour approuver leurs propres demandes de tirage pour satisfaire à cette stratégie.
Vous pouvez spécifier un message de flux d’activité qui apparaît dans la demande de tirage.
Sélectionnez Enregistrer.
Notes
Cette fonctionnalité est disponible pour Azure DevOps Server 2020 et versions ultérieures.
Vous pouvez utiliser Azure DevOps CLI az repos policy required-reviewer pour définir et mettre à jour la stratégie de réviseur requise.
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true. Requis.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main. Requis.
enabled
Activez la stratégie. Valeurs acceptées : false, true. Requis.
message
Message de flux d’activité qui apparaît dans la demande de tirage. Obligatoire.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345. Requis.
required-reviewer-ids
Adresses de messagerie du réviseur séparées par ;. Par exemple : john@contoso.com;alice@contoso.com.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
path-filter
Chemins sur lesquels la stratégie est appliquée. Prend en charge les chemins d’accès absolus, les caractères génériques et plusieurs chemins séparés par ;. Exemples : /WebApp/Models/Data.cs, /WebApp/*ou *.cs, ou /WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré par défaut ou récupéré par le biais de la configuration git.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
Exemple
L’exemple suivant définit Jamal Hartnett comme réviseur requis pour les demandes de tirage dans la main branche du référentiel Fabrikam. Cet exemple utilise la configuration az devops configure --defaults organization=https://dev.azure.com/fabrikamprime project="Fabrikam Fiber" par défaut.
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
Bloquer si la stratégie n’est pas remplie. Valeurs acceptées : false, true.
branch
Nom de la branche pour filtrer les résultats par correspondance exacte. Le paramètre --repository-id est requis pour utiliser le filtre de branche. Par exemple : --branch main.
branch-match-type
Utilisez l’argument branch pour appliquer la stratégie. Si la valeur est exact, la stratégie s’applique à une branche qui correspond exactement à l’argument --branch. Si la valeur est prefix, la stratégie s’applique à tous les dossiers de branche qui correspondent au préfixe dans l’argument --branch. Valeurs acceptées : exact, prefix. Valeur par défaut : exact.
Activez la stratégie. Valeurs acceptées : false, true.
message
Message de flux d’activité qui apparaît dans la demande de tirage.
org
URL de l’organisation Azure DevOps. Vous pouvez configurer l’organisation par défaut à l’aide de az devops configure -d organization=<ORG_URL>. Obligatoire s’il n’est pas configuré par défaut ou récupéré via git config. Exemple : https://dev.azure.com/MyOrganizationName/.
path-filter
Chemins sur lesquels la stratégie est appliquée. Prend en charge les chemins d’accès absolus, les caractères génériques et plusieurs chemins séparés par ;. Exemples : /WebApp/Models/Data.cs, /WebApp/*ou *.cs, ou /WebApp/Models/Data.cs;ClientApp/Models/Data.cs.
project, p
Nom ou ID du projet. Vous pouvez configurer le projet par défaut en utilisant az devops configure -d project=<NAME_OR_ID>. Obligatoire s’il n’est pas configuré comme valeur par défaut ou récupéré par le biais de la configuration Git.
repository-id
ID du référentiel pour filtrer les résultats par correspondance exacte. Par exemple : --repository-ID e556f204-53c9-4153-9cd9-ef41a11e3345.
required-reviewer-ids
Adresses de messagerie du réviseur séparées par ;. Par exemple : john@contoso.com;alice@contoso.com.
subscription
Nom ou ID de l’abonnement. Vous pouvez configurer l’abonnement par défaut en utilisant az account set -s <NAME_OR_ID>.
Les commandes Azure DevOps CLI ne sont pas prises en charge pour Azure DevOps Server.
Sélectionnez les réviseurs pour des répertoires et des fichiers spécifiques dans votre référentiel.
Ces réviseurs sont automatiquement ajoutés aux demandes de tirage qui modifient les fichiers le long de ces chemins. Vous pouvez également spécifier un message de flux d’activité.
Si vous sélectionnez Obligatoire, la demande de tirage ne peut pas être terminée tant que :
Chaque utilisateur ajouté en tant que réviseur pour le chemin approuve les modifications.
Au moins une personne de chaque groupe ajoutée au chemin d’accès approuve les modifications.
Le nombre de réviseurs spécifiés pour chaque groupe ajouté au chemin d’accès approuve les modifications.
Sélectionnez Facultatif si vous souhaitez ajouter automatiquement des réviseurs, mais ne nécessitent pas leur approbation pour terminer la demande de tirage.
Vous pouvez sélectionner les demandeurs peuvent approuver leurs propres modifications.
Lorsque tous les réviseurs requis approuvent le code, vous pouvez terminer la demande de tirage.
Contourner les stratégies de branche
Dans certains cas, vous devrez peut-être contourner les exigences de stratégie. Les autorisations de contournement vous permettent d’envoyer des modifications à une branche directement ou d’effectuer des demandes de tirage qui ne répondent pas aux stratégies de branche. Vous pouvez accorder des autorisations de contournement à un utilisateur ou un groupe. Vous pouvez étendre les autorisations de contournement à un projet entier, à un référentiel ou à une seule branche.
Deux autorisations permettent aux utilisateurs de contourner la stratégie de branche de différentes manières :
Contourner les stratégies lors de l’exécution des demandes de tirage s’applique uniquement à l’achèvement de la demande de tirage. Les utilisateurs disposant de cette autorisation peuvent effectuer des demandes de tirage même si les demandes de tirage ne répondent pas aux stratégies.
Les stratégies de contournement lors de l’envoi s’appliquent aux envois à partir de référentiels locaux et aux modifications effectuées sur le web. Les utilisateurs disposant de cette autorisation peuvent envoyer des modifications directement aux branches protégées sans répondre aux exigences de stratégie.
Pour plus d’informations sur la gestion de ces autorisations, consultez AutorisationsGit.
Dans TFS 2015 à TFS 2018 Update 2, l’autorisation Exempt de l’application de la stratégie permet aux utilisateurs disposant de cette autorisation d’effectuer les actions suivantes :
Accepter de remplacer les stratégies et de compléter une requête pull même si l'ensemble actuel des stratégies de la branche n'est pas satisfait.
Envoyer directement à une branche, même si des stratégies de branche sont définies. Lorsqu'un utilisateur disposant de cette permission effectue un push qui remplacerait la stratégie de la branche, le push contourne automatiquement la stratégie de la branche sans étape d'acceptation ou d'avertissement.
Important
Soyez prudent lorsque vous accordez la possibilité de contourner les stratégies, en particulier au niveau du référentiel et du projet. Les stratégies sont une pierre angulaire de la gestion du code source sécurisée et conforme.
Filtres de chemin
Plusieurs stratégies de branche offrent des filtres de chemin d’accès. Si un filtre de chemin d’accès est défini, la stratégie s’applique uniquement aux fichiers qui correspondent au filtre de chemin d’accès. Laisser ce champ vide signifie que la stratégie s’applique à tous les fichiers de la branche.
Vous pouvez spécifier des chemins absolus (le chemin doit commencer par / ou un caractère générique) et des caractères génériques.
Exemples :
/WebApp/Models/Data.cs
/WebApp/*
*/Models/Data.cs
*.cs
Vous pouvez spécifier plusieurs chemins en utilisant ; comme séparateur.
Exemple :
/WebApp/Models/Data.cs;/ClientApp/Models/Data.cs
Les chemins préfixés par ! sont exclus s’ils seraient autrement inclus.
Exemple :
/WebApp/*;!/WebApp/Tests/* inclut tous les fichiers dans /WebApp, à l’exception des fichiers dans /WebApp/Tests
!/WebApp/Tests/* ne spécifie aucun fichier, car rien n’est inclus en premier
L’ordre des filtres est significatif. Les filtres sont appliqués de gauche à droite.
Puis-je envoyer des modifications directement aux branches qui ont des stratégies de branche ?
Vous ne pouvez pas pousser des changements directement vers des branches avec des stratégies de branche requises à moins que vous n'ayez la permission de contourner les politiques de branche. Les modifications apportées à ces branches ne peuvent être apportées qu’à l’aide de demandesde tirage. Vous pouvez envoyer des modifications directement aux branches qui ont des stratégies de branche facultatives, si elles n’ont aucune stratégie de branche requise.
Qu’est-ce que la saisie semi-automatique ?
Les demandes de tirage dans des branches avec des stratégies de branche configurées ont le bouton Définir la saisie semi-automatique. Sélectionnez cette option pour terminer automatiquement la demande de tirage une fois qu’elle répond à toutes les stratégies. La saisie semi-automatique est utile lorsque vous ne vous attendez pas à des problèmes avec vos modifications.
Quand les conditions de stratégie de branche sont-elles vérifiées ?
Les stratégies de branche sont réévaluées sur le serveur lorsque les propriétaires de demandes de tirage poussent les modifications et lorsque les réviseurs votent. Si une stratégie déclenche une build, l’état de la build est en attente jusqu’à la fin de la génération.
Puis-je utiliser des définitions de build XAML dans les stratégies de branche ?
Non, vous ne pouvez pas utiliser les définitions de build XAML dans les stratégies de branche.
Quels caractères génériques puis-je utiliser pour les réviseurs de code requis ?
Les astérisques * simples correspondent à n’importe quel nombre de caractères, y compris les barres obliques / et les barres obliques inverses\. Les points d’interrogation ? correspondent à n’importe quel caractère unique.
Exemples :
*.sql correspond à tous les fichiers avec l’extension .sql.
/ConsoleApplication/* correspond à tous les fichiers sous le dossier nommé ConsoleApplication.
/.gitattributes correspond au fichier .gitattributes* à la racine du référentiel.
*/.gitignore correspond à n’importe quel fichier .gitignore dans le référentiel.
Les chemins d’accès du réviseur de code requis respectent-ils la casse ?
Non, les stratégies de branche ne respectent pas la casse.
Comment puis-je configurer plusieurs utilisateurs en tant que réviseurs requis, mais exiger qu’un seul d’entre eux approuve ?
Vous pouvez ajouter les utilisateurs à un groupe, puis ajouter le groupe en tant que réviseur. Tout membre du groupe peut ensuite approuver pour répondre à l’exigence de stratégie.
J’ai des autorisations de stratégie de contournement. Pourquoi les échecs de stratégie sont-ils toujours présents dans les statuts de demande de tirage ?
Les stratégies configurées sont toujours évaluées pour les modifications apportées aux demandes de tirage. Pour les utilisateurs disposant d’autorisations de contournement de stratégie, l’état de la stratégie signalée est consultatif uniquement. Si l’utilisateur disposant d’autorisations de contournement approuve, l’état d’échec ne bloque pas l’achèvement de la demande de tirage.
Pourquoi ne puis-je pas terminer mes propres demandes de tirage lorsque « Autoriser les demandeurs à approuver leurs propres modifications est défini » ?
La stratégie Exiger un nombre minimal de réviseurs et la stratégie Réviseurs inclus automatiquement ont toutes deux des options permettant d’autoriser les demandeurs à approuver leurs propres modifications. Dans chaque stratégie, le paramètre s’applique uniquement à cette stratégie. Le paramètre n’affecte pas l’autre stratégie.
Par exemple, votre demande de tirage a les stratégies suivantes définies :
Exiger un nombre minimal de réviseurs nécessite au moins un réviseur.
Les réviseurs inclus automatiquement nécessitent que vous ou une équipe que vous soyez en tant que réviseur.
Les réviseurs inclus automatiquement ont activé l’option Autoriser les demandeurs à approuver leurs propres modifications.
Exiger qu’un nombre minimal de réviseurs n’ait pas activé l’option Autoriser les demandeurs à approuver leurs propres modifications.
Dans ce cas, votre approbation satisfait automatiquement les réviseurs inclus, mais ne nécessite pas un nombre minimal de réviseurs, de sorte que vous ne pouvez pas terminer la demande de tirage.
Il peut également y avoir d’autres stratégies, telles que Interdire au pusher le plus récent d’approuver leurs propres modifications, qui vous empêchent d’approuver vos propres modifications même si l’option Autoriser les demandeurs à approuver leurs propres modifications est définie.
Que se passe-t-il lorsque le chemin d'accès dans les filtres de chemin d'accès ne commence pas par / ou par un caractère générique ?
Le chemin d'accès dans les filtres de chemin d'accès qui ne commence pas par / ou par un caractère générique n'a aucun effet, et le filtre de chemin d'accès est évalué comme si ce chemin d'accès n'avait pas été spécifié. Un tel chemin ne peut pas correspondre au / par lequel commence le chemin d'accès absolu au fichier.
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir: https://aka.ms/ContentUserFeedback.