Notes de publication d’Azure DevOps Server 2022 Update 2

| Communauté des développeurs | Configuration requise du système et compatibilité | Termes du contrat de licence | Blog DevOps | Hachages 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 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 7 : 11 novembre 2025

Nous avons publié patch 7 pour Azure DevOps Server 2022 Update 2 pour inclure les éléments suivants :

• Mise à jour du proxy TFVC : l’algorithme de hachage utilisé dans le processus d’autorisation a été mis à jour de SHA-1 vers SHA-256. Pour garantir la compatibilité et empêcher les interruptions, mettez à jour le proxy avec le serveur.
• Résolution d’un problème lié aux fichiers binaires non signés dans les tâches MSBuildV1 et VSBuildV1.
• Performances optimisées pour l'acteur de l'étape DeleteJobDefinitionsByExtensionName.

Date de publication d’Azure DevOps Server 2022 Update 2 Patch 6 : 10 juin 2025

Nous avons publié patch 6 pour Azure DevOps Server 2022 Update 2 afin d’inclure les améliorations suivantes des plans de test :

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

Avec ce correctif, 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 sur les 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.

• Importez des suites et copiez des cas de test en utilisant uniquement l'identifiant de plan et l'identifiant de suite dans la recherche.

Date de publication d’Azure DevOps Server 2022 Update 2 Patch 5 : 8 avril 2025

Nous avons publié patch 5 pour Azure DevOps Server 2022 Update 2 pour inclure :

• Précédemment, l’agent Azure DevOps a utilisé le CDN Edgio avec le point de terminaison vstsagentpackage.azureedge.net. Dans le cadre de la retraite d’Edgio, le *.azureedge.net domaine est mis hors service. Pour garantir une disponibilité continue, nous avons migré vers un CDN soutenu par Akamai avec un nouveau point de terminaison download.agent.dev.azure.com. Ce correctif inclut les modifications nécessaires pour extraire les fichiers binaires de l'agent à partir du nouveau point de terminaison CDN, ce qui permet de migrer depuis le point de terminaison CDN précédent.

Date de publication d’Azure DevOps Server 2022 Update 2 Patch 4 : 11 mars 2025

Nous avons publié le correctif 4 pour Azure DevOps Server 2022 Update 2 afin d’inclure :

• Mettez à jour les tâches à cause de la dépréciation du CDN Edgio. Pour plus d’informations, consultez le billet de blog sur le changement de fournisseur CDN.
• Mise à niveau de la dépendance Mermaid.

Date de publication d’Azure DevOps Server 2022 Update 2 Patch 3 : 11 février 2025

Nous avons publié patch 3 pour Azure DevOps Server 2022 Update 2 pour inclure :

• Mises à jour des artefacts pour ajouter des propositions d’amélioration Python (PEPs) 685. Cette mise à jour traite des commentaires partagés dans la communauté des développeurs .

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 retour de la communauté des développeurs : correction d’une gestion incorrecte des dates dans la notification par e-mail de PR pour certains formats de région

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 zones et chemins d’itération
• Ignorer les approbations et les vérifications dans les pipelines
• Amélioration de la validation YAML
• Support Azure Artifacts pour les 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 :

• General
• Boards
• Repos
• Pipelines
• Artifacts
• Reporting

General

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 SDK client permet aux extensions web de communiquer avec le cadre 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 pour les appels REST vers Azure DevOps
• Obtenez les services distants proposés par le cadre 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 zones et les chemins d'itération

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 fixons désormais des limitations fixes 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.

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 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 pouvant gérer les stratégies de branche peut désormais activer l'option nouvellement ajoutée « Exiger au moins une approbation sur chaque itération » dans la section « Lorsque de nouvelles modifications sont envoyées ». 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 moment-là, il impliquait l’approbation du premier commit de l’utilisateur A (lors de la création de la demande de tirage) et la stratégie nouvellement introduite réussira. 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, la quatrième itération non approuvée doit être acceptée soit par l'utilisateur B, C, soit par tout autre utilisateur qui n'a apporté aucune modification à la pull request.

Prise en charge des filtres sans blob et sans arbre

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 ces fonctionnalités : --filter=blob:none et --filter=tree:0 La première option (clone sans 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 abandonnez le clone après le lancement d'une construction, par exemple.

Abandon de 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 le 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 le billet de blog Fin du support de SSH-RSA pour Azure Repos.

Pipelines

Empêcher les lancements de pipelines inattendus

Aujourd'hui, si votre pipeline YAML ne spécifie pas de section trigger, il s'exécute pour toutes les modifications poussées vers 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éclenchement est manquante.

Réessayez une étape lorsque les approbations et les vérifications arrivent à expiration.

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

Vous pouvez maintenant réessayer une étape lorsque les approbations et les vérifications atteignent leur échéance. Auparavant, cela n'était possible que lorsqu'une approbation avait 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.

Imaginons que vous avez ajouté les vérifications suivantes sur la connexion de service : une approbation, une vérification pendant les heures d'ouverture et une vérification d'appel de fonction Azure (afin d'appliquer un délai entre les 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 car elle attend que la plupart des vérifications soient terminées. 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 vérifications des approbations, des heures d’activité, invoquer une fonction Azure, et invoquer des vérifications de l’API REST.

Contourner une approbation.

Ignorer la vérification des heures d’ouverture.

Passer outre la vérification de l'invocation 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 l'invocation des vérifications de la fonction Azure

Imaginez que vous déployez votre système en plusieurs étapes. Avant de déployer la deuxième étape, il y a une vérification d'approbation et une vérification de la fonction Azure Invoke qui exécutent 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, il se peut que vous soyez au courant 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 contrôles qui ont réussi et sans nouvelles tentatives.

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

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'imposer qu'un pipeline utilise 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 aligne les environnements 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 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 des 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 mal orthographié. 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 des 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 dont elles font partie.

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 logs 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 réalisées lors d'une tâche.

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 de base populaire pour les conteneurs. 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, Node.js étant utilisé 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 fonctionner.

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).

Désactivation de l'option de modification de l'état de la stratégie de couverture du code en Échec lorsque la construction échoue.

Précédemment, l’état de la stratégie de couverture du code a été remplacé par « Échec » si votre build dans la PR échouait. Il s’agissait d’un élément bloquant pour certains d’entre vous qui avaient la build comme vérification facultative et la stratégie de couverture du code comme vérification obligatoire pour les demandes de fusion, ce qui aboutissait au blocage des demandes de fusion.

À 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 des 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 d'arrêt de prise en charge 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.

Prendre en charge Azure Artifacts pour l'audit npm

Azure Artifacts prend désormais en charge les commandes npm audit et npm audit fix. 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 répertoires

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

Duplication rapide et importation avec un identifiant de plan ou de suite de test

Vous pouvez maintenant gérer plusieurs plans de test dans Azure Test Plans avec facilité ! Reconnaissant les défis qu’impliquent les longs menus déroulants pour l’importation, la copie ou le clonage de cas de test, surtout pour des 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.

Quoi de neuf?

• Stabilité et performances améliorées : Nous avons apporté des améliorations significatives au Test Runner, 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.

Feedback

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.