Notes de publication Azure DevOps Server 2022

---

| | Developer Community System Requirements and Compatibility | License Terms | DevOps Blog | SHA-256 Hashes |

---

Dans cet article, vous trouverez des informations sur la dernière version pour Azure DevOps Server.

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

Pour télécharger Azure DevOps Server produits, visitez la page Téléchargements Azure DevOps Server.

La mise à niveau directe vers Azure DevOps Server 2022 est prise en charge à partir de Azure DevOps Server 2019 ou de Team Foundation Server 2015 ou version ultérieure. Si votre déploiement TFS est sur TFS 2013 ou une 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 .

---

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

Notes

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

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

Nous avons publié un correctif pour Azure DevOps Server mise à jour 0.1 2022 qui inclut les correctifs suivants.

• Extension de la liste de caractères autorisée des tâches PowerShell pour la validation des paramètres Activer les arguments des tâches de l’interpréteur de commandes.
• Correction d’un problème qui entraînait la persistance des modifications des connexions de service après avoir cliqué sur le bouton Annuler.

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

Notes

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

Nous avons publié un correctif pour Azure DevOps Server mise à jour 0.1 2022 qui inclut les correctifs suivants.

• Correction d’un bogue qui entraînait le blocage des pipelines en mettant à niveau le modèle d’exécution de pipeline.
• Correction d’un bogue où l’identité « Propriétaire de l’analyse » s’affichait en tant qu’identité inactive sur les machines de mise à niveau corrective.
• Le travail de nettoyage de build contient de nombreuses tâches, chacune d’elles supprimant un artefact pour une build. Si l’une de ces tâches a échoué, aucune des tâches suivantes ne s’est exécutée. Nous avons modifié ce comportement pour ignorer les échecs de tâche et propre autant d’artefacts que possible.

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

Notes

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

Nous avons publié un correctif pour Azure DevOps Server mise à jour 0.1 2022 qui inclut les correctifs suivants.

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

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

Nous avons publié un correctif pour Azure DevOps Server mise à jour 0.1 2022 qui inclut les correctifs suivants.

• CVE-2023-36869 : Azure DevOps Server vulnérabilité d’usurpation d’identité.
• 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émenté des modifications apportées à l’éditeur de connexions de service afin que l’état du point de terminaison soit vidé lors de l’abandon du composant.
• Résolution du problème lié aux liens relatifs qui ne fonctionnent pas dans les fichiers markdown.
• Correction d’un problème de performances lié au fait que le démarrage de la couche Application prend plus de temps que d’habitude quand un grand nombre de balises sont définies.
• Résolution des erreurs TF400367 dans la page Pools d’agents.
• Correction d’un bogue où l’identité du propriétaire de l’analyse s’affichait comme identité inactive.
• Correction d’un bogue de boucle infinie sur CronScheduleJobExtension.

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

Nous avons publié un correctif pour Azure DevOps Server mise à jour 0.1 2022 qui inclut les correctifs suivants.

• CVE-2023-21565 : Azure DevOps Server vulnérabilité d’usurpation d’identité.
• CVE-2023-21569 : Azure DevOps Server vulnérabilité d’usurpation d’identité.
• Correction d’un bogue avec l’éditeur de connexions de service. À présent, l’état du point de terminaison brouillon est vidé lors de l’abandon du composant.
• Correction d’un bogue dans lequel le détachement ou l’attachement de la collecte ne parvient pas à signaler 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.

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

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

Azure DevOps Server 2022 Update 0.1 RC Date de publication : 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 de Azure DevOps Server 2022 ou de Team Foundation Server 2015 ou version ultérieure.

Cette version inclut les corrections des bugs suivants :

• Mise à niveau de Git Virtual File System (GVFS) vers v2.39.1.1-micorosoft.2 pour résoudre une vulnérabilité de sécurité.
• Les données de test n’ont pas été supprimées, ce qui a entraîné la croissance de la base de données. Avec ce correctif, nous avons mis à jour la rétention de build pour empêcher la création de nouvelles données de test orphelines.
• Mises à jour à la tâche AnalyticCleanup, le travail status a été arrêté et maintenant nous signalons Réussi.
• Correction de l’échec de la commande « publication de l’extension tfx » 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 les erreurs lors de l’accès à l’extension Calendrier d’équipe.
• CVE-2023-21564 : Azure DevOps Server vulnérabilité de script intersite
• CVE-2023-21553 : vulnérabilité d’exécution de code à distance Azure DevOps Server
• Mises à jour des tâches MSBuild et VSBuild pour prendre en charge Visual Studio 2022.
• Mettre à jour la méthodologie de chargement de la réauthentification pour empêcher le vecteur d’attaque XSS.
• Azure DevOps Server proxy 2022 signale l’erreur suivante : VS800069 : ce service n’est disponible que dans Azure DevOps local.
• Correction du problème d’accessibilité des étagères via l’interface utilisateur web.
• Résolution du problème qui nécessitait le redémarrage du service tfsjobagent et Azure DevOps Server pool d’applications après la mise à jour du paramètre SMTP dans la console de gestion Azure DevOps Server.
• Les notifications n’étaient pas envoyées pour PAT sept jours avant la date d’expiration.

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

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

• CVE-2023-21565 : Azure DevOps Server vulnérabilité d’usurpation d’identité.
• CVE-2023-21569 : Azure DevOps Server vulnérabilité d’usurpation d’identité.
• Correction d’un bogue avec l’éditeur de connexions de service. À présent, l’état du point de terminaison brouillon est vidé lors de l’abandon du composant.
• Correction d’un bogue dans lequel le détachement ou l’attachement de la collecte ne parvient pas à signaler 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.

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

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

• Résolution du problème qui nécessitait le redémarrage du service tfsjobagent et Azure DevOps Server pool d’applications après la mise à jour du paramètre SMTP dans la console de gestion Azure DevOps Server.
• 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) notification pour les cas où la remise de notification d’une équipe est 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 d’étendre les identités sous l’équipe pour case activée les préférences des membres.

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

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

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

Azure DevOps Server 2022 Patch 1 Date de publication : 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’ont pas été supprimées, ce qui a entraîné 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.
• Mises à jour à l’objet AnalyticCleanupJob, le status de travail a été Arrêté et nous signalons maintenant Réussite.
• Correction de l’échec de la commande « publication de l’extension tfx » 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 les problèmes et les erreurs lors de l’accès à l’extension Calendrier de l’équipe.

date de publication 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 des Azure DevOps Server 2022 RC2 et RC1 précédemment publiées.

date de publication de 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 de la Azure DevOps Server 2022 RC1 publiée précédemment.

Notes

Nouveaux algorithmes SSH RSA activés

La prise en charge des clés publiques RSA a été améliorée pour prendre en charge les types de clés publiques SHA2 en plus du 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 de contournement pour activer SSH-RSA en le spécifiant explicitement dans le .ssh/config1 fichier, vous devez supprimer ou modifier pour PubkeyAcceptedTypesutiliser RSA-SHA2-256 ou RSA-SHA2-512, ou les deux. Vous trouverez des détails sur la procédure à suivre 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 de la clé elliptique n’a pas encore été ajoutée et reste une fonctionnalité très demandée dans notre backlog.

date de publication de Azure DevOps Server 2022 RC1 : 9 août 2022

Résumé des nouveautés de Azure DevOps Server 2022

Important

Le service d’entrepôt et d’analyse a été déprécié dans la version précédente de Azure DevOps Server (2020). Dans Azure DevOps Server 2022, le service d’entrepôt et d’analyse a été supprimé du produit. Analytics fournit 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 le personnage correct sur les liens de validation
• Nouveaux contrôles pour les variables d’environnement dans les pipelines
• Générer des jetons non restreints pour les builds de duplication
• Nouvelles pages TFVC
• Regrouper par étiquettes disponibles dans les widgets de graphique

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

• Boards
• Repos
• Pipelines
• Création de rapports

---

Boards

Plans de livraison

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

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

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

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

Plans de livraison 2.0 permet d’afficher tous les éléments de travail de votre plan sur un chronologie, à l’aide des dates de début et de cible ou des dates d’itération. L’ordre de priorité est de commencer & dates cibles, puis d’itération. Cela vous permet d’ajouter des éléments de travail au niveau du portefeuille commeEpic qui ne sont souvent pas définis pour une itération.

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

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

• Vue condensée

  La vue condensée montre toutes les cartes d’éléments de travail réduites, ce qui signifie que toutes les informations carte ne sont pas affichées. Cette vue est utile pour une vue d’ensemble du travail dans le plan. Pour réduire les champs carte, cliquez sur l’icône de carte en regard des icônes d’agrandissement situées à droite 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 montre la progression d’un élément de travail en comptant le nombre d’éléments enfants et liés et en affichant le pourcentage d’exécution. 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 la définition de liens de prédécesseur et de successeur dans les éléments de travail. Si ces liens ne sont pas définis, aucune ligne de dépendance ne s’affiche. En cas de problème de dépendance avec un élément de travail, l’icône de lien de dépendance est de couleur rouge.

• Affichage des dépendances

  Les dépendances spécifiques sont consultées via le panneau des 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 du carte. Voici des exemples de dépendances.

  

  

• Lignes de dépendance

  Les dépendances entre les éléments de travail sont visualisées à l’aide de flèches directionnelles 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 qui fonctionne également à l’aide d’une vue condensée.

  

  En cas de problème, la couleur de ligne est rouge, de même que 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, case activée 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 une liste d’é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 liste des éléments de travail. L’une des principales plaintes du pivot Qui m’a été attribué est qu’il affiche les éléments de travail supprimés. Nous convenons que les éléments de travail supprimés n’ont plus de valeur et ne doivent pas figurer dans le backlog. Dans ce sprint, nous masquons tous les éléments supprimés des vues m’ayant été attribuées sur le hub éléments de travail.

Afficher le personnage correct sur les liens de validation

La section développement d’un élément de travail affiche la liste des commits et des demandes de tirage pertinentes. 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 d’affichage incorrect de l’avatar de l’auteur 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. À présent, une fois la pièce jointe supprimée, elle ne peut pas être téléchargée à partir de l’historique, et l’URL de téléchargement ne sera pas disponible à partir de la réponse de l’API REST.

Ajout de la valeur « Ne corrigera pas » 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 Will not fix pour les types d’éléments de travail Bogue dans le processus Agile. La valeur sera disponible en tant que raison lors du déplacement 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 Azure Boards documentation.

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 de 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 de la seule façon de configurer la rétention pour les pipelines YAML, vous pouvez également configurer la rétention pour les pipelines de build classiques sur une base 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 qui avait 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 de ne pas perdre de builds 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 case activée 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 par le biais d’une tâche, consultez la documentation définir des stratégies de rétention pour les builds, les versions et les tests.

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

L’agent Azure Pipelines analyse la sortie standard à la recherche de commandes de journalisation spéciales et les exécute. La setVariablecommande 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 entraîne 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 ce qui suit dans task.json, un auteur de tâche peut contrôler si des variables sont définies par sa 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 jetons sans restriction pour les builds fork

Les utilisateurs de GitHub Enterprise utilisent généralement des duplications pour contribuer à un dépôt amont. Quand Azure Pipelines génère contributions à partir d’une duplication d’un dépôt GitHub Enterprise, il 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 duplications de génération dans notre documentation.

Cela peut être plus restrictif que souhaité dans de tels environnements fermés, où les utilisateurs peuvent toujours tirer parti d’un modèle de collaboration à source interne. 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 donnons le contrôle pour générer un jeton d’accès aux travaux régulier, même pour les builds de duplications.

Vous pouvez modifier ce paramètre à partir de Déclencheurs dans l’éditeur de pipeline. Avant de modifier ce paramètre, assurez-vous de bien comprendre les implications en matière de sécurité de l’activation de cette configuration.

Repos en tant que ressource protégée dans les 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 dépôts. Par exemple, supposons que vous avez deux dépôts A et B dans le même projet et deux pipelines X et Y qui créent normalement ces dépôts. Vous souhaiterez peut-être empêcher le pipeline Y d’accéder au référentiel A. En général, vous souhaitez que les contributeurs de A contrôlent les pipelines auxquels ils souhaitent fournir l’accès.

Bien que cela soit partiellement possible avec les référentiels et pipelines Azure Git, il n’y avait aucune expérience de gestion. Cette fonctionnalité répond à cette lacune. Les dépôts Git Azure peuvent désormais être traités comme des ressources protégées dans les 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 dépôt. Pour ce faire, accédez aux paramètres du projet, sélectionnez Dépôts, puis votre dépôt. Vous remarquerez un nouveau menu appelé « Vérifications », où vous pouvez configurer l’une des vérifications in-the-box 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 dépôt.

Chaque fois qu’un pipeline YAML utilise un dépôt, l’infrastructure Azure Pipelines vérifie et vérifie que toutes les vérifications et autorisations sont satisfaites.

Notes

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. Les exemples incluent 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 de 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 sont disponibles sur les connexions de service, les environnements et les pools d’agents depuis un certain temps. Ils ont récemment été ajoutés aux dépôts. 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é Autorisations de pipelines .

Pour configurer des vérifications ou des approbations qui doivent être évaluées chaque fois qu’un pipeline s’exécute, utilisez la fonctionnalité Approbations et vérifications pour la 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 qui effectue 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 qui effectue 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 pour inclure d’autres utilisateurs dans différents rôles pour la gestion de l’environnement.

Dans les flux suivants, Azure Pipelines ne dispose 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. Lorsque nous avons écouté vos commentaires, nous avons entendu que nous ne devrions pas créer automatiquement un environnement s’il n’est pas clair que l’utilisateur effectuant l’opération est. Avec cette version, nous avons apporté des modifications à la façon dont les environnements seront automatiquement créés :

• À 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 Environnement introuvable. Vous devez précréer les environnements avec la sécurité appropriée et vérifier la configuration avant de l’utiliser dans un pipeline.
• Les pipelines avec un 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 aux scénarios de production. Vous devez toujours précréer des environnements de production avec les autorisations et les vérifications appropriées, puis les utiliser dans les pipelines.

Boîte de dialogue Supprimer des insights du pipeline de build

En fonction de vos commentaires, la boîte de dialogue Insights sur la tâche/pipeline 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 verrous exclusifs

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 verrou exclusif case activée. Cette case activée permet à une seule exécution à partir du pipeline de continuer. Lorsque plusieurs exécutions tentent de déployer dans un environnement en même temps, le case activée annule toutes les anciennes exécutions et autorise le déploiement de la dernière exécution.

L’annulation des anciennes exécutions est une bonne approche lorsque vos mises en production 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 à se poursuivre et de les déployer de manière séquentielle dans un environnement, ou de conserver le comportement précédent qui consiste à annuler les anciennes exécutions et à autoriser uniquement les dernières exécutions. Vous pouvez spécifier ce comportement à l’aide d’une nouvelle propriété appelée lockBehavior dans le fichier YAML du pipeline. La valeur de sequential implique que toutes les exécutions acquièrent le verrou séquentiellement sur la ressource protégée. La valeur de runLatest implique que seule la dernière exécution acquiert le verrou de 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 de lockBehavior, il est supposé être runLatest.

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

Azure Pipelines a 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 maintenant 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 simplifiée avec l’utilisation d’expressions ${{ else }} et ${{ elseif }} . 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 instance, vous ne pouvez pas inclure tous les chemins qui correspondent à src/app/**/myapp*. Cela a été signalé comme un inconvénient par plusieurs clients. Cette mise à jour comble cette lacune. À présent, vous pouvez utiliser des caractères carte 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 est 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. Ce changement sera déployé sur une période de plusieurs semaines à compter du 17 janvier. Nous prévoyons de terminer la migration d’ici mars.

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

L’image windows-2022 inclut Visual Studio 2022. Pour obtenir la liste complète des différences entre windows-2022 et windows-2019, consultez le problème GitHub. Pour obtenir la liste complète des logiciels installés sur l’image, case activée 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 désormais 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 de 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 les agents hébergés par Microsoft, les agents de groupe identique et les 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 prochaine vers .NET 6 & dépréciation de Red Hat 6

Avec la version de .NET 6 , nous sommes en mesure de 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. Par conséquent, nous prévoyons de passer à .NET 6 pour l’agent de pipeline (écouteur et worker) dans les mois à venir.

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

Mises à jour à 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 comporte plusieurs mises à jour qui ont été souvent 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 fichiers. Par conséquent, lorsque vous copiez des fichiers 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 propre 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 sont supprimés.

• La nouvelle version de la tâche s’appuie sur les modules Az installés sur l’agent au lieu des 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 devez mettre à jour explicitement vos pipelines pour utiliser la nouvelle version. Nous avons choisi de mettre à jour la version principale pour nous assurer de ne pas interrompre les pipelines qui dépendent toujours des modules AzureRM.

Nouveaux points d’extension pour l’affichage des 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é sur 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 de pipeline

  

• Menu personnalisé sur un dossier de pipeline

  

Amélioration de la migration vers Azure DevOps Services

Lors de l’exécution d’une importation de Azure DevOps Server vers Azure DevOps Services, vous devez tenir compte du fait 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 Azure DevOps Server local. Pour en savoir plus sur la configuration des stratégies de rétention, consultez notre documentation sur la définition de stratégies de rétention pour les builds, les mises en production et les tests.

Amélioration de l’API REST des exécutions de pipelines

Auparavant, l’API REST Pipelines Exécute ne renvoyait que le self dépôt. Avec cette mise à jour, l’API REST Pipelines Runs retourne toutes les ressources de dépôt d’une build.

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

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

Voici un scénario d’utilisation templateContextde :

• 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 de stages, jobsou deployments

• Le modèle traite la liste d’entrée et effectue certaines transformations sur chacune des étapes, 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, tâche ou déploiement dans la liste

Prenons un exemple. Supposons que vous créez un pipeline qui exécute des tests de bout en bout pour la validation des demandes de tirage. Votre objectif est de tester un seul composant de votre système, mais, comme vous prévoyez d’exécuter des tests de bout en bout, vous avez besoin d’un environnement où davantage de composants du système sont disponibles et 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 se présente comme 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 dans le testSet paramètre, définit la réponse des composants du système spécifiés par ${{ testJob.templateContext.requiredComponents }} pour renvoyer ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Ensuite, vous pouvez 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 à retourner le code HTTP 500.

Comptes de service managés de groupe de support en tant que compte de service d’agent

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

Les comptes de service gérés de groupe fournissent une gestion centralisée des mots de passe pour les comptes de domaine qui jouent le rôle de comptes de service. L’agent Azure Pipelines peut reconnaître ce type de compte, de sorte qu’aucun mot de passe n’est requis pendant 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’information

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, un commit poussé ou en réponse à des déclencheurs internes, par exemple, pour case activée s’il y a 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.

Repos

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 dans les différents services. Les pages TFVC ont été mises à jour pour utiliser la nouvelle plateforme web. Avec cette version, nous mettons les nouvelles pages TFVC en disponibilité générale.

Désactiver un dépôt

Les clients ont souvent demandé un moyen de désactiver un dépôt et d’empêcher les utilisateurs d’accéder à son contenu. Par exemple, vous pouvez effectuer cette opération dans les cas suivants :

• Vous avez trouvé un secret dans le dépôt.
• Un outil d’analyse tiers a constaté qu’un dépôt n’était pas conforme.

Dans ce cas, vous pouvez désactiver temporairement le dépôt pendant que vous travaillez pour résoudre le problème. Avec cette mise à jour, vous pouvez désactiver un dépôt si vous disposez des autorisations Supprimer le dépôt . 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 prises, les utilisateurs disposant de l’autorisation Supprimer le dépôt peuvent réactiver le dépôt. Pour désactiver ou activer un dépôt, accédez à Paramètres du projet, sélectionnez Référentiels, puis le dépôt spécifique.

Configurer les créateurs de branche pour ne pas obtenir « Gérer les autorisations » 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’autoriser d’autres utilisateurs à contribuer à cette branche. Par instance, 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 (build service identity) à modifier le code dans 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 tous les dépôts de votre projet d’équipe et empêcher les créateurs de branches 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 pour tous les dépôts ou un dépôt spécifique.

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 la duplication de voter sur leurs demandes de tirage amont

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

Dans les projets qui font la promotion d’un modèle source interne, la duplication et la contribution sont un modèle courant. 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 » en « 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 de vote strict » pour changer cette autorisation. Nous vous recommandons de le faire si vous utilisez des duplications dans Azure Repos.

Rapports

Regrouper par étiquettes disponibles dans les widgets de graphique

Le widget de graphique Regrouper par étiquettes est désormais disponible par défaut pour tous les clients. Lorsque vous utilisez le widget de graphique, une option est désormais 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’étiez pas en mesure de voir les types d’éléments de travail personnalisés configurés dans le widget burn down et additionnés ou comptés 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.

---

Commentaires

Nous aimerions connaître votre opinion ! Vous pouvez signaler un problème ou fournir une idée et le suivre à travers Developer Community et obtenir des conseils sur Stack Overflow.

---

Haut de la page