Définir et gérer des stratégies de branche

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Utilisez des stratégies de branche pour protéger les branches importantes en exigeant des pull requests, des examinateurs, des compilations et d’autres vérifications avant de fusionner les modifications. Cet article explique comment configurer et gérer des stratégies de branche dans le portail web Azure DevOps et Azure DevOps CLI. Pour obtenir un résumé des stratégies de branche disponibles et des conseils de branchement, consultez À propos des branches et des stratégies de branche.

Pour obtenir un guide de sécurité complet couvrant les stratégies de branche, le contrôle d’accès au référentiel, la signature de validation et les scénarios d’implémentation réels, consultez référentiels sécurisés et demandes de tirage ( pull request).

Vous ne pouvez pas supprimer une branche sur laquelle des stratégies obligatoires sont configurées, et toutes les modifications doivent être effectuées via des pull requests (PR).

Conseil / Astuce

Vous pouvez utiliser l’IA pour vous aider à effectuer cette tâche plus loin dans cet article, ou voir Activer l’aide à l’IA avec Azure DevOps MCP Server pour commencer.

Prérequis

Requirement Détails
Permissions Soyez membre du groupe de sécurité Project Administrators, ou disposez d’autorisations Modifier les stratégies au niveau du dépôt. Pour plus d’informations, consultez Configurer les autorisations du dépôt Git.
configuration de l’interface CLI Azure DevOps (facultatif) Pour utiliser les commandes Azure DevOps CLI az repos policy, suivez la procédure Prise en main d’Azure DevOps CLI.
Ciblage de référentiel pour l’interface CLI (facultatif) Avant de créer ou de mettre à jour des stratégies dans l’interface CLI, identifiez l’ID du référentiel en exécutant az repos list. Pour éviter de répéter --org et --project, définissez des valeurs par défaut avec az devops configure --defaults.
Dépendances de stratégie Avant de configurer la validation de build, disposez d’un pipeline de build prêt. Avant de configurer les vérifications d’état, assurez-vous que le service externe ou l’intégration native peut déjà publier un état de pull request.
Configuration de l’assistance à l’IA (facultatif) Pour utiliser l’assistance ia avec Azure DevOps MCP Server, utilisez Azure DevOps Services, activez le mode agent dans votre assistant IA et installez Node.js 20.0+. Pour plus d’informations, consultez Activer l’assistance IA avec Azure DevOps MCP Server.
Requirement Détails
Permissions Être membre du groupe de sécurité Project Administrators, ou disposer des autorisations Modifier les stratégies au niveau du dépôt. Pour plus d’informations, consultez Configurer les autorisations du dépôt Git.

Ouvrir les paramètres de stratégie de branche

Pour ouvrir les paramètres de stratégie de branche dans le portail web :

  1. Sélectionnez Référentiels >Branches.
  2. Recherchez la branche que vous souhaitez gérer.
  3. Sélectionnez l’icône Autres options en regard de la branche, puis sélectionnez Stratégies de branche.

Capture d’écran montrant l’élément de menu Branches.

Vous pouvez également ouvrir les paramètres de stratégie de branche à partir de Paramètres du projet>Dépôt>Stratégies>Stratégies de branche><Nom de la branche>.

Les branches qui ont des stratégies affichent une icône de stratégie. Sélectionnez l’icône pour accéder directement aux paramètres de stratégie de la branche.

Vous pouvez parcourir la liste ou rechercher la branche dans la zone nom de la branche de recherche .

Capture d’écran montrant Ouvrir les stratégies de branche à partir du menu contextuel.

Configurez des stratégies sur la page des paramètres de la branche. Utilisez les sections suivantes pour activer ou mettre à jour une stratégie existante.

Définir une stratégie de réviseur minimale

Exiger l’approbation d’un nombre minimum de réviseurs avant qu’une pull request puisse être finalisée.

Pour définir la stratégie, sous Stratégies de 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 :

Capture d’écran montrant la stratégie Activer la stratégie Exiger les révisions de code.

  • 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 Approuver sur la PR, mais son vote ne compte pas dans le nombre minimum de réviseurs.

  • Sélectionnez Empêcher l'auteur des dernières modifications d’approuver ses propres changements pour appliquer la séparation des responsabilités. 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 encore donner son approbation.

  • Sous Quand de nouvelles modifications sont poussé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 toutes les autres stratégies passent, le créateur peut terminer la demande de tirage lorsque le nombre requis de réviseurs l’approuve.

Exiger des éléments de travail liés

Pour le suivi de la gestion des éléments de travail, vous pouvez exiger des associations entre les PR 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égies de branche, définissez Vérifier les éléments de travail liés sur Activé. 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éfinir le paramètre Facultatif pour avertir en cas d’absence d’éléments de travail liés, mais permettre la finalisation de la pull request.

Capture d’écran de la nécessité d’éléments de travail liés dans les demandes de tirage.

Exiger une résolution de commentaires

La stratégie de résolution de commentaires vérifie si tous les commentaires de demande de tirage sont résolus.

Définissez « Vérifier la résolution des commentaires » sur « Activé » pour configurer une stratégie de résolution des commentaires pour votre branche. Ensuite, indiquez si la stratégie doit être obligatoire ou facultative.

Capture d'écran de Vérifier la résolution des commentaires.

Pour plus d’informations sur l’utilisation des commentaires de pull request, consultez Passer en revue les pull requests.

Limiter les types de fusion

Azure Repos prend en charge plusieurs stratégies de fusion, et par défaut, elle les autorise toutes. Pour conserver un historique de branche cohérent, imposez une stratégie de fusion lors de la finalisation des PR.

Définissez Limiter les types de fusion sur Activé pour limiter les types de fusion autorisés dans votre dépôt.

Capture d'écran de Limiter les types de fusion.

  • 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.
  • Le squash merge crée un historique linéaire avec un seul commit dans la branche cible, qui inclut 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.

Définir la validation de build

Définissez une règle imposant que les 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.

Lorsque vous définissez le déclencheur de stratégie sur Automatique, une stratégie de validation de build met en file d’attente un nouveau build lorsque vous créez une demande de tirage ou poussez des modifications vers une demande de tirage existante ciblant la branche. Si vous définissez le déclencheur de stratégie sur Manuel, les utilisateurs doivent eux-mêmes mettre la génération en file d’attente. Dans les deux cas, 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, créez un pipeline de build. Si vous n’avez pas de pipeline, consultez Créer un pipeline de build. Choisissez le type de build qui correspond à votre type de projet.

Pour ajouter une stratégie de validation de build

  1. Sélectionnez le bouton + en regard de la validation de build.

    Capture d’écran montrant le bouton Ajouter en regard de la validation de build.

  2. Remplissez le formulaire Définir la stratégie de génération :

    Capture d'écran des paramètres de la stratégie de construction.

    • Sélectionnez le pipeline debuild.

  • Définissez éventuellement un filtre Chemin d’accès. En savoir plus sur les filtres de chemin dans les stratégies de branche.

  • Sous Déclencheur, sélectionnez Automatique (chaque fois que la branche source est mise à jour) ou Manuel.

  • Sous exigence de la politique, 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 sur l’é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.

  1. 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 la branche protégée se met à jour, si la build précédente n’est plus valide.

Exiger des vérifications de statut

Les services externes peuvent utiliser l'API d'état de PR pour publier un état détaillé sur vos PRs. 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.

Capture d'écran de Require external services to approve (Exiger l'approbation des services externes).

Pour configurer une stratégie de vérification du statut :

  1. Assurez-vous que le service peut publier l’état de la pull request dans Azure Repos.
  2. Dans les stratégies de branche, sous Vérifications d’état, sélectionnez +.
  3. Dans État à vérifier, sélectionnez la vérification publiée dans la liste. Si le service n’a pas encore publié l’état, tapez la genre/name valeur directement.
  4. Définissez l’exigence de stratégie sur Obligatoire ou Facultatif.
  5. Configurez éventuellement l’identité autorisée, les conditions de réinitialisation, l’application de la stratégie et le filtre de chemin d’accès.
    • Utilisez Appliquer par défaut si la stratégie doit s’appliquer dès que la pull request est créée.
    • Utilisez Conditionnel si la stratégie doit s’appliquer uniquement après la publication du premier état.
  6. Créez ou mettez à jour une demande de tirage ciblant la branche, puis vérifiez que la stratégie apparaît dans la section Politiques de la demande de tirage.

Pour les vérifications intégrées d’Azure DevOps Services et leurs identifiants genre/name, consultez Vérifications d’état disponibles pour les demandes de tirage. Pour obtenir une procédure pas à pas complète de la configuration du service externe, consultez Configurer une stratégie de branche pour un service externe.

Si une nouvelle intégration n’apparaît pas encore dans la liste déroulante, publiez un statut une fois depuis le service, puis ajoutez la règle, ou saisissez directement la valeur genre/name.

Inclure automatiquement les réviseurs

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.

  1. Sélectionnez le bouton + en regard de Réviseurs inclus automatiquement.

    Capture d’écran montrant Ajouter des réviseurs requis.

  2. Renseignez l’écran Ajouter une nouvelle politique de réviseur.

    Capture d’écran montrant l’écran Ajouter un nouveau réviseur politique.

    • Ajoutez des personnes et des groupes auxréviseurs.

    • Sélectionnez Facultatif si vous souhaitez ajouter automatiquement des réviseurs, mais sans nécessiter leur approbation pour finaliser le pull request.

      Vous pouvez également sélectionner Obligatoire si les pull requests ne peuvent pas être finalisées avant 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 pull requests peuvent voter pour approuver leurs propres pull requests pour se conformer à cette politique.

    • Vous pouvez spécifier un message de flux d’activité qui apparaît dans la pull request.

  3. Sélectionnez Enregistrer.

Autoriser le contournement de la stratégie si nécessaire

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 de finaliser des pull requests qui ne satisfont pas aux stratégies de branche. Vous pouvez accorder des autorisations de contournement à un utilisateur ou un groupe et étendre ces autorisations à 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 finaliser des pull requests même si ces dernières ne respectent pas les politiques.

  • 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.

Capture d’écran montrant les autorisations d’application de stratégie de contournement.

Pour plus d’informations sur la gestion de ces autorisations, consultez AutorisationsGit.

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.

Utiliser des filtres de chemin avec des stratégies de branche

Plusieurs stratégies de branche prennent en charge des filtres de chemin d’accès. Si vous définissez un filtre de chemin d’accès, la stratégie s’applique uniquement aux fichiers qui correspondent au filtre. Laissez ce champ vide pour appliquer la stratégie à tous les fichiers de la branche.

Vous pouvez spécifier des chemins absolus (le chemin doit commencer par / ou par un caractère générique) ainsi que des caractères génériques. Exemples :

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

Vous pouvez spécifier plusieurs chemins à l’aide ; d’un séparateur. Exemple :

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Si vous faites précéder des chemins d’accès de !, vous les excluez s’ils seraient inclus autrement. 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. Appliquez des filtres de gauche à droite.

Résoudre les problèmes liés aux stratégies de branche

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. Vous ne pouvez apporter des modifications à ces branches qu’à l’aide de demandes de 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 branches avec des stratégies de branche configurées pour des demandes de tirage possèdent le bouton Définir la saisie semi-automatique. Sélectionnez cette option pour configurer une demande de tirage afin qu’elle se termine automatiquement une fois que toutes les stratégies sont satisfaites. 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 ?

Le serveur réévalue les stratégies de branche lorsque les auteurs des pull requests publient des 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 politiques 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 slashs / 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 apparaissent-ils toujours dans le statut des pull requests ?

Le système évalue toujours les stratégies configurées pour les modifications apportées à une pull request. 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 finaliser mes propres pull requests lorsque j’active « Autoriser les auteurs à approuver leurs propres modifications » ?

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 requête de fusion 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.

D’autres stratégies peuvent vous empêcher d’approuver vos propres modifications, même si Autoriser les demandeurs à approuver leurs propres modifications est activé. Par exemple, interdire à l’auteur du dernier push d’approuver ses propres modifications.

Que se passe-t-il lorsqu’un filtre de chemin d’accès ne commence pas par / ou par un caractère générique ?

Un chemin dans les filtres de chemin qui ne commence pas par / ni par un caractère générique n’a aucun effet. Le filtre de chemin est évalué comme si ce chemin n’était pas spécifié. Un tel chemin ne peut pas correspondre au / par lequel commence le chemin d'accès absolu au fichier.

Utiliser l’IA pour configurer et gérer des stratégies de branche

Si vous configurez le Azure DevOps MCP Server, vous pouvez utiliser le langage naturel pour recueillir des informations sur le dépôt, la branche, la pull request et le build avant de mettre à jour les stratégies de branche dans Azure DevOps Services.

Le serveur MCP Azure DevOps nécessite Azure DevOps Services, le mode agent dans votre assistant IA et Node.js 20.0+. La documentation MCP actuelle ne décrit pas les actions de lecture ou d'écriture de stratégie de branche directe. Utilisez donc le portail web Azure DevOps ou l'interface CLI Azure DevOps pour créer et mettre à jour des stratégies.

Tâche Exemple d’invite
Répertorier les branches dans un référentiel List the branches in repo <Contoso.Web> in project <Contoso>
Vérifiez les pull requests avant de renforcer la politique What pull requests require my review in project <Contoso>?
Examiner une pull request et les éléments de travail liés Get details for pull request <67> and its linked work items in project <Contoso>
Vérifier l’état de la build avant d’effectuer la validation de build requise Get the latest build status for pipeline <Contoso-CI> in project <Contoso>

Note

Si vous utilisez Visual Studio Code, le mode agent est particulièrement utile pour collecter le contexte du projet dont vous avez besoin avant de mettre à jour les stratégies de branche.

Contenu connexe

  • Last updated on