Notes de publication d’Azure DevOps Server 2022 Update 2

| 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 Update 2 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 2 Patch 2 : 12 novembre 2024

Nous avons publié patch 2 pour Azure DevOps Server 2022 Update 2 afin d’inclure une mise à niveau vers une dépendance vulnérable.

Date de publication d’Azure DevOps Server 2022.2 RTW : 9 juillet 2024

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

Azure DevOps Server 2022.2 RTW est un cumul de correctifs de bogues. Il inclut toutes les fonctionnalités d’Azure DevOps Server 2022.2 RC précédemment publiées. Vous pouvez installer directement Azure DevOps Server 2022.2 ou effectuer une mise à niveau à partir d’Azure DevOps Server 2020, 2019 ou Team Foundation Server 2015 ou version ultérieure. Les problèmes et vulnérabilités suivants ont été résolus avec cette version :

• CVE-2024-35266 : Vulnérabilité d’usurpation d’identité azure DevOps Server
• CVE-2024-35267 : Vulnérabilité d’usurpation d’identité azure DevOps Server
• Ticket de commentaires de la communauté des développeurs : la version de l’agent ne se met pas à jour après la mise à niveau vers Azure DevOps Server 2022.1 et l’utilisation de l’agent de mise à jour dans la configuration du pool d’agents
• Ticket de commentaires de la communauté des développeurs : problème lié au chargement de la page configuration de l’équipe
• Ticket de commentaires de la communauté des développeurs : correction d’une gestion incorrecte des dates dans la notification par e-mail de demande de tirage pour certains formats régionaux

Date de publication d’Azure DevOps Server 2022 Update 2 RC : 7 mai 2024

Azure DevOps Server 2022.2 RC inclut de nombreuses nouvelles fonctionnalités. Voici les principales :

• Limites pour les chemins d’itération et de zone
• Ignorer les approbations et les vérifications dans les pipelines
• Amélioration de la validation YAML
• Prise en charge d’Azure Artifacts pour Cargo Crates
• Nouvelle expérience de répertoire de tableau de bord
• Copie rapide et importation avec l’ID de plan de test ou de suite

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

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

Général

Tâche de publication des résultats des tests

La tâche Publier les résultats des tests prend désormais en charge les pièces jointes d’exécution de test pour le format de rapport JUnit.

Nouvelle version du Kit de développement logiciel (SDK) d’extension web Azure DevOps

Avec cette mise à jour, nous publions une nouvelle version du Kit de développement logiciel (SDK) d’extension web Azure DevOps. Le Kit de développement logiciel (SDK) client permet aux extensions web de communiquer avec l’image hôte. Il peut être utilisé pour :

• Avertir l’hôte que l’extension est chargée ou a des erreurs
• Obtenir des informations contextuelles de base sur la page active (informations sur l’utilisateur actuel, l’hôte et l’extension)
• Obtenir des informations sur le thème
• Obtenir un jeton d’autorisation à utiliser dans les appels REST à Azure DevOps
• Obtenir les services distants proposés par la trame hôte

Vous trouverez une référence d’API complète dans la documentation du package azure-devops-extension-sdk. Cette nouvelle version prend en charge les modules suivants :

• Prise en charge des modules ES : le SDK prend désormais en charge les modules ES (ECMAScript) en plus des modules AMD (définition de module asynchrone) existants. Vous pouvez maintenant importer le SDK à l’aide de la syntaxe du module ES, qui offre des améliorations des performances et réduit la taille de l’application.

• Compatibilité descendante pour les modules AMD : la prise en charge existante des modules AMD reste intacte. Si votre projet utilise des modules AMD, vous pouvez continuer à les utiliser comme avant sans aucune modification.

Comment utiliser :

Pour les modules ES, vous pouvez importer nos modules à l’aide de l’instruction import :

import * as SDK from 'azure-devops-extension-sdk';
// Use the module here

Si vous utilisez des modules AMD, vous pouvez continuer à importer le Kit de développement logiciel (SDK) à l’aide de la require fonction :

require(['azure-devops-extension-sdk'], function(SDK) {

  // Use the module here
});

Boards

Limites pour les chemins d’itération et de zone

Les limites jouent un rôle important dans le maintien de l’intégrité et de l’efficacité d’un service mondial important. Avec cette version, nous introduisons des limites strictes de 10 000 par projet pour les chemins d’itération et de zone. Visitez la page Suivi, processus et limites du projet pour en savoir plus sur les différentes limites du service.

Contrôles de développement et de déploiement

Nous supprimons maintenant les contrôles développement et/ou déploiement de l’élément de travail, en fonction de la configuration de votre projet. Par exemple, vous pouvez configurer vos paramètres de projet pour désactiver repos et/ou pipelines.

Lorsque vous accédez à l’élément de travail, les contrôles de développement et de déploiement correspondants sont masqués du formulaire.

Si vous décidez de connecter un dépôt GitHub à Azure Boards, le contrôle de développement pour les dépôts GitHub s’affiche.

Référentiels

Nouvelle stratégie de branche empêchant les utilisateurs d’approuver leurs propres modifications

Pour améliorer le contrôle sur les modifications approuvées par l’utilisateur et respecter les exigences réglementaires/de conformité plus strictes, nous offrons une option permettant d’empêcher l’utilisateur d’approuver ses propres modifications, sauf autorisation explicite.

L’utilisateur ayant la possibilité de gérer les stratégies de branche peut désormais basculer l’option nouvellement ajoutée « Exiger au moins une approbation sur chaque itération » sous « Lorsque de nouvelles modifications sont envoyées (push) ». Lorsque cette option est sélectionnée, au moins un vote d’approbation pour la dernière modification de branche source est nécessaire. L’approbation de l’utilisateur n’est pas comptabilisée par rapport à une itération non approuvée précédente envoyée par cet utilisateur. Par conséquent, une approbation supplémentaire sur la dernière itération doit être effectuée par un autre utilisateur.

L’image suivante montre la demande de tirage créée par l’utilisateur A et 4 validations supplémentaires (itérations) effectuées sur cette demande de tirage par les utilisateurs B, C, A et C. Une fois la deuxième itération (validée par l’utilisateur B) effectuée, l’utilisateur C a approuvé cela. À ce stade, il implique l’approbation de la première validation de l’utilisateur A (lors de la création de la demande de tirage) et la stratégie nouvellement introduite réussit. Après la cinquième itération (dernière validation de l’utilisateur C), l’approbation a été effectuée par l’utilisateur A. Cette approbation implicite pour la validation antérieure effectuée par l’utilisateur C, mais n’implique pas l’approbation de la deuxième validation effectuée par l’utilisateur A dans la quatrième itération. Pour que la stratégie nouvellement introduite réussisse, l’itération non approuvée quatre doit être approuvée par l’approbation de l’utilisateur B, C ou tout autre utilisateur qui n’a apporté aucune modification à la demande de tirage.

Prise en charge des filtres sans objet blob et sans arborescence

exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1

Azure DevOps prend désormais en charge deux filtrages supplémentaires lors du clonage/extraction. Voici les éléments suivants : --filter=blob:none et--filter=tree:0 La première option (clone sans objet blob) est mieux utilisée pour le développement régulier, tandis que la deuxième option (clone sans arbre) convient mieux pour les cas où vous ignorez le clone après, par exemple l’exécution d’une build.

Dépréciation SSH-RSA

Azure Repos fournit deux méthodes pour permettre aux utilisateurs d’accéder à un référentiel Git dans Azure Repos – HTTPS et SSH. Pour utiliser SSH, vous devez créer une paire de clés à l’aide de l’une des méthodes de chiffrement prises en charge. Dans le passé, nous avons pris en charge uniquement SSH-RSA et nous avons demandé aux utilisateurs d’activer SSH-RSA ici.

Avec cette mise à jour, nous annonçons la dépréciation de SSH-RSA comme méthode de chiffrement prise en charge pour la connexion à Azure Repos à l’aide de SSH. Vous pouvez voir plus de détails dans la fin de la prise en charge de SSH-RSA pour le billet de blog Azure Repos .

Pipelines

Empêcher les exécutions de pipeline inattendues

Aujourd’hui, si votre pipeline YAML ne spécifie pas de trigger section, il s’exécute pour les modifications envoyées à son référentiel. Cela peut créer une confusion quant à la raison pour laquelle un pipeline a été exécuté et entraîner de nombreuses exécutions involontaires.

Nous avons ajouté un paramètre pipelines de niveau projet et collection de projets nommé Désactiver le déclencheur YAML CI implicite qui vous permet de modifier ce comportement. Vous pouvez choisir de ne pas déclencher de pipelines si leur section de déclencheur est manquante.

Réessayez une étape lorsque les approbations et les vérifications expirent

Lorsque les approbations et les vérifications expirent, la phase à laquelle elles appartiennent est ignorée. Les phases qui ont une dépendance sur l’étape ignorée sont également ignorées.

Vous pouvez maintenant réessayer une étape lorsque les approbations et le délai d’attente sont vérifiés. Auparavant, cela n’était possible que lorsqu’une approbation a expiré.

Ignorer les approbations et les vérifications

Les approbations et les vérifications aident à protéger l’accès aux ressources importantes, telles que les connexions de service, les dépôts ou les pools d’agents. Un cas d’usage courant consiste à utiliser approbations et vérifications lors du déploiement en production, et vous souhaitez protéger la connexion de service ARM.

Supposons que vous avez ajouté les vérifications suivantes sur la connexion de service : approbation, vérification des heures d’ouverture et vérification d’appel de fonction Azure (pour appliquer un délai entre différentes régions).

À présent, imaginez que vous devez effectuer un déploiement de correctif logiciel. Vous démarrez une exécution de pipeline, mais elle ne se poursuit pas, elle attend que la plupart des vérifications se terminent. Vous ne pouvez pas vous permettre d’attendre la fin des approbations et des vérifications.

Avec cette version, nous avons permis de contourner les approbations et les vérifications en cours d’exécution. Vous pouvez donc terminer votre correctif logiciel.

Vous pouvez contourner l’exécution des approbations, des heures d’activité, appeler une fonction Azure et appeler des vérifications de l’API REST.

Ignorer une approbation.

Ignorer la vérification des heures d’ouverture.

Ignorer l’appel de la vérification de la fonction Azure. Ignorer la vérification des heures d’ouverture.

Lorsqu’une vérification est ignorée, vous pouvez la voir dans le volet de vérifications.

Vous pouvez contourner une vérification uniquement si vous êtes administrateur de la ressource sur laquelle les vérifications ont été définies.

Réexécuter les vérifications de fonction Azure

Imaginez que vous déployez votre système en plusieurs étapes. Avant de déployer la deuxième étape, il existe une vérification d’approbation et d’appel de fonction Azure qui exécute une vérification de l’intégrité sur la partie déjà déployée du système.

Lorsque vous examinez la demande d’approbation, vous remarquez que la vérification de la santé a été exécutée deux jours plus tôt. Dans ce scénario, vous pouvez être conscient d’un autre déploiement qui a affecté le résultat de la vérification de l’intégrité.

Avec cette mise à jour, vous pouvez réexécuter invoke Azure Function et appeler des vérifications d’API REST. Cette fonctionnalité est disponible uniquement pour les vérifications qui ont réussi et n’ont aucune nouvelle tentative.

Prise en charge du serveur d’entreprise GitHub dans la vérification de modèle requise

Les modèles sont un mécanisme de sécurité qui vous permet de contrôler les étapes, les travaux et les étapes des pipelines dans votre collection de projets.

La vérification de modèle Exiger vous permet d’appliquer qu’un pipeline s’étend à partir d’un ensemble de modèles approuvés avant d’accéder à une ressource protégée, telle qu’un pool d’agents ou une connexion de service.

Vous pouvez maintenant spécifier des modèles situés dans les dépôts GitHub Enterprise Server.

Rôle d’administrateur pour tous les environnements

Les environnements dans les pipelines YAML représentent une ressource de calcul sur laquelle vous déployez votre application, par exemple un cluster AKS ou un ensemble de machines virtuelles. Ils vous fournissent des contrôles de sécurité et une traçabilité pour vos déploiements.

La gestion des environnements peut être très difficile. Cela est dû au fait que, lorsqu’un environnement est créé, la personne qui la crée devient automatiquement l’administrateur unique. Par exemple, si vous souhaitez gérer les approbations et les vérifications de tous les environnements de manière centralisée, vous devez demander à chaque administrateur d’environnement d’ajouter un utilisateur ou un groupe spécifique en tant qu’administrateur, puis d’utiliser l’API REST pour configurer les vérifications. Cette approche est fastidieuse, sujette aux erreurs et n’est pas mise à l’échelle lorsque de nouveaux environnements sont ajoutés.

Avec cette version, nous avons ajouté un rôle d’administrateur au niveau du hub d’environnements. Cela permet d’analyser les environnements avec les connexions de service ou les pools d’agents. Pour attribuer le rôle Administrateur à un utilisateur ou un groupe, vous devez déjà être administrateur du hub d’environnements ou propriétaire de regroupement de projets.

Un utilisateur disposant de ce rôle d’administrateur peut administrer des autorisations, gérer, afficher et utiliser n’importe quel environnement. Cela inclut l’ouverture d’environnements à tous les pipelines.

Lorsque vous accordez un rôle Administrateur utilisateur au niveau du hub d’environnements, ils deviennent administrateurs pour tous les environnements existants et pour tous les environnements futurs.

Amélioration de la validation YAML

Pour vérifier que votre syntaxe YAML est correcte, vous pouvez utiliser la fonctionnalité Valider de l’éditeur web Azure Pipelines. Par conséquent, il est important que cette fonctionnalité intercepte autant de problèmes YAML que possible.

La validation YAML est désormais plus approfondie en ce qui concerne les expressions.

Lorsque vous écrivez des pipelines YAML, vous pouvez utiliser des fonctions pour définir des valeurs de variable.

Imaginez que vous définissez les variables suivantes :

variables:
  Major: '1'
  Minor: '0'
  Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]

La Patch variable est définie à l’aide de la counter fonction et des deux autres variables. Dans le code YAML ci-dessus, le mot format est malté. Auparavant, cette erreur n’a pas été détectée. À présent, la fonctionnalité Valider détecte cette fonctionnalité et affiche un message d’erreur.

Azure Pipelines détecte les définitions de variables incorrectes au niveau du pipeline/ de l’étape/du travail.

Dans les pipelines YAML, vous pouvez ignorer l’exécution de l’étape à l’aide de conditions. Les fautes de frappe peuvent également apparaître ici, comme dans l’exemple suivant.

steps:
- task: NuGetCommand@2
  condition: eq(variable.Patch, 0)
  inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

La NuGetCommand tâche s’exécute uniquement si la valeur de la Patch variable est 0. Là encore, il existe une faute de frappe dans la condition, et la fonctionnalité Valider l’affiche.

Azure Pipelines détecte les conditions YAML incorrectes définies au niveau du pipeline/ de l’étape/du travail.

API REST pour les environnements

Un environnement est une collection de ressources que vous pouvez cibler avec des déploiements à partir d’un pipeline. Les environnements vous fournissent l’historique du déploiement, la traçabilité des éléments de travail et des validations et des mécanismes de contrôle d’accès.

Nous savons que vous souhaitez créer des environnements par programmation. Nous avons donc publié la documentation de leur API REST.

Améliorations apportées à l’API REST Approbations

Nous avons amélioré la localisation des approbations attribuées à un utilisateur en incluant les groupes auxquels appartient l’utilisateur dans les résultats de la recherche.

Les approbations contiennent désormais des informations sur l’exécution du pipeline auxquelles elles appartiennent.

Par exemple, l’appel https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending d’API REST GET suivant retourne

{
    "count": 1,
    "value":
    [
        {
            "id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
            "steps":
            [],
            "status": "pending",
            "createdOn": "2023-11-09T10:54:37.977Z",
            "lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers":
            [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
                }
            },
            "pipeline":
            {
                "owner":
                {
                    "_links":
                    {
                        "web":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
                        },
                        "self":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
                        }
                    },
                    "id": 73222930,
                    "name": "20231109.1"
                },
                "id": "4597",
                "name": "FabrikamFiber"
            }
        }
    ]
}

Les journaux de pipeline contiennent désormais l’utilisation des ressources

Les journaux de pipeline Azure peuvent maintenant capturer les métriques d’utilisation des ressources, telles que la mémoire, l’utilisation du processeur et l’espace disque disponible. Les journaux incluent également les ressources utilisées par l’agent de pipeline et les processus enfants, notamment les tâches exécutées dans un travail.

Si vous pensez que votre travail de pipeline peut rencontrer des contraintes de ressources, activez les journaux détaillés pour que les informations d’utilisation des ressources soient injectées dans les journaux de pipeline. Ils fonctionnent sur n’importe quel agent, indépendamment du modèle d’hébergement.

L’agent Azure Pipelines prend désormais en charge Alpine Linux

L’agent de pipeline v3.227 prend désormais en charge les versions Alpine Linux 3.13 et ultérieures. Alpine Linux est une image populaire pour conteneur (base). Vous trouverez l’agent sur la page des versions. Les versions Alpine Linux de l’agent ont un préfixe vsts-agent-linux-musl , par exemple vsts-agent-linux-musl-x64-3.227.1.tar.gz.

Les tâches Azure Pipelines utilisent le nœud 16

Les tâches du pipeline sont exécutées à l’aide d’un exécuteur, avec Node.js utilisées dans la plupart des cas. Les tâches Azure Pipelines qui utilisent un nœud en tant qu’exécuteur utilisent désormais le nœud 16. Comme Node 16 est la première version de Node à prendre en charge apple silicon en mode natif, cela complète également la prise en charge complète de macOS sur apple silicon. Les agents qui s’exécutent sur apple silicon n’ont pas besoin de Rosetta pour s’exécuter.

Comme la date de fin de vie du nœud 16 a été déplacée vers l’avant, nous avons démarré le travail pour exécuter des tâches avec Node 20.

Augmentation des limites d’Azure Pipeline pour s’aligner sur la taille maximale de modèle Azure Resource Manager (ARM) de 4 Mo.

Vous pouvez utiliser la tâche de déploiement de modèle Azure Resource Manager pour créer une infrastructure Azure. En réponse à vos commentaires, nous avons augmenté la limite d’intégration d’Azure Pipelines de 2 Mo à 4 Mo. Cela s’aligne sur la taille maximale des modèles ARM de 4 Mo pour résoudre les contraintes de taille lors de l’intégration de modèles volumineux.

La tâche AzureRmWebAppDeployment prend en charge l’authentification Microsoft Entra ID

Les tâches AzureRmWebAppDeploymentV3 et AzureRmWebAppDeployment@4 ont été mises à jour pour prendre en charge App Service avec l’authentification de base désactivée. Si l’authentification de base est désactivée sur App Service, les tâches AzureRmWebAppDeploymentV3/4 utilisent l’authentification d’ID Microsoft Entra pour effectuer des déploiements sur le point de terminaison Kudu App Service. Cela nécessite une version récente de msdeploy.exe installée sur l’agent, qui est le cas sur les agents hébergés windows-2022/windows-latest (voir la référence de tâche).

Remplacement désactivé de l’état de la stratégie de couverture du code en échec lors de l’échec de la génération

Précédemment, l’état de la stratégie de couverture du code a été remplacé par « Échec » si votre build dans la demande de tirage a échoué. Il s’agissait d’un bloqueur pour certains d’entre vous qui disposaient de la build en tant que vérification facultative et de la stratégie de couverture du code en tant que vérification requise pour les demandes de tirage entraînant le blocage des demandes de tirage.

À présent, la stratégie de couverture du code ne sera pas remplacée par « Échec » si la build échoue. Cette fonctionnalité sera activée pour tous les clients.

Artifacts

Présentation de la prise en charge d’Azure Artifacts pour cargo Crates

Nous sommes heureux d’annoncer qu’Azure Artifacts offre désormais une prise en charge native des caisses Cargo. Cette prise en charge inclut la parité des fonctionnalités par rapport à nos protocoles existants, en plus de crates.io être disponible en tant que source en amont. Les développeurs et équipes Rust peuvent désormais consommer, publier, gérer et partager leurs caisses Cargo de manière transparente, tout en utilisant l’infrastructure robuste d’Azure et en restant dans l’environnement Azure DevOps familier.

Annonce de dépréciation pour les tâches de pipeline NuGet Restore v1 et NuGet Installer v0

Si vous utilisez les tâches de pipeline NuGet Restore v1 et NuGet Installer v0, passez rapidement à la tâche de pipeline NuGetCommand@2. Vous commencerez bientôt à recevoir des alertes dans vos pipelines si la transition n’a pas été effectuée. Si aucune action n’est entreprise, à partir du 27 novembre 2023, vos builds échoueront.

Prise en charge des artefacts Azure pour l’audit npm

Azure Artifacts prend désormais en charge npm audit et npm audit fix commandes. Cette fonctionnalité permet aux utilisateurs d’analyser et de corriger les vulnérabilités de leur projet en mettant automatiquement à jour les versions de package non sécurisées. Pour en savoir plus, utilisez l’audit npm pour détecter et corriger les vulnérabilités des packages.

Reporting

Nouvelle expérience de répertoire de tableau de bord

Nous avons écouté vos commentaires et nous sommes ravis d’introduire la nouvelle expérience de répertoire de tableau de bord. Il propose non seulement une conception moderne de l’interface utilisateur, mais vous permet également de trier par colonne, avec l’ajout de la dernière colonne configurée . Cette colonne vous fournira de meilleurs insights sur l’utilisation globale du tableau de bord au sein de votre collection de projets. En outre, vous pouvez désormais filtrer par équipe ou par tableau de bord au niveau du projet, ce qui vous permet d’accéder uniquement à la liste de ce que vous devez voir lors du masquage des tableaux de bord que vous ne souhaitez pas afficher.

Essayez-le maintenant et faites-nous savoir ce que vous pensez dans notre communauté Azure DevOps

Filtrage des éléments de travail

Nous sommes heureux d’annoncer le filtrage des graphiques d’éléments de travail. Cette fonctionnalité vous permet de pointer sur votre graphique d’éléments de travail pour obtenir une vue d’ensemble rapide et d’explorer des segments de graphique spécifiques pour obtenir des insights détaillés. Vous n’avez plus besoin de créer des requêtes personnalisées pour accéder à l’élément exact de données dont vous avez besoin. Vous pouvez maintenant explorer vos éléments de travail dans les graphiques d’éléments de travail en quelques clics.

Vos commentaires sont précieux dans la mise en forme de l’avenir de cette fonctionnalité. Essayez-le maintenant et faites-nous savoir ce que vous pensez dans notre communauté Azure DevOps.

Résultats de la couverture du code pour les dossiers

Les résultats de la couverture du code sont désormais disponibles pour chaque fichier et dossier individuel plutôt qu’en tant que numéro de niveau supérieur. La vue de couverture du code s’affiche lorsque le bouton mode Affichage dossier est activé. Dans ce mode, vous pouvez explorer et voir la couverture du code pour cette sous-arborescence sélectionnée. Utilisez le bouton bascule pour basculer entre les nouvelles vues et les anciennes vues.

Test Plans

Copie rapide et importation avec l’ID de plan de test ou de suite

Vous pouvez maintenant gérer plusieurs plans de test dans Azure Test Plans avec facilité ! Reconnaissance des défis rencontrés précédemment avec les menus déroulants longs pour l’importation, la copie ou le clonage de cas de test, en particulier pour les plans ou suites étendus, nous avons pris des mesures pour simplifier votre flux de travail.

Nous sommes heureux d’annoncer la fonctionnalité Test Plan and Suite ID Search. Entrez votre plan de test ou votre ID suite pour importer ou copier rapidement des cas de test sans aucun délai. Cette mise à jour fait partie de notre engagement continu à améliorer votre expérience de gestion des tests, ce qui le rend plus intuitif et moins fastidieux.

Mise à jour pour Azure Test Runner

Nous sommes heureux de partager que Azure Test Runner a été mis à jour vers une version plus récente. Cette mise à jour améliore la stabilité et les performances, ce qui vous permet d’exécuter vos tests sans interruptions ni retards. L’ancienne version d’Azure Test Runner n’est plus prise en charge. Pour obtenir les meilleures performances et la fiabilité de vos opérations de test, nous vous recommandons de mettre à jour la version la plus récente dès que possible.

Nouveautés

• Stabilité et performances améliorées : nous avons apporté des améliorations significatives à l’exécuteur de test, en traitant les problèmes rencontrés par certains utilisateurs. Cette mise à niveau garantit un processus de test plus fiable, ce qui réduit les interruptions de votre travail.
• Invite de mise à niveau : pour rendre la transition vers la nouvelle version transparente, vous rencontrerez une invite de mise à niveau. Cela garantit que tout le monde peut facilement passer à la version améliorée à votre convenance, améliorer la compatibilité et les performances.

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.