Notes de publication d’Azure DevOps Server 2022 Update 1

| 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 1 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 1 Patch 4 : 11 juin 2024

Nous avons publié le correctif 4 pour Azure DevOps Server 2022 Update 1 qui inclut un correctif pour les éléments suivants.

• Correction d’un problème dans les éléments wiki et de travail dans lesquels les résultats de recherche n’étaient pas disponibles pour les projets qui avaient le « I » turc dans leur nom pour les paramètres régionaux turcs.

Date de publication d’Azure DevOps Server 2022 Update 1 Patch 3 : 12 mars 2024

Nous avons publié patch 3 pour Azure DevOps Server 2022 Update 1 qui inclut des correctifs pour les éléments suivants.

• Résolution d’un problème où le serveur proxy a cessé de fonctionner après l’installation de Patch 2.
• Correction d’un problème de rendu sur la page détails de l’extension affectant les langues qui n’étaient pas l’anglais.

Date de publication d’Azure DevOps Server 2022 Update 1 Patch 2 : 13 février 2024

Nous avons publié patch 2 pour Azure DevOps Server 2022 Update 1 qui inclut des correctifs pour les éléments suivants.

• Résolution du problème de rendu des pages de détails sur l’extension de recherche.
• Correction d’un bogue où l’espace disque utilisé par le dossier du cache proxy était calculé de manière incorrecte et que le dossier n’était pas correctement nettoyé.
• CVE-2024-20667 : Vulnérabilité d’exécution de code à distance d’Azure DevOps Server.

Date de publication d’Azure DevOps Server 2022 Update 1 Patch 1 : 12 décembre 2023

Nous avons publié patch 1 pour Azure DevOps Server 2022 Update 1 qui inclut des correctifs pour les éléments suivants.

• Empêchez le paramètre requested for lors de la mise en file d’attente d’une exécution de pipeline.

Date de publication d’Azure DevOps Server 2022 Update 1 : 28 novembre 2023

Azure DevOps Server 2022.1 est un cumul de correctifs de bogues. Elle inclut toutes les fonctionnalités d’Azure DevOps Server 2022.1 RC2 précédemment publiées.

Date de publication d’Azure DevOps Server 2022 Update 1 RC2 : 31 octobre 2023

Azure DevOps Server 2022.1 RC2 est un cumul de correctifs de bogues. Il inclut toutes les fonctionnalités d’Azure DevOps Server 2022.1 RC1 précédemment publiées.

Les éléments suivants ont été corrigés avec cette version :

• Correction d’un problème dans les flux locaux où les entrées en amont ne résolvaient pas les modifications de nom complet.
• Une erreur inattendue s’est produite lors du changement d’onglets du code vers un autre onglet de la page De recherche.
• Erreur lors de la création d’un nouveau type d’élément de travail avec des idéogrammes unifiés chinois, japonais et coréens (CJK). Un point d’interrogation a été affiché sur le journal RAW lors de l’archivage contrôlé lorsque le nom ou les fichiers du projet d’équipe incluaient CJK.
• Correction d’un problème lors de l’installation de La recherche où la machine virtuelle Java (JVM) n’a pas pu allouer suffisamment de mémoire au processus de recherche élastique. Le widget de configuration de recherche utilise désormais le Kit de développement Java (JDK) qui est fourni avec la recherche élastique et supprime donc la dépendance sur n’importe quel environnement Java Runtime (JRE) préinstallé sur le serveur ciblé.

Date de publication d’Azure DevOps Server 2022 Update 1 RC1 : 19 septembre 2023

Azure DevOps Server 2022.1 RC1 inclut de nombreuses nouvelles fonctionnalités. Voici les principales :

• Toutes les API REST publiques prennent en charge des étendues PAT granulaires
• Dernière colonne Consultée sur la page Plans de remise
• Visualiser toutes les dépendances sur les plans de livraison
• macro @CurrentIteration dans les plans de remise
• Projet actuel défini comme étendue par défaut pour le jeton d’accès de build dans les pipelines classiques
• Afficher le parent dans le widget Résultats de la requête
• Copier le tableau de bord
• Prise en charge des types de diagrammes supplémentaires dans les pages wiki
• Les connexions de service Container Registry peuvent désormais utiliser des identités managées Azure

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
• Wiki

Général

Toutes les API REST publiques prennent en charge des étendues PAT granulaires

Auparavant, un certain nombre d’API REST Azure DevOps documentées publiquement n’étaient pas associées à des étendues (par exemple, lecture d’éléments de travail) qui ont conduit les clients à utiliser des étendues complètes pour consommer ces API via des mécanismes d’authentification non interactifs tels que des jetons d’accès personnels (PAT). L’utilisation d’un jeton d’accès personnel complet augmente le risque lorsqu’il peut atterrir entre les mains d’un utilisateur malveillant. C’est l’une des principales raisons pour lesquelles bon nombre de nos clients n’ont pas pleinement profité des stratégies de plan de contrôle pour limiter l’utilisation et le comportement du PAT.

À présent, toutes les API REST Azure DevOps publiques sont désormais associées et prennent en charge une étendue PAT granulaire. Si vous utilisez actuellement un PAT complet pour vous authentifier auprès de l’une des API REST Azure DevOps publiques, envisagez de migrer vers un pat avec l’étendue spécifique acceptée par l’API pour éviter tout accès inutile. La ou les étendues PAT granulaires prises en charge pour une API REST donnée sont disponibles dans la section Sécurité des pages de documentation. En outre, il existe ici une table des étendues.

Les extensions doivent afficher leurs étendues

Lors de l’installation d’extensions dans votre collection Azure DevOps, vous pouvez passer en revue les autorisations dont l’extension a besoin dans le cadre de l’installation. Toutefois, une fois installées, les autorisations d’extension ne sont pas visibles dans les paramètres d’extension. Cela a posé un défi aux administrateurs qui ont besoin d’effectuer une révision périodique des extensions installées. À présent, nous avons ajouté les autorisations d’extension aux paramètres d’extension pour vous aider à passer en revue et à prendre une décision éclairée quant à leur conservation ou non.

Boards

Dernière colonne Consultée sur la page Plans de remise

La page d’annuaire plans de remise fournit la liste des plans définis pour votre projet. Vous pouvez trier par : Nom, Créé par, Description, Dernière configuration ou Favoris. Avec cette mise à jour, nous avons ajouté une dernière colonne accessible à la page du répertoire. Cela offre une visibilité sur le moment où un plan de livraison a été ouvert pour la dernière fois et examiné. Par conséquent, il est facile d’identifier les plans qui ne sont plus utilisés et qui peuvent être supprimés.

Visualiser toutes les dépendances sur les plans de livraison

Les plans de remise ont toujours fourni la possibilité de voir les dépendances entre les éléments de travail. Vous pouvez visualiser les lignes de dépendance, une par une. Avec cette version, nous avons amélioré l’expérience en vous permettant de voir toutes les lignes de dépendances sur tous les éléments de travail à l’écran. Cliquez simplement sur le bouton bascule des dépendances en haut à droite de votre plan de remise. Cliquez de nouveau dessus pour désactiver les lignes.

Nouvelles limites de révision d’élément de travail

Au cours des dernières années, nous avons vu des regroupements de projets avec des outils automatisés générer des dizaines de milliers de révisions d’éléments de travail. Cela crée des problèmes de performances et d’utilisation sur le formulaire d’élément de travail et les API REST de création de rapports. Pour atténuer le problème, nous avons implémenté une limite de révision d’élément de travail de 10 000 à Azure DevOps Service. La limite affecte uniquement les mises à jour à l’aide de l’API REST, et non du formulaire d’élément de travail.

Cliquez ici pour en savoir plus sur la limite de révision et sur la façon de la gérer dans vos outils automatisés.

Augmenter la limite de l’équipe plans de livraison de 15 à 20

Les plans de remise vous permettent d’afficher plusieurs backlogs et plusieurs équipes dans votre collection de projets. Auparavant, vous pouvez afficher 15 backlogs d’équipe, y compris un mélange de backlogs et d’équipes provenant de différents projets. Avec cette version, nous avons augmenté la limite maximale de 15 à 20.

Correction d’un bogue dans l’API Get des liens d’élément de travail de création de rapports

Nous avons résolu un bogue dans l’API Get des liens d’élément de travail de création de rapports pour renvoyer la valeur remoteUrl correcte pour System.LinkTypes.Remote.Related les types de liens. Avant ce correctif, nous renvoyions le nom de collection de projets incorrect et un ID de projet manquant.

Créer un point de terminaison REST de requête temporaire

Nous avons vu plusieurs instances d’auteurs d’extensions qui tentent d’exécuter des requêtes non enregistrées en passant l’instruction WIQL (Work Item Query Language) via la chaîne de requête. Cela fonctionne correctement, sauf si vous avez une instruction WIQL volumineuse qui atteint les limites du navigateur sur la longueur de la chaîne de requête. Pour résoudre ce problème, nous avons créé un nouveau point de terminaison REST pour permettre aux auteurs d’outils de générer une requête temporaire. L’utilisation de l’ID de la réponse pour passer via querystring élimine ce problème.

Pour en savoir plus, consultez la page de documentation de l’API REST des requêtes temporaires.

API de suppression par lots

Actuellement, la seule façon de supprimer des éléments de travail de la corbeille utilise cette API REST pour en supprimer une à la fois. Il peut s’agir d’un processus lent et est soumis à une limitation de débit lorsque vous essayez de faire n’importe quel type de nettoyage de masse. En réponse, nous avons ajouté un nouveau point de terminaison d’API REST pour supprimer et/ou détruire des éléments de travail par lots.

@CurrentIteration macro dans les plans de livraison

Avec cette mise à jour, nous avons ajouté la prise en charge de la macro pour les @CurrentIteration styles dans les plans de livraison. Cette macro vous permet d’obtenir l’itération actuelle à partir du contexte d’équipe de chaque ligne de votre plan.

Logique de redimensionnement de carte dans les plans de remise

Tout le monde n’utilise pas la date cible et/ou la date de début lors du suivi des fonctionnalités et épopées. Certains choisissent d’utiliser une combinaison de dates et de chemins d’itération. Dans cette version, nous avons amélioré la logique pour définir correctement le chemin d’itération et les combinaisons de champs de date en fonction de leur mode d’utilisation.

Par exemple, si la date cible n’est pas utilisée et que vous redimensionnez la carte, le nouveau chemin d’itération est défini au lieu de mettre à jour la date cible.

Améliorations apportées aux mises à jour par lots

Nous avons apporté plusieurs modifications à la version 7.1 de l’API de mise à jour par lots d’éléments de travail. Il s’agit notamment d’améliorations mineures des performances et de la gestion des défaillances partielles. Autrement dit, si un correctif échoue mais que les autres ne le font pas, les autres seront terminés.

Cliquez ici pour en savoir plus sur l’API REST de mise à jour par lots.

API de suppression par lots

Ce nouveau point de terminaison d’API REST pour supprimer et/ou détruire des éléments de travail par lots est désormais disponible publiquement. Cliquez ici pour en savoir plus.

Empêcher la modification des champs de listes de choix partageables

Les champs personnalisés sont partagés entre les processus. Cela peut créer un problème pour les champs de liste de sélection, car nous permettons aux administrateurs de processus d’ajouter ou de supprimer des valeurs du champ. Dans ce cas, les modifications affectent ce champ sur chaque processus qui l’utilise.

Pour résoudre ce problème, nous avons ajouté la possibilité pour l’administrateur de collection de « verrouiller » un champ en cours de modification. Lorsque le champ de liste de sélection est verrouillé, l’administrateur de processus local ne peut pas modifier les valeurs de cette liste de sélection. Ils peuvent uniquement ajouter ou supprimer le champ du processus.

Nouvelle autorisation Enregistrer les commentaires

La possibilité d’enregistrer uniquement les commentaires d’élément de travail a été une demande principale dans la communauté des développeurs. Nous sommes heureux de vous informer que nous avons implémenté cette fonctionnalité. Pour commencer, examinons le scénario le plus courant :

« Je veux empêcher certains utilisateurs de modifier des champs d’élément de travail, mais de les autoriser à contribuer à la discussion. »

Pour ce faire, vous devez accéder au chemin de la zone de configuration > du projet des paramètres > du projet. Sélectionnez ensuite le chemin d’accès de zone de votre choix, puis cliquez sur Sécurité.

Notez la nouvelle autorisation « Modifier les commentaires d’élément de travail dans ce nœud ». Par défaut, l’autorisation est définie sur Not set. Cela signifie que l’élément de travail se comporte exactement comme avant. Pour autoriser un groupe ou des utilisateurs à enregistrer des commentaires, sélectionnez ce groupe/ces utilisateurs et modifiez l’autorisation Autoriser.

Lorsque l’utilisateur ouvre le formulaire d’élément de travail dans ce chemin d’accès de zone, il peut ajouter des commentaires, mais ne peut pas mettre à jour l’un des autres champs.

Nous espérons que vous aimez cette fonctionnalité autant que nous le faisons. Comme toujours, si vous avez des commentaires ou des suggestions, faites-nous savoir.

Rapports de tableaux interactifs

Les rapports interactifs, situés dans le hub Boards, ont été accessibles depuis plusieurs années dans notre version hébergée du produit. Ils remplacent les anciens graphiques Diagramme de flux cumulé, Vitesse et Sprint Burndown plus anciens. Avec cette version, nous les mettons à disposition.

Pour afficher ces graphiques, cliquez sur l’onglet Analytics emplacement dans les pages Tableau Kanban, Backlog et Sprints.

Référentiels

Suppression de l’autorisation « Modifier les stratégies » pour le créateur de branche

Auparavant, lorsque vous avez créé une nouvelle branche, nous vous accordons l’autorisation de modifier des stratégies sur cette branche. Avec cette mise à jour, nous modifions le comportement par défaut pour ne pas accorder cette autorisation même si le paramètre « Gestion des autorisations » est activé pour le référentiel.

Vous aurez besoin de l’autorisation « Modifier les stratégies » accordée explicitement (manuellement ou via l’API REST) par héritage des autorisations de sécurité ou via l’appartenance à un groupe.

Pipelines

Projet actuel défini comme étendue par défaut pour le jeton d’accès de build dans les pipelines classiques

Azure Pipelines utilise des jetons d’accès aux travaux pour accéder à d’autres ressources dans Azure DevOps au moment de l’exécution. Un jeton d’accès de travail est un jeton de sécurité généré dynamiquement par Azure Pipelines pour chaque travail au moment de l’exécution. Auparavant, lors de la création d’un pipeline classique, la valeur par défaut du jeton d’accès était définie sur Collection de projets. Avec cette mise à jour, nous définissons l’étendue d’autorisation du travail sur le projet actuel comme valeur par défaut lors de la création d’un pipeline classique.

Vous trouverez plus d’informations sur les jetons d’accès aux travaux dans les référentiels Access, les artefacts et d’autres ressources.

Modification de l’étendue par défaut des jetons d’accès dans les pipelines de build classiques

Pour améliorer la sécurité des pipelines de build classiques, lors de la création d’un nouveau pipeline, l’étendue d’autorisation du travail de génération est Project, par défaut. Jusqu’à présent, il s’agit d’une collection de projets. En savoir plus sur les jetons d’accès aux travaux. Cette modification n’a aucun impact sur les pipelines existants. Il affecte uniquement les nouveaux pipelines de build classiques que vous créez à partir de ce point.

Prise en charge d’Azure Pipelines pour San Diego, Tokyo et Utah de ServiceNow

Azure Pipelines dispose d’une intégration existante à ServiceNow. L’intégration s’appuie sur une application dans ServiceNow et une extension dans Azure DevOps. Nous avons maintenant mis à jour l’application pour qu’elle fonctionne avec les versions de San Diego, Tokyo et Utah de ServiceNow. Pour vous assurer que cette intégration fonctionne, effectuez une mise à niveau vers la nouvelle version de l’application (4.215.2) à partir du Magasin ServiceNow.

Pour plus d’informations, consultez la documentation Intégrer à ServiceNow Change Management.

Utiliser des URL proxy pour l’intégration de GitHub Enterprise

Azure Pipelines s’intègre aux serveurs GitHub Enterprise locaux pour exécuter des builds d’intégration continue et de demande de tirage. Dans certains cas, GitHub Enterprise Server se trouve derrière un pare-feu et nécessite que le trafic soit acheminé via un serveur proxy. Pour prendre en charge ce scénario, les connexions de service GitHub Enterprise Server dans Azure DevOps vous permettent de configurer une URL de proxy. Auparavant, le trafic d’Azure DevOps n’était pas routé via cette URL de proxy. Avec cette mise à jour, nous nous assurons que nous roulons le trafic suivant à partir d’Azure Pipelines pour passer par l’URL du proxy :

• Obtenir des branches
• Obtenir des informations sur la demande de tirage (pull request)
• Rapport sur l’état de la build

Les connexions de service Container Registry peuvent désormais utiliser des identités managées Azure

Vous pouvez utiliser une identité managée affectée par le système lors de la création de connexions de service Docker Registry pour Azure Container Registry. Cela vous permet d’accéder à Azure Container Registry à l’aide d’une identité managée associée à un agent Azure Pipelines auto-hébergé, ce qui élimine la nécessité de gérer les informations d’identification.

Jetons automatiques créés pour la connexion Kubernetes Service

Étant donné que Kubernetes 1.24, les jetons n’ont plus été créés automatiquement lors de la création d’une connexion Kubernetes Service. Nous avons ajouté cette fonctionnalité. Toutefois, il est recommandé d’utiliser la connexion Azure Service lors de l’accès à AKS, pour en savoir plus, consultez les instructions relatives à la connexion de service pour les clients AKS à l’aide du billet de blog des tâches Kubernetes.

Les tâches Kubernetes prennent désormais en charge kubelogin

Nous avons mis à jour les tâches KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 et AzureFunctionOnKubernetes@1 pour prendre en charge kubelogin. Cela vous permet de cibler Azure Kubernetes Service (AKS) configuré avec l’intégration Azure Active Directory.

Kubelogin n’est pas préinstallé sur les images hébergées. Pour vous assurer que les tâches mentionnées ci-dessus utilisent kubelogin, installez-la en insérant la tâche KubeloginInstaller@0 avant la tâche qui dépend de celle-ci :

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Améliorations apportées aux autorisations de pipeline

Nous avons amélioré l’expérience de gestion des autorisations de pipeline pour que le système d’autorisations se souvienne si un pipeline avait déjà utilisé une ressource protégée, telle qu’une connexion de service.

Dans le passé, si vous avez coché « Accorder l’autorisation d’accès à tous les pipelines » lorsque vous avez créé une ressource protégée, mais que vous avez ensuite restreint l’accès à la ressource, votre pipeline avait besoin d’une nouvelle autorisation pour utiliser la ressource. Ce comportement n’était pas cohérent avec l’ouverture et la fermeture ultérieures de l’accès à la ressource, où une nouvelle autorisation n’était pas requise. Ce problème est maintenant résolu.

Nouvelle étendue PAT pour la gestion des autorisations de pipeline, des approbations et des vérifications

Pour limiter les dommages causés par la fuite d’un jeton PAT, nous avons ajouté une nouvelle étendue PAT, nommée Pipeline Resources. Vous pouvez utiliser cette étendue PAT lors de la gestion de l’autorisation de pipeline à l’aide d’une ressource protégée, telle qu’une connexion de service, ou pour gérer les approbations et les vérifications de cette ressource.

Les appels d’API REST suivants prennent en charge la nouvelle étendue PAT comme suit :

• Mettre à jour une approbation prend en charge l’étenduePipeline Resources Use
• Gérer les vérifications prend en charge l’étendue Pipeline Resources Use and Manage
• Mettre à jour les autorisations de pipeline pour les ressources prend en charge l’étendue Pipeline Resources Use and Manage
• Autoriser les ressources de définition prend en charge l’étendue Pipeline Resources Use and Manage
• Autoriser les ressources de projet prend en charge l’étendue Pipeline Resources Use and Manage

Restreindre l’ouverture des ressources protégées aux administrateurs de ressources

Pour améliorer la sécurité des ressources qui sont essentielles à votre capacité à générer et déployer en toute sécurité vos applications, Azure Pipelines nécessite désormais un rôle d’administrateur de type ressource lors de l’ouverture de l’accès à une ressource à tous les pipelines.

Par exemple, un rôle d’administrateur général des connexions de service est requis pour permettre à n’importe quel pipeline d’utiliser une connexion de service. Cette restriction s’applique lors de la création d’une ressource protégée ou lors de la modification de sa configuration de sécurité.

En outre, lors de la création d’une connexion de service et que vous n’avez pas suffisamment de droits, l’autorisation Accorder l’accès à toutes les options de pipelines est désactivée.

Améliorations de la sécurité de l’API REST pipelines

La majorité des API REST dans Azure DevOps utilisent des jetons PAT délimités. Toutefois, certaines d’entre elles nécessitent des jetons PAT entièrement étendus. En d’autres termes, vous devrez créer un jeton PAT en sélectionnant « Accès complet » pour utiliser certaines de ces API. Ces jetons présentent un risque de sécurité, car ils peuvent être utilisés pour appeler n’importe quelle API REST. Nous avons apporté des améliorations dans Azure DevOps pour supprimer la nécessité de jetons entièrement étendus en incorporant chaque API REST dans une étendue spécifique. Dans le cadre de cet effort, l’API REST pour mettre à jour les autorisations de pipeline pour une ressource nécessite désormais une étendue spécifique. L’étendue dépend du type de ressource autorisé à être utilisée :

• Code (read, write, and manage) pour les ressources de type repository
• Agent Pools (read, manage) ou Environment (read, manage) pour les ressources de type queue et agentpool
• Secure Files (read, create, and manage) pour les ressources de type securefile
• Variable Groups (read, create and manage) pour les ressources de type variablegroup
• Service Endpoints (read, query and manage) pour les ressources de type endpoint
• Environment (read, manage) pour les ressources de type environment

Pour modifier en bloc les autorisations des pipelines, vous aurez toujours besoin d’un jeton PAT entièrement étendu. Pour en savoir plus sur la mise à jour des autorisations de pipeline pour les ressources, consultez la documentation sur les autorisations de pipeline - Mettre à jour les autorisations de pipeline pour les ressources .

Gestion des accès affiné pour les pools d’agents

Les pools d’agents vous permettent de spécifier et de gérer les machines sur lesquelles vos pipelines s’exécutent.

Auparavant, si vous utilisiez un pool d’agents personnalisé, la gestion des pipelines qui peuvent y accéder était grossière. Vous pouvez autoriser tous les pipelines à l’utiliser, ou vous pouvez exiger que chaque pipeline demande l’autorisation. Malheureusement, une fois que vous avez accordé une autorisation d’accès au pipeline à un pool d’agents, vous n’avez pas pu le révoquer à l’aide de l’interface utilisateur des pipelines.

Azure Pipelines fournit désormais une gestion d’accès affinée pour les pools d’agents. L’expérience est similaire à celle de la gestion des autorisations de pipeline pour les connexions de service.

Empêcher d’accorder à tous les pipelines l’accès aux ressources protégées

Lorsque vous créez une ressource protégée telle qu’une connexion de service ou un environnement, vous avez la possibilité de sélectionner l’autorisation Accorder l’accès à tous les pipelines . Jusqu’à présent, cette option a été cochée par défaut.

Bien qu’il soit plus facile pour les pipelines d’utiliser de nouvelles ressources protégées, l’inverse est qu’il favorise accidentellement l’octroi d’un trop grand nombre de pipelines le droit d’accéder à la ressource.

Pour promouvoir un choix sécurisé par défaut, Azure DevOps laisse désormais la case à cocher non activée.

Possibilité de désactiver le masquage pour les secrets courts

Azure Pipelines masque les secrets dans les journaux. Les secrets peuvent être des variables marquées comme secrètes, des variables de groupes de variables liés à Azure Key Vault ou des éléments d’une connexion de service marqués comme secret par le fournisseur de connexion de service.

Toutes les occurrences de valeur de secret sont masquées. Le masquage de secrets courts, par exemple « »,1 « », «Dev » permet de deviner facilement leurs valeurs, par exemple dans une date : «Jan 3, 202***2 »
Il est maintenant clair que '3' est un secret. Dans ce cas, vous préférerez peut-être ne pas masquer complètement le secret. S’il n’est pas possible de marquer la valeur comme secret (par exemple, la valeur est extraite de Key Vault), vous pouvez définir le AZP_IGNORE_SECRETS_SHORTER_THAN bouton sur une valeur allant jusqu’à 4.

Tâche de téléchargement de l’exécuteur de nœud

Lorsque vous adoptez des versions de l’agent qui excluent l’exécuteur de tâches Node 6 , vous devrez peut-être parfois exécuter des tâches qui n’ont pas été mises à jour pour utiliser un exécuteur de nœud plus récent. Pour ce scénario, nous fournissons une méthode permettant de continuer à utiliser des tâches dépendantes des exécuteurs de fin de vie des nœuds. Consultez le billet de blog Sur les instructions de l’exécuteur de nœuds.

La tâche ci-dessous est une méthode permettant d’installer l’exécuteur Node 6 juste-à-temps, afin qu’une ancienne tâche puisse toujours s’exécuter :

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

Mise à jour de la validation de l’exécuteur de nœud TFX

Les auteurs de tâches utilisent l’outil d’empaquetage d’extensions (TFX) pour publier des extensions. TFX a été mis à jour pour effectuer des validations sur les versions de l’exécuteur node. Consultez le billet de blog Node runner guidance (Guide de l’exécuteur de nœuds).

Les extensions qui contiennent des tâches utilisant l’exécuteur Node 6 voient cet avertissement :

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

Instructions pour la préinstallation manuelle de Node 6 sur les agents de pipeline

Si vous utilisez le flux de l’agentpipeline-, vous n’avez pas le nœud 6 inclus dans l’agent. Dans certains cas, lorsqu’une tâche de la Place de marché dépend toujours de Node 6 et que l’agent ne peut pas utiliser la tâche NodeTaskRunnerInstaller (par exemple, en raison de restrictions de connectivité), vous devez préinstaller Node 6 indépendamment. Pour ce faire, veuillez consulter les instructions relatives à l’installation manuelle de l’exécuteur Node 6.

Journal des modifications des tâches de pipeline

Nous publions maintenant les modifications apportées aux tâches de pipeline dans ce journal des modifications. Il contient la liste complète des modifications apportées aux tâches de pipeline intégrées. Nous avons publié rétroactivement des modifications antérieures, si bien que le journal des modifications fournit un enregistrement historique des mises à jour des tâches.

Les tâches de mise en production utilisent l’API Microsoft Graph

Nous avons mis à jour nos tâches de publication pour utiliser l’API Microsoft Graph. Cela supprime l’utilisation de l’API AAD Graph de nos tâches.

Amélioration des performances des tâches Windows PowerShell

Vous pouvez utiliser des tâches pour définir l’automatisation dans un pipeline. L’une de ces tâches est la PowerShell@2 tâche utilitaire qui vous permet d’exécuter des scripts PowerShell dans votre pipeline. Pour utiliser le script PowerShell pour cibler un environnement Azure, vous pouvez utiliser la AzurePowerShell@5 tâche. Certaines commandes PowerShell qui peuvent imprimer les mises à jour de progression, par exemple Invoke-WebRequest, s’exécutent maintenant plus rapidement. L’amélioration est plus significative si vous avez un grand nombre de ces commandes dans votre script, ou quand elles sont longues. Avec cette mise à jour, la progressPreference propriété des PowerShell@2 tâches est AzurePowerShell@5 désormais définie SilentlyContinue par défaut.

Pipelines Agent v3 sur .NET 6

L’agent de pipeline a été mis à niveau pour utiliser .NET 3.1 Core vers .NET 6 comme runtime. Cela introduit la prise en charge native d’Apple Silicon ainsi que windows Arm64.

L’utilisation de .NET 6 a un impact sur la configuration système requise pour l’agent. Plus précisément, nous allons supprimer la prise en charge des systèmes d’exploitation suivants : CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Consultez la documentation de l’Agent version 3.

Ce script peut être utilisé pour identifier les pipelines qui utilisent des agents avec des systèmes d’exploitation non pris en charge.

Spécifier la version de l’agent dans l’extension de machine virtuelle agent

Les machines virtuelles Azure peuvent être incluses dans les groupes de déploiement à l’aide d’une extension de machine virtuelle. L’extension de machine virtuelle a été mise à jour pour spécifier éventuellement la version de l’agent souhaitée à installer :

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

Nouvelles bascules pour contrôler la création de pipelines classiques

Azure DevOps vous permet désormais de vous assurer que votre collection de projets utilise uniquement des pipelines YAML, en désactivant la création de pipelines de build classiques, de pipelines de mise en production classiques, de groupes de tâches et de groupes de déploiement. Vos pipelines classiques existants continueront à s’exécuter, et vous pourrez les modifier, mais vous ne pourrez pas en créer de nouveaux.

Azure DevOps vous permet désormais de vous assurer que votre organisation utilise uniquement des pipelines YAML, en désactivant la création de pipelines de build classiques, de pipelines de mise en production classiques, de groupes de tâches et de groupes de déploiement. Vos pipelines classiques existants continueront à s’exécuter, et vous pourrez les modifier, mais vous ne pourrez pas en créer de nouveaux.

Vous pouvez désactiver la création de pipelines classiques au niveau de la collection de projets ou au niveau du projet, en activant les bascules correspondantes. Les bascules sont disponibles dans Project/Project Settings -> Pipelines -> Settings. Il existe deux bascules : une pour les pipelines de build classiques et une pour les pipelines de mise en production classiques, les groupes de déploiement et les groupes de tâches.

L’état des bascules est désactivé par défaut, et vous aurez besoin de droits d’administrateur pour modifier l’état. Si le bouton bascule est activé au niveau de l’organisation, la désactivation est appliquée pour tous les projets. Sinon, chaque projet est libre de choisir s’il faut appliquer ou non la désactivation.

Lors de la désactivation de la création de pipelines classiques, les API REST liées à la création de pipelines classiques, de groupes de tâches et de groupes de déploiement échouent. Les API REST qui créent des pipelines YAML fonctionnent.

Mises à jour de l’événement de raccordement de service « Exécuter l’état de l’étape modifiée »

Les hooks de service vous permettent d’exécuter des tâches sur d’autres services lorsque des événements se produisent dans votre projet dans Azure DevOps, l’état de l’étape d’exécution modifié est l’un de ces événements. L’événement d’état de l’étape d’exécution modifié doit contenir des informations sur l’exécution, y compris le nom du pipeline. Auparavant, elle incluait uniquement des informations sur l’ID et le nom de l’exécution. Avec cette mise à jour, nous avons apporté des modifications à l’événement pour inclure des informations manquantes.

Désactiver l’affichage du dernier message de validation pour une exécution de pipeline

Auparavant, l’interface utilisateur pipelines utilisée pour afficher le dernier message de validation lors de l’affichage de l’exécution d’un pipeline.

Ce message peut prêter à confusion, par exemple, lorsque le code de votre pipeline YAML se trouve dans un référentiel différent de celui qui contient le code qu’il crée. Nous avons entendu vos commentaires de la Communauté des développeurs nous demandant un moyen d’activer/désactiver l’ajout du dernier message de validation au titre de chaque exécution de pipeline.

Avec cette mise à jour, nous avons ajouté une nouvelle propriété YAML, nommée appendCommitMessageToRunName, qui vous permet de le faire exactement. Par défaut, la propriété est définie sur true. Lorsque vous la définissez falsesur , l’exécution du pipeline n’affiche que le BuildNumber.

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.

Icône de vue d’ensemble de l’exécution du pipeline status

Avec cette version, nous allons faciliter la connaissance de l’état global d’une exécution de pipeline.

Pour les pipelines YAML qui ont de nombreuses étapes, il était difficile de savoir la status d’une exécution de pipeline, autrement dit, s’il est toujours en cours d’exécution ou s’il s’est terminé. Et si elle s’est terminée, quel est l’état global : réussite, échec ou annulation. Nous avons résolu ce problème en ajoutant une exécution status icône de vue d’ensemble.

Panneau latéral des phases de pipeline

Les pipelines YAML peuvent avoir des dizaines d’étapes, et ils ne sont pas tous adaptés à votre écran. Bien que l’icône vue d’ensemble de l’exécution du pipeline vous indique l’état global de votre exécution, il est toujours difficile de savoir quelle étape a échoué ou quelle étape est toujours en cours d’exécution, par exemple.

Dans cette version, nous avons ajouté un panneau latéral des phases de pipeline qui vous permet de voir rapidement l’état de toutes vos étapes. Vous pouvez ensuite cliquer sur une étape et accéder directement à ses journaux.

Rechercher des étapes dans le panneau latéral

Nous avons facilité la recherche des étapes que vous recherchez dans le panneau latéral des étapes. Vous pouvez désormais filtrer rapidement les étapes en fonction de leur état, par exemple les phases en cours d’exécution ou celles qui nécessitent une intervention manuelle. Vous pouvez également rechercher des étapes par leur nom.

Actions rapides d’étape

L’écran Exécutions d’un pipeline vous permet d’accéder rapidement à toutes les étapes d’exécution. Dans cette version, nous avons ajouté un panneau d’étapes à partir duquel vous pouvez effectuer des actions pour chaque étape. Par exemple, vous pouvez facilement réexécuter les travaux ayant échoué ou réexécuter l’ensemble de la phase. Le panneau est disponible lorsque toutes les étapes ne correspondent pas à l’interface utilisateur, comme vous pouvez le voir dans la capture d’écran suivante.

Vérifie les améliorations apportées à l’expérience utilisateur

Nous rendons la lecture des journaux de vérification plus facile. Les journaux de vérification fournissent des informations critiques pour la réussite de votre déploiement. Ils peuvent vous indiquer si vous avez oublié de fermer un ticket d’élément de travail ou que vous devez mettre à jour un ticket dans ServiceNow. Auparavant, sachant qu’une vérification a fourni ces informations critiques était difficile.

À présent, la page détails de l’exécution du pipeline affiche le journal de vérification le plus récent. Il s’agit uniquement des vérifications qui suivent notre utilisation recommandée.

Désactiver une vérification

Nous avons effectué des vérifications de débogage moins fastidieuses. Parfois, une vérification de la fonction Azure invoke ou de l’API REST Invoke ne fonctionne pas correctement, et vous devez la corriger. Auparavant, vous deviez supprimer ces vérifications pour les empêcher de bloquer de manière erronée un déploiement. Une fois que vous avez corrigé la vérification, vous deviez l’ajouter et la configurer correctement, en vous assurant que tous les en-têtes requis sont définis ou que les paramètres de requête sont corrects. C’est fastidieux.

Maintenant, vous pouvez simplement désactiver une vérification. La vérification désactivée ne s’exécutera pas dans les évaluations ultérieures de la suite de vérification.

Ressources consommées et paramètres de modèle dans l’API Rest d’exécutions de pipelines

L’API REST Exécutions de pipelines étendues retourne désormais davantage de types d’artefacts utilisés par une exécution de pipeline et les paramètres utilisés pour déclencher cette exécution. Nous avons amélioré l’API pour retourner les container ressources et pipeline les paramètres de modèle utilisés dans une exécution de pipeline. Vous pouvez maintenant, par exemple, écrire des vérifications de conformité qui évaluent les référentiels, conteneurs et autres exécutions de pipeline utilisées par un pipeline.

Voici un exemple du nouveau corps de la réponse.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Prise en charge des modèles de disponibilité générale dans l’éditeur YAML

Les modèles sont une fonctionnalité couramment utilisée au sein des pipelines YAML. Il s’agit d’un moyen simple de partager des extraits de code de pipeline. Ils sont également un mécanisme puissant de vérification ou d’application de la sécurité et de la gouvernance par le biais de votre pipeline.

Azure Pipelines prend en charge un éditeur YAML, qui peut être utile lors de la modification de votre pipeline. Toutefois, l’éditeur n’a pas pris en charge les modèles jusqu’à présent. Les auteurs de pipelines YAML n’ont pas pu obtenir d’assistance via IntelliSense lors de l’utilisation d’un modèle. Les auteurs de modèles n’ont pas pu utiliser l’éditeur YAML. Dans cette version, nous ajoutons la prise en charge des modèles dans l’éditeur YAML.

Lorsque vous modifiez votre fichier principal YAML Azure Pipelines, vous pouvez inclure ou étendre un modèle. Lorsque vous tapez le nom de votre modèle, vous êtes invité à valider votre modèle. Une fois validé, l’éditeur YAML comprend le schéma du modèle, y compris les paramètres d’entrée.

Après validation, vous pouvez choisir d’accéder au modèle. Vous pourrez apporter des modifications au modèle à l’aide de toutes les fonctionnalités de l’éditeur YAML.

Il existe des limitations connues :

• Si le modèle a des paramètres requis qui ne sont pas fournis en tant qu’entrées dans le fichier YAML principal, la validation échoue et vous invite à fournir ces entrées. Dans une expérience idéale, la validation ne doit pas être bloquée et vous devez être en mesure de renseigner les paramètres d’entrée à l’aide d’IntelliSense.
• Vous ne pouvez pas créer un modèle à partir de l’éditeur. Vous pouvez uniquement utiliser ou modifier des modèles existants.

Nouvelle variable système prédéfinie

Nous avons introduit une nouvelle variable système prédéfinie, nommée Build.DefinitionFolderPath, dont la valeur est le chemin d’accès au dossier d’une définition de pipeline de build. La variable est disponible dans les pipelines de build YAML et classique.

Par exemple, si votre pipeline est hébergé sous le FabrikamFiber\Chat dossier dans Azure Pipelines, la valeur est Build.DefinitionFolderPath FabrikamFiber\Chat.

Ajouter la prise en charge de la fonction de fractionnement de chaîne dans les expressions de modèle YAML

Les pipelines YAML vous offrent des moyens pratiques de réduire la duplication de code, telles que la boucle de each la valeur d’une liste ou d’une propriété d’un objet.

Parfois, l’ensemble d’éléments à itérer est représenté sous forme de chaîne. Par exemple, lorsque la liste des environnements à déployer est définie par la chaîne integration1, integration2.

Comme nous avons écouté vos commentaires de la Communauté des développeurs, nous avons entendu que vous vouliez une fonction de chaîne split dans les expressions de modèle YAML.

À présent, vous pouvez split utiliser une chaîne et effectuer une itération sur each ses sous-chaînes.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Expressions de modèle dans la définition de ressource du référentiel

Nous avons ajouté la prise en charge des expressions de modèle lors de la définition de la ref propriété d’une repository ressource dans un pipeline YAML. Il s’agissait d’une fonctionnalité hautement demandée par notre Communauté des développeurs.

Il existe des cas d’usage lorsque vous souhaitez que votre pipeline examine différentes branches de la même ressource de référentiel.

Par exemple, supposons que vous disposez d’un pipeline qui génère son propre référentiel et, pour cela, il doit extraire une bibliothèque à partir d’un référentiel de ressources. En outre, supposons que votre pipeline vérifie la même branche de bibliothèque que celle utilisée par lui-même. Par exemple, si votre pipeline s’exécute sur la main branche, il doit extraire la main branche du référentiel de bibliothèque. Si les pipelines s’exécutent sur la dev branche, il doit extraire la dev branche de bibliothèque.

Jusqu’à aujourd’hui, vous deviez spécifier explicitement la branche à extraire et modifier le code du pipeline chaque fois que la branche change.

À présent, vous pouvez utiliser des expressions de modèle pour choisir la branche d’une ressource de référentiel. Consultez l’exemple suivant de code YAML à utiliser pour les branches non principales de votre pipeline :

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

Lorsque vous exécutez le pipeline, vous pouvez spécifier la branche à extraire pour le library référentiel.

Spécifier la version d’un modèle à étendre au moment de la file d’attente de build

Les modèles représentent un excellent moyen de réduire la duplication de code et d’améliorer la sécurité de vos pipelines.

Un cas d’usage populaire consiste à héberger des modèles dans leur propre dépôt. Cela réduit le couplage entre un modèle et les pipelines qui l’étendent et facilite l’évolution du modèle et des pipelines indépendamment.

Prenons l’exemple suivant, dans lequel un modèle est utilisé pour surveiller l’exécution d’une liste d’étapes. Le code du modèle se trouve dans le Templates référentiel.

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

Supposons que vous disposez d’un pipeline YAML qui étend ce modèle, situé dans le référentiel FabrikamFiber. Jusqu’à aujourd’hui, il n’était pas possible de spécifier dynamiquement la ref propriété de la templates ressource de référentiel lors de l’utilisation du référentiel comme source de modèle. Cela signifie que vous deviez modifier le code du pipeline si vous vouliez que votre pipeline : étendre un modèle à partir d’une autre branche étend un modèle du même nom de branche que votre pipeline, quelle que soit la branche que vous avez exécutée dans votre pipeline

Avec l’introduction d’expressions de modèle dans la définition de ressource du référentiel, vous pouvez écrire votre pipeline comme suit :

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Ainsi, votre pipeline étend le modèle dans la même branche que la branche sur laquelle le pipeline s’exécute. Vous pouvez donc vous assurer que les branches de votre pipeline et du modèle correspondent toujours. Autrement dit, si vous exécutez votre pipeline sur une branche dev, il étend le modèle spécifié par le template.yml fichier dans la dev branche du templates référentiel.

Vous pouvez également choisir, au moment de la génération, la branche de référentiel de modèles à utiliser, en écrivant le code YAML suivant.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

À présent, vous pouvez avoir votre pipeline sur la branche main étendre un modèle à partir d’une branche dev dans une exécution et étendre un modèle à partir d’une branche main dans une autre exécution, sans modifier le code de votre pipeline.

Lorsque vous spécifiez une expression de modèle pour la ref propriété d’une ressource de référentiel, vous pouvez utiliser et système parameters des variables prédéfinies, mais vous ne pouvez pas utiliser des variables DÉFINIES par l’interface utilisateur YAML ou Pipelines.

Expressions de modèle dans la définition de ressource de conteneur

Nous avons ajouté la prise en charge des expressions de modèle lors de la définition des propriétés et options portsdes endpointvolumespropriétés d’une container ressource dans un pipeline YAML. Il s’agissait d’une fonctionnalité hautement demandée par notre Communauté des développeurs.

À présent, vous pouvez écrire des pipelines YAML comme suit.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

Vous pouvez utiliser parameters. et variables. dans vos expressions de modèle. Pour les variables, vous ne pouvez utiliser que celles définies dans le fichier YAML, mais pas celles définies dans l’interface utilisateur de Pipelines. Si vous redéfinissez la variable, par exemple, à l’aide de commandes de journal d’agent, elle n’aura aucun effet.

Améliorations des builds planifiées

Nous avons résolu un problème qui entraînait l’endommagement des informations de planification d’un pipeline et le pipeline à ne pas charger. Cela a été dû, par exemple, lorsque le nom de la branche a dépassé un certain nombre de caractères.

Message d’erreur amélioré lors de l’échec du chargement des pipelines

Azure Pipelines fournit plusieurs types de déclencheurs pour configurer le démarrage de votre pipeline. Une façon d’exécuter un pipeline consiste à utiliser des déclencheurs planifiés. Parfois, les informations d’exécution planifiée d’un pipeline sont endommagées et peuvent entraîner l’échec d’une charge. Auparavant, nous affichions un message d’erreur trompeur, affirmant que le pipeline n’a pas été trouvé. Avec cette mise à jour, nous avons résolu ce problème et renvoyons un message d’erreur informatif. À l’avenir, vous recevrez le message similaire à : Les données de planification de build sont endommagées si un pipeline ne parvient pas à se charger.

Ne synchronisez pas les balises lors de l’extraction d’un référentiel Git

La tâche d’extraction utilise --tags l’option permettant d’extraire le contenu d’un référentiel Git. Cela entraîne l’extraction par le serveur de toutes les balises ainsi que de tous les objets pointés par ces balises. Cela augmente le temps d’exécution de la tâche dans un pipeline, en particulier si vous avez un grand référentiel avec un certain nombre d’étiquettes. En outre, la tâche d’extraction synchronise les balises même lorsque vous activez l’option d’extraction superficielle, ce qui peut vaincre son objectif. Pour réduire la quantité de données extraites ou extraites d’un référentiel Git, nous avons maintenant ajouté une nouvelle option à la tâche pour contrôler le comportement des balises de synchronisation. Cette option est disponible à la fois dans les pipelines classiques et YAML.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Pour tous les nouveaux pipelines que vous créez (YAML ou Classic), les balises sont toujours synchronisées par défaut. Cette option ne modifie pas le comportement des pipelines existants. Les balises sont toujours synchronisées dans ces pipelines, sauf si vous modifiez explicitement l’option comme décrit ci-dessus.

Artifacts

Autorisations de flux par défaut mises à jour

Les comptes du service de génération de regroupement de projets ont désormais le rôle Collaborateur par défaut lorsqu’un nouveau flux Azure Artifacts étendu à la collection de projets est créé, au lieu du rôle Contributeur actuel.

Nouvelle interface utilisateur pour la recherche de package en amont

Auparavant, vous pouviez voir les packages en amont si vous aviez une copie du flux. Le point de douleur était que vous n’avez pas pu rechercher les packages disponibles en amont et qui ne sont pas encore enregistrés dans le flux. À présent, vous pouvez rechercher des packages en amont disponibles avec la nouvelle interface utilisateur de flux.

Azure Artifacts fournit désormais une interface utilisateur qui vous permet de rechercher des packages dans vos sources en amont et d’enregistrer des versions de packages dans votre flux. Cela s’aligne sur l’objectif de Microsoft d’améliorer nos produits et services.

Reporting

Afficher le parent dans le widget Résultats de la requête

Le widget résultats de la requête prend désormais en charge le nom du parent et un lien direct vers ce parent.

Copier le tableau de bord

Avec cette version, nous incluons Copy Dashboard.

Date du dernier accès aux tableaux de bord et modification par

L’un des défis de permettre aux équipes de créer plusieurs tableaux de bord est la gestion et le nettoyage des éléments obsolètes et inutilisés. Savoir quand un tableau de bord a été visité ou modifié pour la dernière fois est un élément important pour comprendre ceux qui peuvent être supprimés. Dans cette version, nous avons inclus deux nouvelles colonnes dans la page du répertoire Dashboards. La date du dernier accès effectue le suivi de la dernière visite du tableau de bord. Modified By suit la date de la dernière modification du tableau de bord et par qui.

Les informations Modifiées par s’affichent également sur la page du tableau de bord elle-même.

Nous espérons que ces nouveaux champs aident les administrateurs de projet à comprendre le niveau d’activité des tableaux de bord afin de prendre une décision éclairée s’ils doivent être supprimés ou non.

Les vues d’analyse sont désormais disponibles

La fonctionnalité Vues Analytics a été dans un état d’aperçu pendant une période prolongée dans notre version hébergée du produit. Avec cette version, nous sommes heureux d’annoncer que cette fonctionnalité est désormais disponible pour toutes les collections de projets.

Dans le volet de navigation, les affichages Analytics ont été déplacés de l’onglet Vue d’ensemble vers l’onglet Tableaux .

Une vue Analytics offre un moyen simplifié de spécifier les critères de filtre d’un rapport Power BI basé sur des données d’analyse. Si vous n’êtes pas familiarisé avec les vues d’analyse, voici une documentation pour vous aider :

• À propos des vues Analytics
• Créer une vue Analytique dans Azure DevOps
• Gérer les vues Analytics
• Créer un rapport Power BI avec une vue Analytique par défaut
• Se connecter à Analytics avec un connecteur de données Power BI

Le widget de demande de tirage pour plusieurs dépôts est désormais disponible

Nous sommes ravis d’annoncer que le widget Demande de tirage pour plusieurs référentiels est disponible dans Azure DevOps Server 2022.1. Avec ce nouveau widget, vous pouvez facilement afficher les demandes de tirage à partir de 10 référentiels différents dans une seule liste rationalisée, ce qui facilite plus que jamais le suivi de vos demandes de tirage.

Ticket de suggestion de communauté

Présentation de la résolution comme terminée dans les graphiques burndown et burnup

Nous comprenons l’importance de refléter avec précision les progrès de l’équipe, y compris les éléments résolus comme terminés dans les graphiques. Avec une option bascule simple, vous pouvez désormais choisir d’afficher les éléments résolus comme terminé, en fournissant une véritable réflexion sur l’état de brûlure de l’équipe. Cette amélioration permet un suivi et une planification plus précis, permettant aux équipes de prendre des décisions éclairées en fonction des progrès réels. Découvrez une transparence améliorée et des insights améliorés avec les graphiques de burndown et de burnup mis à jour dans reporting.

Wiki

Prise en charge des types de diagrammes supplémentaires dans les pages wiki

Nous avons mis à niveau la version des graphiques mermaid utilisés dans les pages wiki vers la version 8.13.9. Avec cette mise à niveau, vous pouvez désormais inclure les diagrammes et visualisations suivants dans vos pages wiki Azure DevOps :

• Organigramme
• Diagrammes de séquence
• Diagrammes de Gantt
• Graphiques en secteurs
• Diagrammes de conditions requises
• Diagrammes d’état
• Parcours utilisateur

Les diagrammes qui sont en mode expérimental, tels que Entity Relationship et Git Graph, ne sont pas inclus. Pour plus d’informations sur les nouvelles fonctionnalités, consultez les notes de publication de la sirène.

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.