Notes de publication Azure DevOps Server 2022 Update 2
| | 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 Update 2 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 2 RC Date de publication : 7 mai 2024
Azure DevOps Server 2022.2 RC inclut de nombreuses nouvelles fonctionnalités. Voici les principales :
- Limites pour les chemins de zone et d’itération
- Ignorer les approbations et les vérifications dans les pipelines
- Validation YAML améliorée
- Prise en charge d’Azure Artifacts pour Cargo Crates
- Nouvelle expérience de répertoire de tableau de bord
- Copie et importation rapides avec le plan de test ou l’ID de suite
Vous pouvez également accéder à des sections individuelles pour voir toutes les nouvelles fonctionnalités de chaque service :
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 de série de test au 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 le frame hôte. Il peut être utilisé pour :
- Informer l’hôte que l’extension est chargée ou contient 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 vers Azure DevOps
- Obtenir les services distants proposés par le cadre hôte
Vous trouverez une référence complète sur l’API dans la documentation du package azure-devops-extension-sdk. Cette nouvelle version prend en charge les modules suivants :
Prise en charge du module ES : Sdk prend désormais en charge les modules ES (ECMAScript) en plus des modules AMD (Définition de module asynchrone) existants. Vous pouvez désormais importer le KIT de développement logiciel (SDK) à l’aide de la syntaxe du module ES, qui permet d’améliorer les performances et de réduire 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 de zone et d’itération
Les limites jouent un rôle important dans le maintien de l’intégrité et de l’efficacité d’un service global de grande envergure. Avec cette version, nous introduisons des limites matérielles de 10 000 par projet pour les chemins de zone et d’itération. Visitez la page Suivi du travail, 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 développement et déploiement correspondants sont masqués dans le formulaire.
Si vous décidez de connecter un dépôt GitHub à Azure Boards, le contrôle Développement pour les dépôts GitHub s’affiche.
Repos
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 répondre à des exigences réglementaires/de conformité plus strictes, nous offrons une option pour empêcher l’utilisateur d’approuver ses propres modifications, sauf autorisation explicite.
L’utilisateur capable de gérer les stratégies de branche peut désormais basculer l’option « Exiger au moins une approbation à chaque itération » sous « Quand les nouvelles modifications sont envoyées ». Lorsque cette option est sélectionnée, au moins un vote d’approbation pour la dernière modification de la branche source est requis. 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 de 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 (validation effectuée par l’utilisateur B), l’utilisateur C l’a approuvée. À ce moment-là, cela impliquait 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. Cela impliquait l’approbation d’une validation antérieure effectuée par l’utilisateur C, mais elle n’impliquait 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 quatre non approuvée doit être approuvée par l’utilisateur B, C ou tout autre utilisateur qui n’a apporté aucune modification à la demande de tirage.
Notes
Il existe un problème connu dans lequel les stratégies de branche prennent un groupe, configuré en tant que réviseur, comme entité d’approbation. Imaginons qu’une approbation soit requise par tout utilisateur du groupe G. L’utilisateur A est membre de ce groupe G. Une fois que l’utilisateur A a fourni l’approbation comme dans l’image ci-dessus (après la cinquième itération), l’approbation du groupe G approuve la modification effectuée par l’utilisateur A. Ce problème n’est pas attendu et sera résolu dans la version RTW.
Prise en charge des filtres sans objet blob et sans arborescence
Azure DevOps prend désormais en charge deux filtrages supplémentaires lors du clonage/extraction. Ces règles sont les suivantes :--filter=blob:none et--filter=tree:0 La première option (clone sans objet blob) est préférable pour le développement normal, tandis que la deuxième option (clone sans arbre) convient mieux aux cas où vous ignorez le clone après, par exemple en exécutant une build.
Dépréciation SSH-RSA
Azure Repos fournit deux méthodes permettant aux utilisateurs d’accéder à un dépôt 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 prenons uniquement en charge SSH-RSA et nous avons demandé aux utilisateurs d’activer le SSH-RSA ici.
Avec cette mise à jour, nous annonçons la dépréciation de SSH-RSA en tant que méthode de chiffrement prise en charge pour la connexion à Azure Repos à l’aide de SSH. Vous trouverez plus d’informations dans le billet de blog Fin de la prise en charge SSH-RSA pour Azure Repos billet de blog.
Pipelines
Empêcher les exécutions de pipeline involontaires
Aujourd’hui, si votre pipeline YAML ne spécifie pas de trigger section, il s’exécute pour toutes les modifications envoyées à son dépôt. Cela peut créer une confusion quant à la raison pour laquelle un pipeline s’est exécuté et entraîner de nombreuses exécutions involontaires.
Nous avons ajouté un paramètre Pipelines au niveau de la collection de projets et du projet nommé Désactiver le déclencheur CI YAML implicite qui vous permet de modifier ce comportement. Vous pouvez choisir de ne pas déclencher les pipelines si leur section de déclencheur est manquante.
Réessayez une étape où les approbations et les vérifications expirent
Lorsque les approbations et les vérifications expirent, l’étape à laquelle ils appartiennent est ignorée. Les étapes qui ont une dépendance à l’étape ignorée sont également ignorées.
Vous pouvez maintenant réessayer une étape où les approbations et les vérifications expirent. Auparavant, cela était possible uniquement lorsqu’un délai d’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 du service ARM.
Supposons que vous avez ajouté les vérifications suivantes sur la connexion de service : approbation, case activée heures d’ouverture et case activée d’appel de fonction Azure (pour appliquer un délai entre différentes régions).
Maintenant, 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 que les approbations et les vérifications se terminent.
Avec cette version, nous avons permis de contourner les approbations et les vérifications en cours d’exécution, afin que vous puissiez terminer votre correctif logiciel.
Vous pouvez contourner les approbations en cours d’exécution, les heures d’ouverture, l’appel de fonction Azure et l’appel de vérifications de l’API REST.
Contourner une approbation.
Contourner les heures d’ouverture case activée.
Contourner l’case activée d’appel de fonction Azure. Contourner les heures d’ouverture case activée.
Lorsqu’une case activée est contournée, vous pouvez la voir dans le panneau de vérifications.
Vous ne pouvez contourner une case activée que 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 d’appel
Imaginez que vous déployez votre système en plusieurs étapes. Avant de déployer la deuxième étape, il existe un case activée d’approbation et d’appel de fonction Azure qui exécute une case activée saine d’intégrité sur la partie déjà déployée du système.
Lorsque vous examinez la demande d’approbation, vous remarquez la santé case activée exécutée deux jours plus tôt. Dans ce scénario, vous connaissez peut-être un autre déploiement qui a affecté le résultat du case activée sain d’esprit.
Avec cette mise à jour, vous pouvez réexécuter Invoke Azure Function et Invoke REST API checks. Cette fonctionnalité est disponible uniquement pour les vérifications qui ont réussi et qui n’ont pas de nouvelles tentatives.
Notes
Vous pouvez réexécuter une case activée uniquement si vous êtes administrateur de la ressource sur laquelle les vérifications ont été définies.
Prise en charge du serveur d’entreprise GitHub dans le modèle requis case activée
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 de votre collection de projets.
Le modèle Exiger case activée 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 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. En effet, lorsqu’un environnement est créé, la personne qui le crée devient automatiquement le seul administrateur. Par exemple, si vous souhaitez gérer les approbations et les vérifications de tous les environnements de manière centralisée, vous deviez 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 ne se met pas à l’échelle lorsque de nouveaux environnements sont ajoutés.
Avec cette version, nous avons ajouté un rôle Administrateur au niveau du hub d’environnements. Cela permet aux environnements de s’aligner sur 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 la collection de projets.
Un utilisateur disposant de ce rôle d’administrateur peut administrer les 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 d’administrateur d’utilisateur au niveau du hub d’environnements, il devient administrateur pour tous les environnements existants et pour tous les environnements futurs.
Validation YAML améliorée
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 complète lorsqu’il s’agit d’expressions.
Lors de l’écriture de 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 malpelté. Auparavant, cette erreur n’était pas détectée. À présent, la fonctionnalité Valider détecte cela et génère un message d’erreur.
Azure Pipelines détecte des 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 la phase à 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 y a 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 des déploiements, la traçabilité des éléments de travail et des validations, ainsi que 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 pour 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 l’utilisateur appartient dans les résultats de la recherche.
Les approbations contiennent désormais des informations sur l’exécution du pipeline à laquelle 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 désormais capturer des 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, y compris 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. Cela fonctionne 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 pipeline v3.227 prend désormais en charge Alpine Linux versions 3.13 et ultérieures. Alpine Linux est une image de conteneur (de base) populaire. 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 dans le pipeline sont exécutées à l’aide d’un exécuteur, avec Node.js utilisés dans la plupart des cas. Les tâches Azure Pipelines qui utilisent un nœud en tant qu’exécuteur utilisent désormais toutes le nœud 16. Le nœud 16 étant la première version de Node à prendre en charge en mode natif le silicium Apple, cela complète également la prise en charge complète des tâches pour macOS sur le silicium Apple. Les agents s’exécutant sur le silicium Apple n’ont pas besoin de Rosetta pour s’exécuter.
Comme la date de fin de vie du nœud 16 a progressé, nous avons commencé à exécuter des tâches avec le nœud 20.
Annonce de la mise hors service des tâches déconseillées
Azure Pipelines comporte de nombreuses tâches déconseillées. Les tâches déconseillées seront supprimées le 31 janvier 2024. Pour vous aider à identifier les pipelines qui utilisent des tâches déconseillées, les pipelines affichent des avertissements si une telle tâche est utilisée. Nous avons mis à jour la référence des tâches pour indiquer clairement la dépréciation status et la date de mise hors service.
Les tâches suivantes ont été déconseillées et commencent à émettre des avertissements :
- AppCenterDistributeV1,
- AppCenterDistributeV2
- AzureMonitorV0
- ChefKnifeV1
- ChefV1
- CondaEnvironmentV1
- DeployVisualStudioTestAgentV2
- DotNetCoreInstallerV1
- IISWebAppDeployment
- QuickPerfTestV1
- RunJMeterLoadTestV1
- RunLoadTestV1
- SqlServerDacpacDeploymentV1
- XamarinTestCloudV1
Mettez à jour vos pipelines pour utiliser une version de tâche plus récente ou une alternative avant le 31 janvier 2024.
Augmentation des limites d’Azure Pipeline pour s’aligner sur la taille maximale de 4 Mo du modèle Azure Resource Manager (ARM).
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 de 4 Mo des modèles ARM 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 les App Service avec l’authentification de base désactivée. Si l’authentification de base est désactivée sur le App Service, les tâches AzureRmWebAppDeploymentV3/4 utilisent Microsoft Entra ID authentification 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, ce qui est le cas sur les agents hébergés windows-2022/windows-latest (voir référence sur les tâches).
La substitution désactivée de la stratégie de couverture du code status à Échec en cas d’échec de la génération
Précédemment dans, la stratégie de couverture du code status a été remplacée par « Échec » en cas d’échec de votre build dans la demande de tirage. Il s’agissait d’un bloqueur pour certains d’entre vous qui avaient la build en tant que case activée facultatif et la stratégie de couverture du code en tant que case activée obligatoire pour les demandes de tirage, ce qui entraînait 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 ravis d’annoncer qu’Azure Artifacts offre désormais une prise en charge native pour les caisses cargo. Cette prise en charge inclut la parité des fonctionnalités par rapport à nos protocoles existants, en plus de crates.io disponible en tant que source amont. Les développeurs et les équipes Rust peuvent désormais consommer, publier, gérer et partager leurs caisses Cargo en toute transparence, 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 effectuée, à compter du 27 novembre 2023, vos builds entraîneront un échec.
Prise en charge d’Azure Artifacts 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 à jour automatiquement des versions de package non sécurisées. Pour plus d’informations, consultez Utiliser l’audit npm pour détecter et corriger les vulnérabilités de package.
Rapports
Nouvelle expérience de répertoire de tableau de bord
Nous avons écouté vos commentaires et sommes ravis de présenter la nouvelle expérience d’annuaire dashboard. Il offre non seulement une conception d’interface utilisateur moderne, mais vous permet également de trier par colonne, avec l’ajout de la colonne Dernière configuration . Cette colonne vous fournit de meilleures informations 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 tableaux de bord au niveau du projet, ce qui vous permet d’accéder uniquement à la liste de ce que vous devez voir tout en masquant les 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 une vue d’ensemble rapide et d’explorer des segments de graphique spécifiques pour obtenir des informations détaillées. Vous n’avez plus besoin de créer des requêtes personnalisées pour accéder à l’élément de données exact 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 inestimables pour façonner 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 que uniquement en tant que numéro de niveau supérieur. L’affichage couverture du code s’affiche lorsque le bouton Mode d’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 vues nouvelle et ancienne.
Test Plans
Copie et importation rapides avec le plan de test ou l’ID de suite
Vous pouvez désormais gérer facilement plusieurs plans de test dans Azure Test Plans ! Reconnaissant les défis précédemment rencontrés avec les menus déroulants longs pour l’importation, la copie ou le clonage des cas de test, en particulier pour les plans ou suites étendus, nous avons pris des mesures pour simplifier votre flux de travail.
Nous sommes ravis d’annoncer la fonctionnalité Plan de test et ID de suite Recherche fonctionnalité. Entrez votre plan de test ou votre ID de 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 la rend plus intuitive et moins chronophage.
Mise à jour pour Azure Test Runner
Nous sommes ravis de partager qu’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 interruption ni retard. L’ancienne version d’Azure Test Runner n’est plus prise en charge. Pour optimiser les performances et la fiabilité de vos opérations de test, nous vous recommandons de mettre à jour vers 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 faciliter la transition vers la nouvelle version, une invite de mise à niveau s’affiche. Cela garantit que tout le monde peut facilement passer à la version améliorée à votre convenance, ce qui améliore la compatibilité et les performances.
Commentaires
Nous aimerions connaître votre opinion ! Vous pouvez signaler un problème ou fournir une idée et le suivre dans Developer Community et obtenir des conseils sur Stack Overflow.