Notes de publication d’Azure DevOps Server

| Communauté | des développeursConfiguration requise et compatibilité | du systèmeTermes | Blog | DevOpsHachages SHA-256 |

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 Azure Azure DevOps Server Requirements.

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 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 : 9 décembre 2025

Azure DevOps Server RTW est un cumul de correctifs de bogues et de modifications pour prendre en charge SQL Server 2025. Elle inclut toutes les fonctionnalités dans Azure DevOps Server RC précédemment publiée.

Vous pouvez installer directement Azure DevOps Server ou effectuer une mise à niveau à partir d’Azure DevOps Server 2022, 2020, 2019 ou Team Foundation Server 2015 ou version ultérieure.

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

• Modifications de localisation fusionnées.
• Modifications apportées à la prise en charge de SQL Server 2025.
• Correction d’un problème où les noms de référentiel ou de branche longs ont dépassé le contrôle de liste déroulante dans la configuration du widget Vignette de code sur la page Tableaux de bord.
• Correction du problème où l’état gitHub PR était correctement enregistré en tant que fermé pour les demandes de tirage fusionnées et non fusionnées lors de l’utilisation de webhooks. Le système s’appuie désormais sur l’indicateur booléen fusionné dans la charge utile du webhook pour enregistrer avec précision l’état correct dans la base de données.
• Correction d’un problème de propriété récursive qui entraînait le blocage de Visual Studio pendant les scénarios de liaison WIT (Work Item Tracking).
• Résolution d’un problème où la page Pool d’agents sous Paramètres de collecte a généré une erreur et n’a pas pu se charger lorsque Analytics a été suspendu ou désactivé. La page se charge maintenant correctement, quel que soit l’état d’Analytics.

Date de publication d’Azure DevOps Server RC : 7 octobre 2025

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

Azure DevOps Server présente les fonctionnalités que nous avons publiées précédemment dans notre version hébergée du produit. Vous pouvez accéder à des sections individuelles pour voir toutes les nouvelles fonctionnalités de chaque service :

• Généralités
• Comités
• Repos
• Pipelines
• Test Plans
• Rapports
• Wiki

General

Copier le bloc de code dans le Presse-papiers

En réponse à vos commentaires dans la Communauté des développeurs, nous avons introduit le bouton Copier dans le Presse-papiers pour tous les blocs de code dans le rendu Markdown. Cette amélioration est disponible dans les pages Wiki, les aperçus des fichiers Markdown dans Repos, les discussions et descriptions des demandes de tirage (pull request) et les discussions sur les éléments de travail.

Autorisation Plans de remise ajoutée

Dans le cadre de nos améliorations de sécurité en cours, nous avons introduit une nouvelle autorisation gérer les plans de livraison au niveau du projet. Cette modification a été implémentée pour empêcher l’accès accidentel de lecture/écriture aux utilisateurs du groupe Lecteurs.

Boards

Liens AB# sur les demandes de tirage GitHub

Dans le cadre de nos améliorations continues apportées à l’intégration d’Azure Boards + GitHub, nous sommes heureux d’introduire une nouvelle fonctionnalité qui simplifie l’affichage des liens AB#. Avec cette mise à jour, les liens AB# apparaissent désormais directement dans la section Développement des demandes de tirage GitHub, ce qui facilite l’accès aux éléments de travail liés sans effectuer de recherches dans des descriptions ou des commentaires.

Ces liens s’affichent uniquement lorsque AB# est inclus dans la description de la demande de tirage. Si vous liez directement à partir d’un élément de travail, ils ne seront pas affichés dans la section Développement. En outre, la suppression du lien AB# de la description le supprime du contrôle développement.

Amélioration de la recherche de connexion au référentiel GitHub

Nous avons amélioré le processus de connexion d’un projet Azure DevOps à une organisation GitHub, particulièrement bénéfique pour ceux avec des milliers de dépôts. Auparavant, vous avez peut-être rencontré des difficultés telles que des erreurs de délai d’attente et des délais d’attente longs. Cette mise à jour optimise l’expérience de recherche et de sélection, éliminant le risque d’erreurs de délai d’expiration et rendant le processus de connexion plus fluide et plus efficace.

Intégration GitHub : afficher l’état de build pour les pipelines YAML

Nous nous engageons à atteindre la parité des fonctionnalités entre YAML et Pipelines classiques. Une fonctionnalité manquante est la possibilité de fournir un lien « Intégré dans la build » lorsque votre dépôt est hébergé dans GitHub. Avec notre dernière version, nous avons résolu cet écart en ajoutant une option dans les paramètres de pipeline YAML pour vous permettre de vérifier :

Une fois la compilation terminée, le lien correspondant apparaît automatiquement sur les éléments de travail associés, améliorant la traçabilité globale.

Prise en charge de l’API REST pour la connexion aux référentiels GitHub

Nous introduisons de nouveaux points de terminaison d’API REST qui vous permettent d’automatiser l’ajout et la suppression de dépôts GitHub dans vos projets Azure DevOps. En outre, nous avons augmenté la limite de référentiel par connexion de 500 à 2 000 lors de l’utilisation de ces points de terminaison.

Ces points de terminaison sont les suivants :

• Liste des connexions actuelles
• Liste des référentiels connectés
• Ajout et suppression de référentiels

Nous avons également fourni des exemples de code pour vous aider à commencer.

Modification pour la suppression des chemins de zone et d'itération

La suppression d’une zone ou d’un chemin d’itération peut être perturbatrice. Il peut déplacer des éléments de travail vers un nouveau chemin et peut entraîner la perte d’accès des équipes à leurs tableaux et backlogs. Malgré les avertissements et les invites, les chemins d’accès sont parfois supprimés sans comprendre pleinement les conséquences. Pour résoudre ce problème, nous avons modifié le comportement : les chemins de zone et d’itération ne peuvent désormais être supprimés que s’ils ne sont plus utilisés par des éléments de travail.

Gestion améliorée des étiquettes sur le formulaire d’élément de travail

La gestion des étiquettes dans Azure Boards a été améliorée pour offrir une expérience plus rationalisée. Les balises supprimées n’apparaissent plus dans la liste suggérée sur les formulaires d’élément de travail, ce qui garantit que seules les balises actives sont affichées.

Prise en charge améliorée des images dans les commentaires d’éléments de travail

Nous avons amélioré notre prise en charge du collage d’images dans les commentaires de tâches. Vous pouvez désormais coller des images directement à partir de sources telles que Microsoft Teams, des e-mails et des documents Word dans la section de discussion d’un élément de travail

Limite de l’API REST sur les commentaires d’élément de travail

Pour améliorer la sécurité, une nouvelle limite a été définie sur le nombre de commentaires qui peuvent être ajoutés aux éléments de travail via l’API REST. Chaque élément de travail prend désormais en charge un maximum de 1 000 commentaires via l’API. Cette restriction s’applique uniquement à l’API REST, et les utilisateurs peuvent toujours ajouter manuellement des commentaires via l’interface web, même au-delà du seuil de 1 000 commentaires.

Augmentation de la limite des plans de livraison

Nous avons augmenté le nombre maximal de plans de livraison par projet de 1 000 à 1 500.

Repos

Nouveau paramètre pour désactiver la création de référentiels TFVC

Au cours des dernières années, aucune nouvelle fonctionnalité n’a été ajoutée à Team Foundation Version Control (TFVC), car Git est devenu le système de contrôle de version préféré dans Azure Repos. Toutes les améliorations récentes de la sécurité, des performances et de l’accessibilité ont été apportées exclusivement aux référentiels Git, ce qui entraîne une baisse continue de l’utilisation de TFVC. Bien que certains s’appuient toujours sur TFVC et que nous n’avons pas l’intention de supprimer cet ensemble de fonctionnalités, nous prévoyons de supprimer progressivement TFVC pour les nouveaux projets et collections de projets, ainsi que pour les projets qui n’utilisent actuellement pas TFVC.

Dans le cadre de cette transition, nous introduisons un nouveau paramètre pour « Désactiver la création de référentiels TFVC », ce qui affecte uniquement la création de nouveaux référentiels TFVC et n’aura pas d’impact sur les dépôts existants.

Prise en charge de l’interface utilisateur des sous-modules Git

De nombreuses équipes utilisent activement des sous-modules Git pour organiser leur codebase. Nous sommes ravis de partager que nous avons ajouté la prise en charge des sous-modules Git dans le hub Files. Vous pouvez maintenant accéder instantanément à un référentiel de sous-modules en un seul clic, exactement à la validation spécifique référencée à partir de votre superprojet. Lorsqu’ils sont utilisés comme sous-module, les services Git suivants sont pris en charge : Azure Repos, GitHub, GitLab et Bitbucket. Plusieurs formats d’URL spécifiés dans le fichier .gitmodules sont également pris en charge, notamment https absolu, SSH et URL relatives.

Nouveau panneau « Intégrité et utilisation » dans le hub de fichiers de dépôt

À mesure que les référentiels Git augmentent, ils accumulent des validations, des objets blob et d’autres données, ce qui peut augmenter la charge sur l’infrastructure Azure DevOps, ce qui a un impact sur les performances et l’expérience utilisateur. La gestion d’un référentiel sain est essentielle pour garantir des performances et une fiabilité cohérentes.

Pour prendre en charge ce problème, nous allons maintenant surveiller plusieurs facteurs tels que la taille du référentiel, la fréquence de validation, le contenu et la structure. Si votre référentiel commence à forcer l’infrastructure, vous pouvez recevoir une notification avec des recommandations d’action corrective. En gérant l’intégrité de votre référentiel, vous pouvez empêcher les interruptions et garantir des opérations fluides.

Pour vérifier l’intégrité de votre référentiel, accédez à Azure Repos, > Files et choisissez « Intégrité et utilisation » dans le menu points de suspension pour accéder au volet d’intégrité et d’utilisation du référentiel.

Configurer des branches cibles pour les demandes de tirage

La gestion de plusieurs branches dans un référentiel peut être difficile, en particulier en créant de nouvelles pull requests. Avec la nouvelle fonctionnalité Configurer les branches cibles pour les demandes d’extraction, vous pouvez désormais spécifier une liste de branches cibles préférées, ce qui garantit que les suggestions de demande de tirage sont plus précises et pertinentes. Cela permet de rationaliser votre flux de travail et de réduire les chances de cibler la branche incorrecte. Pour utiliser cette fonctionnalité, créez un fichier .azuredevops/pull_request_targets.yml dans la branche par défaut de votre dépôt. Ce fichier YAML doit contenir une liste intitulée pull_request_targets avec les noms de branche ou les préfixes qui correspondent aux branches candidates. Par exemple:

pull_request_targets:
  - main
  - release/*
  - feature/*

Dans cette configuration, la branche principale est hiérarchisée, mais les branches commençant par la version/ou la fonctionnalité/ seront également prises en compte le cas échéant. La configuration est appliquée dans les scénarios suivants :

• Suggestions de demande de tirage : après avoir envoyé une branche à Azure DevOps, la page Repos peut suggérer la création d’une demande de tirage à partir de cette branche, en choisissant dynamiquement la branche cible.
• URL de la demande de tirage : lorsque vous accédez directement à la page de création de demande de tirage à l’aide d’un paramètre sourceRef, mais omettez le paramètre targetRef, Azure DevOps sélectionne une branche cible en fonction de ce choix dynamique.

Il est recommandé d'inclure uniquement les branches protégées par les politiques de demande de pull afin de garantir la cohérence dans l'historique du premier parent de la validation de la pointe.

Prendre en charge les diagrammes mermaid dans un fichier Markdown

Les fichiers Markdown contenant la syntaxe mermaid s’affichent désormais sous forme de diagrammes dans les aperçus de fichiers de l'outil de navigation de fichiers des dépôts et dans les pull requests. Cela peut vous aider à ajouter une documentation plus riche à vos référentiels.

Recherche de demandes de tirage par titre sur la page de liste des PR

La page de liste des pull requests inclut désormais un filtre par titre de pull request, facilitant la localisation de pull requests spécifiques.

Sparse checkout pour Azure Repos

La commande git sparse-checkout est désormais prise en charge dans la tâche d’extraction YAML, en même temps que le filtre de clone partiel, pour améliorer les performances d’extraction du référentiel. Vous pouvez utiliser les propriétés sparseCheckoutDirectories et sparseCheckoutPatterns.

Configurer sparseCheckoutDirectories active le mode cônique, où le processus d’extraction utilise la correspondance des répertoires. Vous pouvez également définir des sparseCheckoutPatterns, qui déclenchent le mode non-cone et permettent une correspondance de motifs plus complexe.

Si les deux propriétés sont définies, l’agent initialise le mode cone avec l’appariement de répertoires. Si aucune propriété n’est spécifiée dans la tâche de validation, le processus de validation clairsemée est désactivé. Tout problème rencontré lors de l’exécution de la commande entraîne l’échec de la tâche de validation. Exemple YAML pour le mode cone de sparse checkout :

    checkout: repo
    sparseCheckoutDirectories: src
YAML example for sparse checkout non-cone mode:
YAMLCopy

   checkout: repo
   sparseCheckoutPatterns: /* !/img 

Vous trouverez l’agent sur la page des versions.

Rendre les politiques cross-repo sensibles à la casse

Auparavant, l’aperçu des candidats de branche pour les politiques cross-repo affichait des résultats de manière insensible à la casse, bien que la correspondance des branches soit sensible à la casse. Cette incohérence a créé un risque de désalignement, car il pouvait sembler que des branches étaient protégées alors qu'elles ne l'étaient pas. Pour résoudre ce problème, nous avons mis à jour l’aperçu du modèle de branche afin qu’il soit conforme au comportement sensible à la casse de l’application des politiques.

Auparavant:

After:

Changements dans les stratégies d'enregistrement du TFVC

Nouvelle version (19.254) du package NuGet Microsoft.TeamFoundationServer.ExtendedClient

Le package NuGet Microsoft.TeamFoundationServer.ExtendedClient a été mis à jour avec les nouvelles classes et méthodes de stratégie TFVC.

Modifications de stratégie

Nous apportons des modifications à la façon dont les stratégies de validation TFVC sont stockées dans Azure DevOps, ce qui implique également des mises à jour de la façon dont le NuGet Microsoft.TeamFoundationServer.ExtendedClient communique avec le service. Si votre projet TFVC utilise des stratégies de validation, migrez ces stratégies vers le nouveau format. Il existe deux méthodes pour y parvenir :

1. Utilisation de Visual Studio.

Avertissement

Certaines conséquences d'une action peuvent être dangereuses. Veillez à mettre à jour Visual Studio vers la dernière version avant de continuer (VS 2022, VS 2019 et VS 2017 avec les versions minimales 17.14 Preview 3, 17.13.6, 17.12.7, 17.10.13, 17.8.20, 16.11.46, 15.9.72 prennent en charge les nouvelles politiques).

Pour créer de nouvelles stratégies à l'aide de Visual Studio, l’administrateur du projet doit ouvrir Paramètres -> Projet d'équipe -> Contrôle de code source -> Stratégie de validation et ajouter une nouvelle stratégie (sans marque « Obsolète ») avec les mêmes paramètres que l'ancienne :

2. Si vous utilisez une implémentation personnalisée de Microsoft.TeamFoundationServer.ExtendedClient pour communiquer avec le serveur, suivez le guide de migration. La migration est nécessaire pour maintenir la compatibilité des enregistrements TFVC avec les futures versions d'Azure DevOps. Pour le moment, les anciennes (obsolètes) et les nouvelles stratégies restent valides et fonctionnelles. Pour plus d’informations sur les plans futurs, consultez notre billet de blog.

Amélioration de l’API GetRepository

Nous avons ajouté la propriété creationDate à la réponse de l'API Repositories - Get Repository, retournant la date de création du référentiel. La propriété est disponible sur les versions 7.2-preview et ultérieures de l’API.

Amélioration de l'API de requête des demandes de tirage

Nous avons introduit une nouvelle propriété Label dans la réponse à la requête de pull request - API Obtenir. Vous pouvez maintenant spécifier s'il faut inclure des étiquettes pour les pull requests associées dans chaque requête. Une nouvelle propriété Include est disponible ; si elle est définie sur Étiquettes, la réponse inclut des étiquettes pour les pull requests spécifiées. Si elles sont laissées comme null, les étiquettes ne sont pas incluses. Pour éviter les erreurs involontaires, assurez-vous que NotSet n’est pas explicitement affecté. Cela entraînera une mauvaise requête.

Exemple de charge utile de requête :

{
    "queries": [
        {
            "type": "lastMergeCommit",
            "include": "Labels",
            "items": [ 
                "0d6c9b2b524113113fced41aecbf8631a4649dec"
            ]
        },
        {
            "type": "lastMergeCommit",
            "items": [
                "b524113113f0dd41aecbf8631a4649dec6c9b2ce"
            ]
        }
    ]
}

Pipelines

TFX vérifie si une tâche utilise un exécuteur de processus Node en fin de vie.

Les auteurs de tâches utilisent TFX pour publier des extensions. Le TFX a été mis à jour pour effectuer des validations sur d’autres versions de l’exécuteur Node.

Les extensions qui contiennent des tâches utilisant une version d’exécuteur Node.js qui est en fin de vie (EOL) (jusqu’à et y compris Node 16) recevront cet avertissement :

Task < TaskName > dépend d'un exécuteur de tâches arrivé en fin de vie et qui sera supprimé à l'avenir. Les auteurs doivent consulter les conseils de mise à niveau des nœuds : https://aka.ms/node-runner-guidance

Accéder à Azure Service Bus à partir de Pipelines à l’aide de l’authentification Microsoft Entra ID

Vous pouvez maintenant utiliser l’authentification Microsoft Entra ID pour accéder à Azure Service Bus à partir d’Azure Pipelines. Cela vous permet de tirer parti d’Azure RBAC pour un contrôle d’accès affiné.

Les identités accédant à Azure Service Bus doivent se voir attribuer l’un des rôles intégrés Azure pour Azure Service Bus sur le Service Bus auquel elles accèdent.

tâche de PublishToAzureServiceBus@2

Les nouvelles tâches PublishToAzureServiceBus@2 peuvent être configurées à l’aide d’une connexion de service Azure. Créez une connexion de service Azure et remplissez les propriétés serviceBusQueueName et serviceBusNamespace de la nouvelle tâche :

- task: PublishToAzureServiceBus@2
  inputs:
    azureSubscription: my-azure-service-connection
    serviceBusQueueName: my-service-bus-queue
    serviceBusNamespace: my-service-bus-namespace
    useDataContractSerializer: false
    messageBody: |
      {
        "foo": "bar"
      }

Tâches du serveur

Les tâches de serveur personnalisé (sans agent) qui utilisent l’exécution de ServiceBus peuvent spécifier une connexion de service Azure en tant que EndpointId et omettre ConnectionString. Consultez la création de tâches serveur.

TFX vérifie si une tâche utilise un exécuteur de processus Node en fin de vie.

Les auteurs de tâches utilisent TFX pour publier des extensions. Le TFX a été mis à jour pour effectuer des validations sur d’autres versions de l’exécuteur Node.

Les extensions qui contiennent des tâches utilisant une version d’exécuteur Node.js qui est en fin de vie (EOL) (jusqu’à et y compris Node 16) recevront cet avertissement :

Task < TaskName > dépend d'un exécuteur de tâches arrivé en fin de vie et qui sera supprimé à l'avenir. Les auteurs doivent consulter les conseils de mise à niveau des nœuds : https://aka.ms/node-runner-guidance

Les tâches qui utilisent une version de Node Runner en fin de vie pour s’exécuter émettent des avertissements

Les tâches de pipeline qui s’appuient sur une version de Nœud qui ne sont plus conservées commencent à recevoir des avertissements : la version TaskName dépend d’une version de Nœud (10) qui est en fin de vie. Contactez le propriétaire de l’extension pour obtenir une version mise à jour de la tâche. Les gestionnaires de tâches doivent consulter les instructions de mise à niveau des nœuds : https://aka.ms/node-runner-guidance pour supprimer ces avertissements, vous pouvez définir un environnement ou une variable de pipeline au niveau du pipeline (travail) ou de la tâche. Par exemple:

variables:
  AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false

DockerCompose@0 utilise Docker Compose v2 en mode de compatibilité v1

Docker Compose v1 atteint sa fin de vie et sera supprimé des agents hébergés le 24 juillet 2024. Nous avons mis à jour la tâche DockerCompose@0 pour utiliser Docker Compose v2 en mode de compatibilité v1 si Docker Compose v1 n’est pas disponible sur l’agent.

Toutefois, le mode de compatibilité ne traite pas tous les problèmes de compatibilité. Consultez Migrer vers Composer V2. Certains utilisateurs auront besoin de plus de temps pour mettre à jour leurs projets Docker Compose pour la compatibilité docker Compose v2. Dans ce cas, suivez ces instructions pour utiliser la tâche DockerComposeV0 avec docker-compose v1. REMARQUE : Ce guide est basé sur la documentation Install Compose autonome Utiliser docker-compose v1 sur Windows Ajouter l’étape PowerShell à votre pipeline pour télécharger docker-Compose v1.29.2 et l’utiliser avec la tâche DockerComposeV0 sur Windows :

variables:
    dockerComposePath: C:\docker-compose

steps:
- powershell: |
    mkdir -f $(dockerComposePath)
    # GitHub now requires TLS1.2. In PowerShell, run the following
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: '**/docker-compose.yml'
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)\docker-compose.exe
Use docker-compose v1 on Linux
Add the bash step to your pipeline to download Docker-Compose v1.29.2 and use it with the DockerComposeV0 task on Linux:
YAMLCopy
variables:
    dockerComposePath: /tmp/docker-compose

steps:
- bash: |
    sudo mkdir $(dockerComposePath)
    sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
    sudo chmod 755 $(dockerComposePath)/docker-compose
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)/docker-compose

Test Plans

Extension "Test et Feedback" dans Manifest V3

Nous sommes heureux d’annoncer une nouvelle mise à jour de l’extension Test et Commentaires Azure DevOps pour Chrome et Edge. Cette mise à jour passe de notre implémentation de Manifest V2 à V3, conformément à la planification de dépréciation de Google pour Manifest V2. Bien que les principales fonctionnalités de l’extension restent inchangées, la mise à jour améliore la sécurité et les performances.

Pour plus d’informations, consultez notre billet de blog récent sur cette mise à jour. Tester l’extension de commentaires dans le manifeste V3

Azure Test Runner version 1.2.2

Azure Test Plans a publié un correctif dans la version 1.2.2 pour un problème récent dans les plans de test où Azure Test Runner(ATR) a rencontré des échecs de lancement dans Chrome version 130. Ce problème s’est produit en raison de la prise en charge ajoutée de Chrome pour les URL de schéma non spéciales, ce qui a affecté le flux utilisateur ATR. Avec cette mise à jour, le bogue de régression est résolu et les fonctionnalités ATR sont restaurées. Pour plus d’informations sur ce bogue de régression, consultez ce suivi des problèmes dans Chromium.

Nous vous encourageons à utiliser l’application web pour des fonctionnalités améliorées. Si vous trouvez des fonctionnalités manquantes dans l’application web, nous aimerions entendre de vous. Partagez vos commentaires avec nous !

Intégration transparente du pipeline de construction pour l'exécution des cas de test

Nous avons simplifié le processus d’exécution de cas de test en intégrant en toute transparence les configurations de pipeline de build. Les définitions de build et les ID définis au niveau du plan de test se propagent automatiquement à Web Runner, ce qui élimine la nécessité d’une configuration manuelle à chaque fois. Cette amélioration permet de gagner du temps et d’améliorer l’efficacité, ce qui vous permet de vous concentrer sur des tâches plus critiques.

Restaurer des plans de test supprimés et des suites de test à l’aide de l’API REST

Restaurez facilement les plans de test supprimés et les suites de test avec de nouvelles API en libre-service. Nous introduisons les API GET et PATCH qui vous permettent de rechercher des plans de test ou des suites supprimés et de les restaurer avec leurs éléments enfants, sans avoir besoin de support client. Avec ces API, vous pouvez rapidement récupérer des éléments de travail de test supprimés accidentellement, ce qui réduit les temps d’arrêt et améliore la productivité. Bien que les artefacts d’exécution ne soient pas restaurés, tous les plans de test, suites et cas de test associés peuvent être ramenés à votre espace de travail avec facilité. Cette fonctionnalité en libre-service vous donne un meilleur contrôle sur la gestion des tests et simplifie le processus de restauration, ce qui accélère et rend plus efficace la récupération des ressources de test critiques.

Exporter des cas de test avec des colonnes personnalisées dans XLSX

Vous pouvez désormais exporter des cas de test avec des colonnes personnalisées dans XLSX. En fonction de vos commentaires, les plans de test prennent en charge l’exportation de cas de test avec des colonnes personnalisées, ce qui vous offre une plus grande flexibilité et un meilleur contrôle des données que vous partagez et analysez. Cette amélioration vous aide à adapter les exportations à vos besoins, en vous assurant que les informations que vous exportez sont pertinentes et exploitables.

Nouvelles fonctionnalités de tri dans le répertoire Plans de test

Le répertoire Plans de test offre désormais des options de tri améliorées ! Avec cette mise à jour, vous pouvez organiser rapidement chaque colonne alphanumériquement, en fournissant un moyen simplifié de rechercher et d’accéder à vos données.

Annuler l’étape de test dans l'exécuteur web et l'exécuteur de bureau

Prenez le contrôle de l'exécution de votre cas de test avec la nouvelle option « Annuler ». Vous pouvez facilement rétablir les états des étapes de test avec un simple double-clic, ce qui vous donne plus de flexibilité et de contrôle pendant les exécutions de test. Pas plus de redémarrage des cas de test pour corriger les clics accidentels : annulez et poursuivez votre flux de travail sans interruption.

Nous introduisons également des améliorations de navigation et d’accessibilité conviviales au clavier pour garantir que cette fonctionnalité fonctionne en toute transparence pour tous les utilisateurs, notamment ceux qui s’appuient sur des technologies d’assistance. Cette amélioration vous permet de gagner du temps, de réduire la frustration et de rester concentré sur l’exécution de tests efficacement.

Améliorations apportées aux tâches v2 des résultats de la couverture du code

Avec cette version, nous incluons plusieurs améliorations apportées à la tâche v2 :

• Prise en charge étendue des différents formats de couverture du code, notamment : .coverage,.covx,.covb,.cjson,.xml,.lcov et pycov1.

• Génération d’un fichier cjson complet (et d’un rapport de couverture du code) qui contient des informations détaillées sur la couverture du code, telles que les noms de fichiers, les lignes couvertes/non couvertes, etc.

Prise en charge de la couverture de différentiel (couverture de PR) : v2 peut générer des commentaires PR sur la couverture de différentiel pour plusieurs langues au sein du même pipeline.

La tâche v2 prend désormais en charge la tâche Build Quality Check, qui n’a pas été prise en charge dans la tâche v1.

Prise en charge des pipelines YAML dans les plans de test

En plus des pipelines classiques, vous pouvez désormais utiliser vos pipelines YAML lors de la configuration de vos plans de test ou de l’exécution de tests automatisés à partir de plans de test.

Cette demande a été hiérarchisée en fonction des tickets de suggestion de la Communauté des développeurs suivants.

• Autoriser le pipeline YAML à utiliser dans les paramètres du plan de test

• Exécuter des tests automatisés à partir de Plans de test Azure à l’aide du pipeline YAML

Rapports

Données des colonnes de cumul accessibles dans le backlog

Nous avons mis à jour les colonnes de cumul pour afficher les données disponibles les plus récentes. Auparavant, ces colonnes pouvaient apparaître vides pour les éléments de travail fréquemment mis à jour, ce qui entraînait une confusion. Vous verrez également un horodatage indiquant quand les données ont été actualisées pour la dernière fois. Bien qu'un certain retard dans le traitement Analytics soit normal, ces améliorations visent à assurer la transparence et à offrir une expérience plus fluide lors de l’utilisation des colonnes de cumul.

Wiki

Amélioration du collage de contenu HTML dans les wikis

Nous avons simplifié le collage du contenu HTML dans les Wikis. À présent, des éléments HTML tels que des liens, des listes, des tableaux, des images, des feuilles Excel, des messages Microsoft Teams, des e-mails et des requêtes Azure Data Explorer sont automatiquement convertis en syntaxe Markdown pour une modification plus fluide.