Notes de publication d’Azure DevOps Server 2022

---

| Conditions requises pour la communauté | des développeurs et termes | du contrat de licence de compatibilité | DevOps Blog | SHA-256 Hachages |

---

Dans cet article, vous trouverez des informations sur la version la plus récente pour Azure DevOps Server.

Pour en savoir plus sur l’installation ou la mise à niveau d’un déploiement Azure DevOps Server, consultez La configuration requise pour azure DevOps Server.

Pour télécharger des produits Azure DevOps Server, consultez la page Téléchargements du serveur Azure DevOps.

La mise à niveau directe vers Azure DevOps Server 2022 est prise en charge à partir d’Azure DevOps Server 2019 ou Team Foundation Server 2015 ou version ultérieure. Si votre déploiement TFS se trouve sur TFS 2013 ou version antérieure, vous devez effectuer certaines étapes intermédiaires avant de procéder à la mise à niveau vers Azure DevOps Server 2022. Pour plus d’informations, consultez la page Installer.

---

Date de publication d’Azure DevOps Server 2022 Update 0.1 Patch 5 : 14 novembre 2023

Remarque

Les correctifs Azure DevOps Server sont cumulatifs, si vous n’avez pas installé patch 3, ce correctif inclut les mises à jour de l’agent Azure Pipelines. La nouvelle version de l’agent après l’installation de Patch 5 sera 3.225.0.

File	Hachage SHA-256
devops2022.0.1patch5.exe	DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

Nous avons publié un correctif pour Azure DevOps Server 2022 Update 0.1 qui inclut des correctifs pour les éléments suivants.

• Étendue de la liste des caractères autorisés pour activer la validation des arguments des tâches de l’interpréteur de commandes.
• Corrigez un problème qui entraînait la persistance des modifications des connexions de service après avoir cliqué sur le bouton Annuler.

Date de publication d’Azure DevOps Server 2022 Update 0.1 Patch 4 : 10 octobre 2023

Remarque

Les correctifs Azure DevOps Server sont cumulatifs, si vous n’avez pas installé patch 3, ce correctif inclut les mises à jour de l’agent Azure Pipelines. La nouvelle version de l’agent après l’installation de Patch 5 sera 3.225.0.

Nous avons publié un correctif pour Azure DevOps Server 2022 Update 0.1 qui inclut des correctifs pour les éléments suivants.

• Correction d’un bogue qui entraînait le blocage des pipelines en mettant à niveau le modèle d’exécution du pipeline.
• Correction d’un bogue dans lequel l’identité « Propriétaire d’analyse » s’affichait comme Une identité inactive sur les ordinateurs de mise à niveau des correctifs.
• Le travail de nettoyage de build contient de nombreuses tâches, chacune supprimant un artefact pour une build. Si l’une de ces tâches a échoué, aucune des tâches suivantes n’a été exécutée. Nous avons modifié ce comportement pour ignorer les échecs de tâche et nettoyer autant d’artefacts que possible.

Date de publication d’Azure DevOps Server 2022 Update 0.1 Patch 3 : 12 septembre 2023

Remarque

Ce correctif inclut des mises à jour de l’agent Azure Pipelines. La nouvelle version de l’agent après l’installation de Patch 3 sera 3.225.0.

Nous avons publié un correctif pour Azure DevOps Server 2022 Update 0.1 qui inclut des correctifs pour les éléments suivants.

• CVE-2023-33136 : Vulnérabilité d’exécution de code à distance d’Azure DevOps Server.
• CVE-2023-38155 : Vulnérabilité d’élévation de privilèges azure DevOps Server et Team Foundation Server.

Date de publication d’Azure DevOps Server 2022 Update 0.1 Patch 2 : 8 août 2023

Nous avons publié un correctif pour Azure DevOps Server 2022 Update 0.1 qui inclut des correctifs pour les éléments suivants.

• CVE-2023-36869 : Vulnérabilité d’usurpation d’identité azure DevOps Server.
• Correction d’un bogue dans les appels SOAP où ArithmeticException peut être déclenché pour la réponse XML de métadonnées volumineuses.
• Implémentation des modifications apportées à l’éditeur de connexions de service afin que l’état du point de terminaison vide sur le rejet du composant.
• Problème résolu avec les liens relatifs qui ne fonctionnent pas dans les fichiers Markdown.
• Correction d’un problème de performances lié au niveau application prenant plus de temps que la normale au démarrage lorsqu’un grand nombre de balises sont définies.
• Résolution des erreurs TF400367 sur la page Pools d’agents.
• Correction d’un bogue dans lequel l’identité du propriétaire d’analyse s’est montrée comme une identité inactive.
• Correction du bogue de boucle infinie sur CronScheduleJobExtension.

Date de publication d’Azure DevOps Server 2022 Update 0.1 Patch 1 : 13 juin 2023

Nous avons publié un correctif pour Azure DevOps Server 2022 Update 0.1 qui inclut des correctifs pour les éléments suivants.

• CVE-2023-21565 : Vulnérabilité d’usurpation d’identité azure DevOps Server.
• CVE-2023-21569 : Vulnérabilité d’usurpation d’identité azure DevOps Server.
• Correction d’un bogue avec l’éditeur de connexions de service. À présent, le brouillon de l’état du point de terminaison vide sur le composant est ignoré.
• Correction d’un bogue dans lequel la collection de détachements ou d’attachement ne signale pas l’erreur suivante : « TF246018 : l’opération de base de données a dépassé la limite de délai d’attente et a été annulée.

Date de publication d’Azure DevOps Server 2022 Update 0.1 : 9 mai 2023

Azure DevOps Server 2022.0.1 est un cumul de correctifs de bogues. Il inclut tous les correctifs dans Azure DevOps Server 2022.0.1 RC précédemment publié. Vous pouvez installer directement Azure DevOps Server 2022.0.1 ou effectuer une mise à niveau à partir d’Azure DevOps Server 2022 ou Team Foundation Server 2015 ou version ultérieure.

Date de publication d’Azure DevOps Server 2022 Update 0.1 RC : 11 avril 2023

Azure DevOps Server 2022.0.1 RC est un cumul de correctifs de bogues. Il inclut tous les correctifs dans les correctifs Azure DevOps Server 2022 précédemment publiés. Vous pouvez installer directement Azure DevOps Server 2022.0.1 ou effectuer une mise à niveau à partir d’Azure DevOps Server 2022 ou Team Foundation Server 2015 ou version ultérieure.

Cette version inclut les corrections des bugs suivants :

• Mise à niveau du système de fichiers virtuels Git (GVFS) vers v2.39.1.1-micorosoft.2 pour résoudre une vulnérabilité de sécurité.
• Les données de test n’étaient pas supprimées, ce qui entraînait la croissance de la base de données. Avec ce correctif, nous avons mis à jour la rétention des builds pour empêcher la création de nouvelles données de test orphelines.
• Les mises à jour apportées à AnalyticsCleanupJob, l’état du travail a été arrêté et nous signalons maintenant la réussite.
• Correction de la commande « tfx extension publish » ayant échoué avec l’erreur « La clé donnée n’était pas présente dans le dictionnaire ».
• Implémentation d’une solution de contournement pour résoudre et erreur lors de l’accès à l’extension Calendrier d’équipe.
• CVE-2023-21564 : Vulnérabilité de script intersites Azure DevOps Server
• CVE-2023-21553 : Vulnérabilité d’exécution de code à distance du serveur Azure DevOps
• Mise à jour des tâches MSBuild et VSBuild pour prendre en charge Visual Studio 2022.
• Mettez à jour la méthodologie de chargement de la réauthentification pour empêcher le vecteur d’attaque XSS.
• Le proxy Azure DevOps Server 2022 signale l’erreur suivante : VS800069 : ce service est disponible uniquement dans Azure DevOps local.
• Correction du problème d’accessibilité des ensembles de rayons via l’interface utilisateur web.
• Problème résolu lors du redémarrage du service tfsjobagent et du pool d’applications Azure DevOps Server après la mise à jour du paramètre SMTP dans la console de gestion du serveur Azure DevOps.
• Les notifications n’ont pas été envoyées pendant sept jours avant la date d’expiration.

Date de publication d’Azure DevOps Server 2022 Patch 4 : 13 juin 2023

Nous avons publié un correctif pour Azure DevOps Server 2022 qui inclut des correctifs pour les éléments suivants.

• CVE-2023-21565 : Vulnérabilité d’usurpation d’identité azure DevOps Server.
• CVE-2023-21569 : Vulnérabilité d’usurpation d’identité azure DevOps Server.
• Correction d’un bogue avec l’éditeur de connexions de service. À présent, le brouillon de l’état du point de terminaison vide sur le composant est ignoré.
• Correction d’un bogue dans lequel la collection de détachements ou d’attachement ne signale pas l’erreur suivante : « TF246018 : l’opération de base de données a dépassé la limite de délai d’attente et a été annulée.

Date de publication d’Azure DevOps Server 2022 Patch 3 : 21 mars 2023

Nous avons publié un correctif (19.205.33506.1) pour Azure DevOps Server 2022 qui inclut des correctifs pour les éléments suivants.

• Problème résolu lors du redémarrage du service tfsjobagent et du pool d’applications Azure DevOps Server après la mise à jour du paramètre SMTP dans la console de gestion du serveur Azure DevOps.
• Copiez l’état du point de terminaison dans le panneau de modification du point de terminaison de service au lieu de le transmettre par référence.
• Auparavant, lors de la modification des connexions de service, les modifications étaient conservées dans l’interface utilisateur après avoir sélectionné le bouton Annuler. Avec ce correctif, nous avons résolu dans le Kit de développement logiciel (SDK) de notification lorsqu’une équipe dispose d’une remise de notification définie sur Ne pas remettre. Dans ce scénario, si l’abonnement aux notifications est configuré avec l’option de remise des préférences d’équipe, les membres de l’équipe ne recevront pas les notifications. Il n’est pas nécessaire de développer les identités sous l’équipe pour vérifier les préférences des membres.

Date de publication d’Azure DevOps Server 2022 Patch 2 : 14 février 2023

Nous avons publié un correctif pour Azure DevOps Server 2022 qui inclut des correctifs pour les éléments suivants.

• CVE-2023-21564 : Vulnérabilité de script intersites Azure DevOps Server
• Mise à jour des tâches MSBuild et VSBuild pour prendre en charge Visual Studio 2022.
• Mise à jour de la méthodologie de chargement de la réauthentification pour empêcher le vecteur d’attaque XSS possible.
• Le proxy Azure DevOps Server 2022 signale l’erreur suivante : VS800069 : ce service est disponible uniquement dans Azure DevOps local.

Date de publication d’Azure DevOps Server 2022 Patch 1 : 24 janvier 2023

Nous avons publié un correctif pour Azure DevOps Server 2022 qui inclut des correctifs pour les éléments suivants.

• Les données de test n’étaient pas supprimées, ce qui entraînait la croissance de la base de données. Avec ce correctif, nous avons mis à jour la rétention des builds pour empêcher la création de nouvelles données de test orphelines.
• Les mises à jour apportées à AnalyticsCleanupJob, l’état du travail a été arrêté et nous signalons maintenant la réussite.
• Correction de la commande « tfx extension publish » ayant échoué avec l’erreur « La clé donnée n’était pas présente dans le dictionnaire ».
• Implémentation d’une solution de contournement pour résoudre et erreur lors de l’accès à l’extension Calendrier d’équipe.

Date de publication d’Azure DevOps Server 2022 : 6 décembre 2022

Azure DevOps Server 2022 est un cumul de correctifs de bogues. Il inclut toutes les fonctionnalités d’Azure DevOps Server 2022 RC2 et RC1 précédemment publiées.

Date de publication d’Azure DevOps Server 2022 RC2 : 25 octobre 2022

Azure DevOps Server 2022 RC2 est un cumul de correctifs de bogues. Il inclut toutes les fonctionnalités d’Azure DevOps Server 2022 RC1 précédemment publiées.

Remarque

Nouveaux algorithmes SSH RSA activés

La prise en charge de la clé publique RSA a été améliorée pour prendre en charge les types de clés publiques SHA2 en plus des types de clés publiques SHA1 SSH-RSA que nous avons précédemment pris en charge.

Les types de clés publiques désormais pris en charge sont les suivants :

• SSH-RSA
• RSA-SHA2-256
• RSA-SHA2-512

Action requise

Si vous avez implémenté le travail autour de l’activation de SSH-RSA en le spécifiant explicitement dans le .ssh/config1 fichier, vous devez supprimer le PubkeyAcceptedTypes, ou le modifier pour utiliser RSA-SHA2-256, ou RSA-SHA2-512, ou les deux. Vous trouverez des détails sur ce qu’il faut faire si vous êtes toujours invité à entrer votre mot de passe et GIT_SSH_COMMAND="ssh -v" git fetch n’affiche aucun algorithme de signature mutuelle dans la documentation ici.

La prise en charge des clés elliptiques n’a pas encore été ajoutée et reste une fonctionnalité hautement demandée sur notre backlog.

Date de publication d’Azure DevOps Server 2022 RC1 : 9 août 2022

Résumé des nouveautés d’Azure DevOps Server 2022

Important

Le service d’entrepôt et d’analyse a été déconseillé dans la version précédente d’Azure DevOps Server (2020). Dans Azure DevOps Server 2022, l’entrepôt et Analysis Service ont été supprimés du produit. Analytics offre désormais l’expérience de création de rapports dans le produit.

Azure DevOps Server 2022 introduit de nombreuses nouvelles fonctionnalités. Voici les principales :

• Plans de livraison
• Afficher une personne correcte sur les liens de validation
• Nouveaux contrôles pour les variables d’environnement dans les pipelines
• Générer des builds de fork de jeton sans restriction
• Nouvelles pages TFVC
• Regrouper par balises disponibles dans les widgets de graphique

Vous pouvez également accéder à des sections individuelles pour voir toutes les nouvelles fonctionnalités de chaque service :

• Boards
• Référentiels
• Pipelines
• Génération d’états

---

Boards

Plans de livraison

Nous sommes heureux d’annoncer que les plans de livraison sont désormais inclus dans Azure DevOps Server. Les plans de livraison fournissent 3 scénarios clés :

• Vue chronologique du plan
• Progression du travail
• Suivi des dépendances

Voici les principales fonctionnalités. Le filtrage, les marqueurs et les critères de champ font également partie des plans de livraison.

Il existe deux vues principales : condensée et développée

Les plans de remise 2.0 permettent d’afficher tous les éléments de travail de votre plan dans une chronologie, à l’aide des dates de début et de cible ou des dates d’itération. L’ordre de priorité est les dates de début et de cible, puis l’itération. Cela vous permet d’ajouter des éléments de travail au niveau du portefeuille commeEpic qui ne sont souvent pas définis à une itération.

Il existe deux vues principales de la vue condensée et de la vue développée. Vous pouvez également effectuer un zoom avant et arrière du plan en cliquant sur la loupe côté main du plan.

Il existe deux vues principales de la vue condensée et de la vue développée. Vous pouvez également effectuer un zoom avant et arrière du plan en cliquant sur la loupe située à droite du plan.

• Vue condensée

  La vue condensée affiche toutes les cartes d’élément de travail réduites , ce qui signifie que toutes les informations de carte ne sont pas affichées. Cette vue est utile pour une vue globale du travail dans le plan. Pour réduire les champs de carte, cliquez sur l’icône de carte en regard des icônes d’agrandissement dans le côté droit du plan.

  Voici un exemple de plan bascule entre les vues condensées et développées.

  

• Vue développée

  La vue développée affiche la progression d’un élément de travail en comptant le nombre d’éléments enfants et liés et en affichant le pourcentage terminé. Actuellement, la progression est déterminée par le nombre d’éléments de travail.

  Voici un exemple de plan utilisant une vue développée. Notez les barres de progression et le pourcentage terminés.

  

Suivi des dépendances

Le suivi des dépendances est basé sur les liens prédécesseurs et successeurs définis dans les éléments de travail. Si ces liens ne sont pas définis, aucune ligne de dépendance n’est affichée. Lorsqu’il existe un problème de dépendance avec un élément de travail, l’icône de lien de dépendance est en rouge.

• Affichage des dépendances

  Les dépendances spécifiques sont consultées via le panneau de dépendances qui affiche toutes les dépendances de cet élément de travail, y compris la direction. Un point d’exclamation rouge indique un problème de dépendance. Pour afficher le panneau, cliquez simplement sur l’icône de lien de dépendance dans le coin supérieur droit de la carte. Voici des exemples de dépendances.

  

  

• Lignes de dépendance

  Les dépendances entre les éléments de travail sont visualisées avec des lignes de direction entre les éléments de travail respectifs. Plusieurs dépendances s’affichent sous la forme de plusieurs lignes. Une ligne de couleur rouge indique un problème.

  Voici quelques exemples.

  

  Voici un exemple d’élément de travail avec plusieurs dépendances et fonctionne également à l’aide d’une vue condensée.

  

  Lorsqu’il y a un problème, la couleur de ligne est rouge, et c’est l’icône de dépendance.

  Voici un exemple.

  

Style de carte

Les cartes peuvent désormais être mises en forme à l’aide de règles, comme les tableaux Kanban. Ouvrez les paramètres du plan, puis cliquez sur Styles. Dans le volet Styles, cliquez sur + Ajouter une règle de style pour ajouter la règle, puis cliquez sur Enregistrer. Il peut y avoir jusqu’à 10 règles et chaque règle peut avoir jusqu’à 5 clauses.

• Avant

• Après

Pour en savoir plus sur les plans de livraison, consultez la documentation ici.

Éléments supprimés sur le hub Éléments de travail

Le hub Éléments de travail est l’endroit où afficher la liste des éléments que vous avez créés ou qui vous sont attribués. Il fournit plusieurs fonctions de tableau croisé dynamique et de filtre personnalisées pour simplifier la description des éléments de travail. L’une des principales plaintes du tableau croisé dynamique Affecté à moi est qu’elle affiche les éléments de travail supprimés. Nous sommes d’accord que les éléments de travail supprimés ne sont plus de valeur et ne doivent pas figurer dans le backlog. Dans ce sprint, nous masquons tous les éléments supprimés de l’affichage Affecté à moi sur le hub Éléments de travail.

Afficher une personne correcte sur les liens de validation

La section développement d’un élément de travail affiche la liste des validations pertinentes et des demandes de tirage. Vous pouvez afficher l’auteur de la validation ou de la demande de tirage avec l’heure associée. Avec cette mise à jour, nous avons résolu un problème avec l’avatar de l’auteur affiché de manière incorrecte dans la vue.

Supprimer la possibilité de télécharger une pièce jointe supprimée de l’historique des éléments de travail

Nous avons résolu un petit problème où les utilisateurs pouvaient télécharger des pièces jointes à partir de l’historique des éléments de travail, même après la suppression de la pièce jointe du formulaire. Maintenant, une fois la pièce jointe supprimée, elle ne peut pas être téléchargée à partir de l’historique, ni l’URL de téléchargement sera disponible à partir de la réponse de l’API REST.

Ajout de la valeur « Will not Fix » au champ Raison du bogue

Comme pour tous les autres types d’élément de travail, le type d’élément de travail bogue a un workflow bien défini. Chaque workflow se compose de trois États ou plus et d’une Raison. Les raisons spécifient la raison pour laquelle l’élément est passé d’un état à un autre. Avec cette mise à jour, nous avons ajouté une valeur de raison de non-correction pour les types d’éléments de travail bogues dans le processus Agile. La valeur est disponible pour une raison pour laquelle vous déplacez des bogues de Nouveau ou Actif vers Résolu. Vous pouvez en savoir plus sur la définition, la capture, le triage et la gestion des bogues logiciels dans la documentation Azure Boards.

Pipelines

Suppression des stratégies de rétention par pipeline dans les builds classiques

Vous pouvez maintenant configurer des stratégies de rétention pour les builds classiques et les pipelines YAML dans les paramètres du projet Azure DevOps. Les règles de rétention par pipeline pour les pipelines de build classiques ne sont plus prises en charge. Bien qu’il s’agit du seul moyen de configurer la rétention pour les pipelines YAML, vous pouvez également configurer la rétention pour les pipelines de build classiques par pipeline. Nous avons supprimé toutes les règles de rétention par pipeline pour les pipelines de build classiques dans une prochaine version.

Ce que cela signifie pour vous : tout pipeline de build classique utilisé pour avoir des règles de rétention par pipeline sera régi par les règles de rétention au niveau du projet.

Pour vous assurer que vous ne perdez aucune build lors de la mise à niveau, nous allons créer un bail pour toutes les builds existantes au moment de la mise à niveau qui n’ont pas de bail.

Nous vous recommandons de vérifier les paramètres de rétention au niveau du projet après la mise à niveau. Si votre pipeline nécessite spécifiquement des règles personnalisées, vous pouvez utiliser une tâche personnalisée dans votre pipeline. Pour plus d’informations sur l’ajout de baux de rétention via une tâche, consultez la documentation relative à la définition des stratégies de rétention pour les builds, versions et tests.

Nouveaux contrôles pour les variables d’environnement dans les pipelines

L’agent Azure Pipelines analyse la sortie standard des commandes de journalisation spéciales et les exécute. La setVariable commande peut être utilisée pour définir une variable ou modifier une variable précédemment définie. Cela peut être exploité par un acteur en dehors du système. Par exemple, si votre pipeline a une étape qui imprime la liste des fichiers dans un serveur ftp, une personne ayant accès au serveur ftp peut ajouter un nouveau fichier, dont le nom contient la setVariable commande et provoquer le changement de comportement du pipeline.

Nous avons de nombreux utilisateurs qui s’appuient sur la définition de variables à l’aide de la commande de journalisation dans leur pipeline. Avec cette version, nous apportons les modifications suivantes pour réduire le risque d’utilisations indésirables de la setVariable commande.

• Nous avons ajouté une nouvelle construction pour les auteurs de tâches. En incluant un extrait de code tel que le suivant, task.jsonun auteur de tâche peut contrôler si des variables sont définies par leur tâche.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 

• En outre, nous mettons à jour un certain nombre de tâches intégrées telles que ssh afin qu’elles ne puissent pas être exploitées.

• Enfin, vous pouvez maintenant utiliser des constructions YAML pour contrôler si une étape peut définir des variables.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Générer des builds de fork de jeton sans restriction

Les utilisateurs GitHub Enterprise utilisent couramment des duplications pour contribuer à un référentiel en amont. Quand Azure Pipelines génère des contributions à partir d’une duplication d’un dépôt GitHub Enterprise, elle limite les autorisations accordées au jeton d’accès au travail et n’autorise pas l’accès aux secrets de pipeline par ces travaux. Vous trouverez plus d’informations sur la sécurité des fourches de construction dans notre documentation.

Cela peut être plus restrictif que souhaité dans ces environnements fermés, où les utilisateurs peuvent toujours bénéficier d’un modèle de collaboration interne source. Bien que vous puissiez configurer un paramètre dans un pipeline pour rendre les secrets disponibles pour les duplications, il n’existe aucun paramètre pour contrôler l’étendue du jeton d’accès au travail. Avec cette version, nous vous proposons de contrôler la génération d’un jeton d’accès de travail standard, même pour les builds de fourche.

Vous pouvez modifier ce paramètre à partir de déclencheurs dans l’éditeur de pipeline. Avant de modifier ce paramètre, assurez-vous que vous comprenez parfaitement les implications de sécurité de l’activation de cette configuration.

Dépôts en tant que ressource protégée dans des pipelines YAML

Vous pouvez organiser votre projet Azure DevOps pour héberger de nombreux sous-projets, chacun avec son propre dépôt Git Azure DevOps et un ou plusieurs pipelines. Dans cette structure, vous pouvez contrôler quels pipelines peuvent accéder aux référentiels. Par exemple, supposons que vous avez deux référentiels A et B dans le même projet et deux pipelines X et Y qui créent normalement ces référentiels. Vous pouvez empêcher le pipeline Y d’accéder au référentiel A. En général, vous souhaitez que les contributeurs d’A contrôlent les pipelines auxquels ils souhaitent fournir l’accès.

Bien que cela soit partiellement possible avec les référentiels et les pipelines Azure Git, il n’y a pas eu d’expérience pour la gestion. Cette fonctionnalité répond à cet écart. Les dépôts Git Azure peuvent désormais être traités comme des ressources protégées dans des pipelines YAML, tout comme les connexions de service et les pools d’agents.

En tant que contributeur du référentiel A, vous pouvez ajouter des vérifications et des autorisations de pipeline à votre référentiel. Pour ce faire, accédez aux paramètres du projet, sélectionnez Référentiels, puis votre référentiel. Vous remarquerez un nouveau menu appelé « Vérifications », où vous pouvez configurer l’une des vérifications dans la zone ou personnalisées sous la forme de fonctions Azure.

Sous l’onglet « Sécurité », vous pouvez gérer la liste des pipelines qui peuvent accéder au référentiel.

Chaque fois qu’un pipeline YAML utilise un référentiel, l’infrastructure Azure Pipelines vérifie et garantit que toutes les vérifications et autorisations sont satisfaites.

Remarque

Ces autorisations et vérifications s’appliquent uniquement aux pipelines YAML. Les pipelines classiques ne reconnaissent pas ces nouvelles fonctionnalités.

Autorisations et vérifications sur les groupes de variables et les fichiers sécurisés

Vous pouvez utiliser différents types de ressources partagées dans des pipelines YAML. Par exemple, citons les connexions de service, les groupes de variables, les fichiers sécurisés, les pools d’agents, les environnements ou les référentiels. Pour protéger un pipeline contre l’accès à une ressource, le propriétaire de la ressource peut configurer des autorisations et des vérifications sur cette ressource. Chaque fois qu’un pipeline tente d’accéder à la ressource, toutes les autorisations et vérifications configurées sont évaluées. Ces protections ont été disponibles sur les connexions de service, les environnements et les pools d’agents pendant un certain temps. Ils ont été récemment ajoutés aux référentiels. Avec cette version, nous ajoutons les mêmes protections aux groupes de variables et aux fichiers sécurisés.

Pour restreindre l’accès à un groupe de variables ou à un fichier sécurisé à un petit ensemble de pipelines, utilisez la fonctionnalité d’autorisations Pipelines.

Pour configurer des vérifications ou des approbations qui doivent être évaluées chaque fois qu’un pipeline s’exécute, utilisez les approbations et vérifiez la fonctionnalité Bibliothèque .

Modifications apportées à la création automatique d’environnements

Lorsque vous créez un pipeline YAML et que vous faites référence à un environnement qui n’existe pas, Azure Pipelines crée automatiquement l’environnement. Cette création automatique peut se produire dans le contexte utilisateur ou dans le contexte système. Dans les flux suivants, Azure Pipelines connaît l’utilisateur effectuant l’opération :

• Vous utilisez l’Assistant Création de pipeline YAML dans l’expérience web Azure Pipelines, puis faites référence à un environnement qui n’a pas encore été créé.
• Vous mettez à jour le fichier YAML à l’aide de l’éditeur web Azure Pipelines, puis enregistrez le pipeline après avoir ajouté une référence à un environnement qui n’existe pas. Dans chacun des cas ci-dessus, Azure Pipelines a une compréhension claire de l’utilisateur effectuant l’opération. Par conséquent, il crée l’environnement et ajoute l’utilisateur au rôle d’administrateur de l’environnement. Cet utilisateur dispose de toutes les autorisations nécessaires pour gérer l’environnement et/ou inclure d’autres utilisateurs dans différents rôles pour gérer l’environnement.

Dans les flux suivants, Azure Pipelines n’a pas d’informations sur l’utilisateur qui crée l’environnement : vous mettez à jour le fichier YAML à l’aide d’un autre éditeur de code externe, ajoutez une référence à un environnement qui n’existe pas, puis déclenchez un pipeline d’intégration continue. Dans ce cas, Azure Pipelines ne connaît pas l’utilisateur. Auparavant, nous avons géré ce cas en ajoutant tous les contributeurs de projet au rôle Administrateur de l’environnement. Tout membre du projet peut ensuite modifier ces autorisations et empêcher d’autres personnes d’accéder à l’environnement.

Nous avons reçu vos commentaires sur l’octroi d’autorisations d’administrateur sur un environnement à tous les membres d’un projet. Comme nous avons écouté vos commentaires, nous avons entendu dire que nous ne devrions pas créer automatiquement un environnement s’il n’est pas clair quant à qui l’utilisateur effectue l’opération. Avec cette version, nous avons apporté des modifications à la façon dont les environnements seront créés automatiquement :

• À l’avenir, les exécutions de pipeline ne créent pas automatiquement un environnement s’il n’existe pas et si le contexte utilisateur n’est pas connu. Dans ce cas, le pipeline échoue avec une erreur d’environnement introuvable. Vous devez précréer les environnements avec la bonne sécurité et vérifier la configuration avant de l’utiliser dans un pipeline.
• Les pipelines avec le contexte utilisateur connu créent toujours automatiquement des environnements comme ils l’ont fait dans le passé.
• Enfin, il convient de noter que la fonctionnalité permettant de créer automatiquement un environnement a été ajoutée uniquement pour simplifier le processus de prise en main d’Azure Pipelines. Il était destiné aux scénarios de test, et non pour les scénarios de production. Vous devez toujours créer des environnements de production avec les autorisations et les vérifications appropriées, puis les utiliser dans les pipelines.

Supprimer le dialogue Insights du pipeline de build

En fonction de vos commentaires, la boîte de dialogue Task/Pipeline Insights qui s’affiche lors de la navigation dans le pipeline de build a été supprimée pour améliorer le flux de travail. L’analytique de pipeline est toujours disponible afin que vous disposiez des insights dont vous avez besoin.

Prise en charge des déploiements séquentiels plutôt que de la dernière version uniquement lors de l’utilisation de vérifications de verrouillage exclusives

Dans les pipelines YAML, les vérifications sont utilisées pour contrôler l’exécution des phases sur les ressources protégées. L’un des contrôles courants que vous pouvez utiliser est un contrôle de verrouillage exclusif. Cette vérification permet d’exécuter uniquement une seule exécution à partir du pipeline. Lorsque plusieurs exécutions tentent de déployer sur un environnement en même temps, la vérification annule toutes les anciennes exécutions et autorise le déploiement de la dernière exécution.

L’annulation d’anciennes exécutions est une bonne approche lorsque vos versions sont cumulatives et contiennent toutes les modifications de code des exécutions précédentes. Toutefois, il existe certains pipelines dans lesquels les modifications de code ne sont pas cumulatives. Avec cette nouvelle fonctionnalité, vous pouvez choisir d’autoriser toutes les exécutions à continuer et à déployer séquentiellement dans un environnement, ou de conserver le comportement précédent d’annulation des anciennes exécutions et d’autoriser uniquement la dernière version. Vous pouvez spécifier ce comportement à l’aide d’une nouvelle propriété appelée lockBehavior dans le fichier YAML du pipeline. Une valeur d’implique sequential que toutes les exécutions acquièrent le verrou de manière séquentielle sur la ressource protégée. Une valeur d’implique runLatest que seule la dernière exécution acquiert le verrou sur la ressource.

Pour utiliser la vérification Verrou exclusif avec des déploiements sequential ou runLatest, suivez ces étapes :

1. Activez la vérification Verrou exclusif sur l’environnement (ou une autre ressource protégée).
2. Dans le fichier YAML du pipeline, spécifiez une nouvelle propriété appelée lockBehavior. Celle-ci peut être spécifiée pour l’ensemble du pipeline ou pour un index donné :

Définie sur un index :

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Définie sur le pipeline :

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Si vous ne spécifiez pas un lockBehavior, il est supposé être runLatest.

Prise en charge de la version québécoise de ServiceNow

Azure Pipelines dispose d’une intégration existante à ServiceNow. L’intégration s’appuie sur une application dans ServiceNow et une extension dans Azure DevOps. Nous avons maintenant mis à jour l’application pour qu’elle fonctionne avec la version québécoise de ServiceNow. Les pipelines classiques et YAML fonctionnent désormais avec le Québec. Pour vous assurer que cette intégration fonctionne, effectuez une mise à niveau vers la nouvelle version de l’application (4.188.0) à partir du Magasin Service Now. Pour plus d’informations, consultez Intégrer à ServiceNow Change Management.

Nouvelles expressions conditionnelles YAML

L’écriture d’expressions conditionnelles dans des fichiers YAML s’est simplement facilitée avec l’utilisation des expressions et ${{ elseif }} des ${{ else }} expressions. Vous trouverez ci-dessous des exemples d’utilisation de ces expressions dans des fichiers de pipelines YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Prise en charge des caractères génériques dans les filtres de chemin

Les caractères génériques peuvent être utilisés lors de la spécification de branches d’inclusion et d’exclusion pour les déclencheurs CI ou PR dans un fichier YAML de pipeline. Toutefois, ils ne peuvent pas être utilisés lors de la spécification de filtres de chemin d’accès. Par exemple, vous ne pouvez pas inclure tous les chemins qui correspondent src/app/**/myapp*. Cela a été souligné comme un inconvénient par plusieurs clients. Cette mise à jour remplit cet écart. À présent, vous pouvez utiliser des caractères génériques (**ou *?) lors de la spécification de filtres de chemin d’accès.

La spécification de l’agent par défaut pour les pipelines sera Windows-2022

L’image windows-2022 est prête à être la version par défaut de l’étiquette windows-latest dans les agents hébergés par Microsoft Azure Pipelines. Jusqu’à présent, cette étiquette pointait vers les agents windows-2019. Cette modification sera déployée sur une période de plusieurs semaines à compter du 17 janvier. Nous prévoyons d’effectuer la migration d’ici mars.

Azure Pipelines a pris en charge windows-2022 depuis septembre 2021. Nous avons surveillé vos commentaires pour améliorer la stabilité de l’image windows-2022 et maintenant nous sommes prêts à le définir comme le plus récent.

L’image windows-2022 inclut Visual Studio 2022. Pour obtenir la liste complète des différences entre windows-2022 et windows-2019, visitez le problème GitHub. Pour obtenir la liste complète des logiciels installés sur l’image, consultez ici.

Le renommage du dossier de pipeline valide les autorisations

Les dossiers contenant des pipelines peuvent être renommés. Le changement de nom d’un dossier réussit maintenant uniquement si l’utilisateur dispose d’autorisations de modification sur au moins un pipeline contenu dans le dossier.

Planification de la mise à niveau du runtime de l’agent pipelines

Qu’est-ce que l’agent de pipeline ?

L’agent de pipeline Azure DevOps est le produit logiciel qui s’exécute sur un hôte de pipeline pour exécuter des travaux de pipeline. Il s’exécute sur des agents hébergés par Microsoft, des agents identiques et des agents auto-hébergés. Dans ce dernier cas, vous l’installez vous-même. L’agent de pipeline se compose d’un écouteur et d’un worker (implémentés dans .NET), le Worker exécute des tâches qui sont implémentées dans Node ou PowerShell et héberge donc ces runtimes pour eux.

Mise à niveau à venir vers .NET 6 & Red Hat 6 dépréciation

Avec la version de .NET 6 , nous pouvons tirer parti de ses nouvelles fonctionnalités multiplateformes. Plus précisément, nous serons en mesure de fournir une compatibilité native pour Apple Silicon et Windows Arm64. Nous prévoyons donc de passer à .NET 6 pour l’agent de pipeline (écouteur et worker) au cours des prochains mois.

En raison d’un certain nombre de contraintes imposées, nous supprimons la prise en charge de Red Hat Enterprise Linux 6 à partir de notre agent le 30 avril 2022.

Mises à jour de la tâche de copie de fichiers Azure

Nous déployons une nouvelle version de la tâche de copie de fichiers Azure. Cette tâche est utilisée pour copier des fichiers vers des objets blob de stockage Microsoft Azure ou des machines virtuelles. La nouvelle version a plusieurs mises à jour qui ont souvent été demandées par la communauté :

• La version de l’outil AzCopy a été mise à jour vers la version 10.12.2, qui prend en charge les types de contenu de fichier. Par conséquent, lorsque vous copiez pdf, Excel, PPT ou l’un des types mime pris en charge, le type de contenu du fichier est correctement défini.

• Avec la nouvelle version d’AzCopy, vous pouvez également configurer un paramètre pour nettoyer la cible lorsque le type de destination est Azure Blob. La définition de cette option supprime tous les dossiers/fichiers de ce conteneur. Ou si un préfixe d’objet blob est fourni, tous les dossiers/fichiers de ce préfixe seront supprimés.

• La nouvelle version de la tâche s’appuie sur des modules Az installés sur l’agent au lieu de modules AzureRM. Cela supprime un avertissement inutile dans certains cas lors de l’utilisation de la tâche.

Les modifications font partie d’une mise à jour de version majeure pour cette tâche. Vous devrez mettre à jour explicitement vos pipelines pour utiliser la nouvelle version. Nous avons choisi de mettre à jour la version principale pour nous assurer que nous n’arrêtons pas les pipelines qui dépendent toujours des modules AzureRM.

Nouveaux points d’extension pour la vue détails des pipelines

Nous avons ajouté deux nouveaux points d’extensibilité que vous pouvez cibler dans vos extensions. Ces points d’extensibilité vous permettent d’ajouter un bouton personnalisé dans l’en-tête de pipeline et un menu personnalisé dans un dossier de pipeline :

• Bouton personnalisé dans l’en-tête de pipeline : ms.vss-build-web.pipelines-header-menu
• Menu personnalisé dans un dossier de pipeline : ms.vss-build-web.pipelines-folder-menu

Pour utiliser ces nouveaux points d’extensibilité, ajoutez simplement une nouvelle contribution qui les cible dans le fichier manifeste de vss-extension.json votre extension Azure DevOps.

Par exemple :

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

Le résultat sera :

• Bouton personnalisé dans l’en-tête du pipeline

  

• Menu personnalisé dans un dossier de pipeline

  

Amélioration de la migration vers Azure DevOps Services

Lors de l’exécution d’une importation à partir d’Azure DevOps Server vers Azure DevOps Services, vous devez considérer qu’Azure DevOps ne prend plus en charge les règles de rétention par pipeline. Avec cette mise à jour, nous avons supprimé ces stratégies lorsque vous migrez vers Azure DevOps Services de votre serveur Azure DevOps local. Pour en savoir plus sur la configuration des stratégies de rétention, consultez notre documentation sur la définition des stratégies de rétention pour les builds, les versions et les tests.

Amélioration de l’API REST d’exécution de pipelines

Auparavant, l’API REST Pipelines exécute uniquement le self référentiel. Avec cette mise à jour, l’API REST Exécutions de pipelines retourne toutes les ressources de référentiel d’une build.

Les modèles de pipelines YAML étendus peuvent désormais être transmis des informations contextuelles pour les phases, les travaux et les déploiements

Avec cette mise à jour, nous ajoutons une nouvelle templateContext propriété pour jobles deploymentcomposants de stage pipeline YAML destinés à être utilisés conjointement avec des modèles.

Voici un scénario d’utilisation templateContext:

• Vous utilisez des modèles pour réduire la duplication de code ou améliorer la sécurité de vos pipelines

• Votre modèle prend comme paramètre une liste , stagesjobsoudeployments

• Le modèle traite la liste d’entrée et effectue certaines transformations sur chacune des phases, travaux ou déploiements. Par exemple, il définit l’environnement dans lequel chaque travail s’exécute ou ajoute des étapes supplémentaires pour appliquer la conformité

• Le traitement nécessite que des informations supplémentaires soient transmises par l’auteur du pipeline dans le modèle pour chaque étape, travail ou déploiement dans la liste

Examinons un exemple. Supposons que vous créez un pipeline qui exécute des tests de bout en bout pour la validation des demandes d’extraction. Votre objectif est de tester un seul composant de votre système, mais, étant donné que vous envisagez d’exécuter des tests de bout en bout, vous avez besoin d’un environnement où plus de composants du système sont disponibles et que vous devez spécifier leur comportement.

Vous réalisez que d’autres équipes auront des besoins similaires. Vous décidez donc d’extraire les étapes de configuration de l’environnement dans un modèle. Son code ressemble à ce qui suit :

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Ce que fait le modèle, pour chaque travail du testSet paramètre, il définit la réponse des composants du système spécifiés par ${{ testJob.templateContext.requiredComponents }} pour renvoyer ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Vous pouvez ensuite créer votre propre pipeline qui s’étend testing-template.yml comme dans l’exemple suivant.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Ce pipeline exécute deux tests, un positif et un négatif. Les deux tests nécessitent que le dimensionsapi composant soit disponible. Le positive_test travail attend le dimensionsapi code HTTP de retour 200, tandis qu’il negative_test s’attend à ce qu’il retourne le code HTTP 500.

Prise en charge des comptes de service gérés de groupe en tant que compte de service d’agent

L’agent Azure Pipelines prend désormais en charge les comptes de service géré de groupe sur les agents auto-hébergés sur Windows.

Les comptes de service géré de groupe fournissent une gestion centralisée des mots de passe pour les comptes de domaine qui agissent en tant que comptes de service. L’agent Azure Pipelines peut reconnaître ce type de compte afin qu’un mot de passe ne soit pas requis lors de la configuration :

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Exécutions d’informations

Une exécution d’information vous indique qu’Azure DevOps n’a pas pu récupérer le code source d’un pipeline YAML. Une telle exécution ressemble à ce qui suit.

Azure DevOps récupère le code source d’un pipeline YAML en réponse à des événements externes, par exemple, une validation envoyée (push) ou en réponse à des déclencheurs internes, par exemple pour vérifier s’il existe des modifications de code et démarrer une exécution planifiée ou non. Lorsque cette étape échoue, le système crée une exécution d’information. Ces exécutions sont créées uniquement si le code du pipeline se trouve dans un référentiel GitHub ou BitBucket.

La récupération du code YAML d’un pipeline peut échouer en raison des raisons suivantes :

• Le fournisseur de référentiel rencontre une panne
• Limitation des tentatives d’accès
• Problèmes d’authentification
• Impossible de récupérer le contenu du fichier .yml du pipeline

En savoir plus sur les exécutions d’informations.

La propriété DE l’API retentionRules REST de définition de build est obsolète

Dans le type de réponse de l’API REST de définition de BuildDefinition build, la retentionRules propriété est désormais marquée comme obsolète, car cette propriété retourne toujours un jeu vide.

Référentiels

Nouvelles pages TFVC

Nous avons mis à jour différentes pages dans Azure DevOps pour utiliser une nouvelle plateforme web dans le but de rendre l’expérience plus cohérente et plus accessible sur les différents services. Les pages TFVC ont été mises à jour pour utiliser la nouvelle plateforme web. Avec cette version, nous rendons les nouvelles pages TFVC en disponibilité générale.

Désactiver un référentiel

Les clients ont souvent demandé un moyen de désactiver un référentiel et d’empêcher les utilisateurs d’accéder à son contenu. Par exemple, vous pouvez effectuer cette opération lorsque :

• Vous avez trouvé un secret dans le référentiel.
• Un outil d’analyse tiers a trouvé un référentiel hors conformité.

Dans ce cas, vous pouvez désactiver temporairement le référentiel pendant que vous travaillez pour résoudre le problème. Avec cette mise à jour, vous pouvez désactiver un référentiel si vous disposez d’autorisations de suppression de référentiel . En désactivant un dépôt, vous :

• Peut répertorier le dépôt dans la liste des dépôts
• Impossible de lire le contenu du dépôt
• Impossible de mettre à jour le contenu du dépôt
• Afficher un message indiquant que le dépôt a été désactivé lorsqu’il tente d’accéder au dépôt dans l’interface utilisateur Azure Repos

Une fois les étapes d’atténuation nécessaires effectuées, les utilisateurs disposant de l’autorisation Supprimer le référentiel peuvent réactiver le référentiel. Pour désactiver ou activer un référentiel, accédez à Paramètres du projet, sélectionnez Référentiels, puis le référentiel spécifique.

Configurer les créateurs de branche pour qu’ils n’obtiennent pas d’autorisations de gestion sur leurs branches

Lorsque vous créez une branche, vous obtenez « Gérer les autorisations » sur cette branche. Cette autorisation vous permet de modifier les autorisations d’autres utilisateurs ou d’admettre des utilisateurs supplémentaires pour contribuer à cette branche. Par exemple, un créateur de branche peut utiliser cette autorisation pour permettre à un autre utilisateur externe d’apporter des modifications au code. Ils peuvent également autoriser un pipeline (identité de service de build) à modifier le code de cette branche. Dans certains projets avec des exigences de conformité plus élevées, les utilisateurs ne doivent pas être en mesure d’apporter ces modifications.

Avec cette mise à jour, vous pouvez configurer n’importe quel référentiel de votre projet d’équipe et restreindre les créateurs de branche d’obtenir l’autorisation « Gérer les autorisations ». Pour ce faire, accédez aux paramètres du projet, sélectionnez Référentiels, puis Paramètres de tous les référentiels ou référentiels spécifiques.

Ce paramètre est activé par défaut pour imiter le comportement existant. Toutefois, vous pouvez la désactiver si vous souhaitez utiliser cette nouvelle fonctionnalité de sécurité.

Empêcher les utilisateurs de duplication (fork) de voter sur leurs demandes de tirage en amont

Avec Azure Repos, les utilisateurs disposant d’une autorisation de « lecture » sur un référentiel peuvent fourcher le dépôt et apporter des modifications dans leur fourche. Pour soumettre une demande de tirage avec leurs modifications à l’amont, les utilisateurs ont besoin de l’autorisation « contribuer aux demandes de tirage » en amont. Toutefois, cette autorisation régit également qui peut voter sur les demandes de tirage (pull request) dans le référentiel en amont. Par conséquent, vous pouvez vous retrouver dans des situations où un utilisateur, qui n’est pas contributeur au référentiel, peut envoyer une demande de tirage (pull request) et la fusionner en fonction de la façon dont vous configurez les stratégies de branche.

Dans les projets qui favorisent un modèle source interne, le fork-and-contribution est un modèle commun. Pour sécuriser et promouvoir davantage ce modèle, nous modifions l’autorisation de voter sur une demande de tirage de « contribuer aux demandes de tirage » pour « contribuer ». Toutefois, cette modification n’est pas effectuée par défaut dans tous les projets. Vous devez vous inscrire et sélectionner une nouvelle stratégie sur votre dépôt, appelée « Mode vote strict » pour changer cette autorisation. Nous vous recommandons de le faire si vous vous appuyez sur des duplications dans Azure Repos.

Reporting

Regrouper par balises disponibles dans les widgets de graphique

Le widget de graphique Group by Tags est désormais disponible par défaut pour tous les clients. Lorsque vous utilisez le widget de graphique, il existe désormais une option disponible pour les balises. Les utilisateurs peuvent visualiser leurs informations en sélectionnant toutes les étiquettes ou un ensemble de balises dans le widget.

Afficher les types d’éléments de travail personnalisés dans le widget burndown

Auparavant, vous n’avez pas pu voir les types d’éléments de travail personnalisés configurés dans le widget de combustion et additionné ou compté par un champ personnalisé. Avec cette mise à jour, nous avons résolu ce problème et vous pouvez maintenant voir les types d’éléments de travail personnalisés dans le widget burndown.

---

Retours d'expérience

Nous sommes à votre écoute ! Vous pouvez signaler un problème ou fournir une idée et le suivre via la Communauté des développeurs et obtenir des conseils sur Stack Overflow.

---

Haut de page