Partager via

Notes de publication d’Azure DevOps Server 2022 Update 1

| Communauté des développeurs | Exigences système et compatibilité | Conditions 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 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

Fichier Algorithme de hachage SHA-256
devops2022.1patch4.exe 29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F

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

Fichier Algorithme de hachage SHA-256
devops2022.1patch3.exe E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

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

Fichier Algorithme de hachage SHA-256
devops2022.1patch2.exe 59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

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

Fichier Algorithme de hachage SHA-256
devops2022.1patch1.exe 9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

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

  • Évitez de définir requested for lors de la mise en file d'attente d'un lancement de pipeline.

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

Remarque

Il existe deux problèmes connus avec cette version :

  1. 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. Nous travaillons actuellement sur un correctif pour résoudre ce problème et partagerons les mises à jour dans la Communauté des développeurs à mesure que nous progressons. En attendant, vous trouverez une solution de contournement pour ce problème dans ce ticket de la Communauté des développeurs.
  2. Compatibilité Maven 3.9.x. Maven 3.9.x a introduit des modifications importantes avec Azure Artifacts en mettant à jour le résolveur Maven par défaut en utilisant le protocole HTTP natif depuis Wagon. Cela provoque des problèmes d’authentification 401 pour les clients utilisant http, au lieu de https. Vous trouverez plus d’informations sur ce problème ici. Pour contourner ce problème, vous pouvez continuer à utiliser Maven 3.9.x avec la propriété -Dmaven.resolver.transport=wagon. Ce changement oblige Maven à utiliser Wagon Resolver Transport. Consultez la documentation ici pour plus d’informations.

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.

Remarque

Il existe un problème connu avec la compatibilité Maven 3.9.x. Maven 3.9.x a introduit des modifications importantes avec Azure Artifacts en mettant à jour le résolveur Maven par défaut en utilisant le protocole HTTP natif depuis Wagon. Cela provoque des problèmes d’authentification 401 pour les clients utilisant http, au lieu de https. Vous trouverez plus d’informations sur ce problème ici.

Pour contourner ce problème, vous pouvez continuer à utiliser Maven 3.9.x avec la propriété -Dmaven.resolver.transport=wagon. Ce changement oblige Maven à utiliser Wagon Resolver Transport. Consultez la documentation ici pour plus d’informations.

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.

Remarque

Il existe un problème connu avec la compatibilité Maven 3.9.x. Maven 3.9.x a introduit des modifications importantes avec Azure Artifacts en mettant à jour le résolveur Maven par défaut en utilisant le protocole HTTP natif depuis Wagon. Cela provoque des problèmes d’authentification 401 pour les clients utilisant http, au lieu de https. Vous trouverez plus d’informations sur ce problème ici.

Pour contourner ce problème, vous pouvez continuer à utiliser Maven 3.9.x avec la propriété -Dmaven.resolver.transport=wagon. Ce changement oblige Maven à utiliser Wagon Resolver Transport. Consultez la documentation ici pour plus d’informations.

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 prenaient pas en compte les modifications de nom d'affichage.
  • Une erreur inattendue s'est produite lors du passage de l'onglet Code à un autre onglet sur 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é dans les journaux RAW lors de l'enregistrement conditionnel quand le nom du projet d'équipe ou les fichiers incluaient des caractères 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 quelques-uns des points forts :

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

Généralités

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 y a une table des étendues ici.

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.

Créer des jetons d’accès personnels à déployer sur la Place de marché

Comités

Colonne 'Dernier Accès' sur la page Plans de livraison

La page d'annuaire des plans de livraison 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.

Gif pour faire la démonstration du champ Dernier accès sur la page Plans de livraison.

Visualisez toutes les dépendances dans les plans de livraison

Les plans de livraison ont toujours offert 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 livraison. Cliquez de nouveau dessus pour désactiver les lignes.

Gif pour visualiser toutes les dépendances sur la page Plans de livraison.

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 le nombre maximum de l'équipe des plans de livraison de 15 à 20

Les plans de livraison vous permettent d’afficher plusieurs backlogs et plusieurs équipes dans votre collection de projets. Auparavant, vous pouviez afficher 15 backlogs d'équipes, 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.

Nous avons résolu un bogue dans l'API Get des liens de l'élément de travail dans le rapport pour fournir la valeur correcte de remoteUrl pour les types de liens System.LinkTypes.Remote.Related. 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 consiste à utiliser cette API REST pour les supprimer un à 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 @CurrentIteration pour le style dans Delivery Plans. Cette macro vous permet d’obtenir l’itération actuelle à partir du contexte d’équipe de chaque ligne de votre plan.

Gif pour démonstration de la macro CurrentIteration dans les plans de livraison.

Logique de redimensionnement de carte dans les plans de livraison

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.

Gif pour démontrer comment copier le lien des commentaires.

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 d’être modifié. Lorsque le champ 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.

Gif pour démonstration de la modification des champs de liste de sélection partageables.

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 aux paramètres du projet > configuration du projet > chemin de la zone. Sélectionnez ensuite le chemin d’accès de zone de votre choix, puis cliquez sur Sécurité.

Chemin d’accès à la zone

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.

Nouvelle autorisation

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.

Modification de démonstration des champs de liste de sélection partageables.

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 l’ancien diagramme de flux cumulé, la vitesse et les graphiques Sprint Burndown. Avec cette version, nous les mettons à disposition.

Pour afficher ces graphiques, cliquez sur l’emplacement de l’onglet Analytique dans les pages Kanban Board, Backlog et Sprints.

Rapports interactifs

Dépôts

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.

Image de gestion des autorisations.

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.

Canalisations

Le projet actuel est défini comme l’étendue par défaut pour le jeton d’accès de compilation 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 au 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 la documentation sur les référentiels, les artefacts et d’autres ressources d’accessibilité.

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

Pour renforcer la sécurité des pipelines de build classiques, lors de la création d’un nouveau pipeline, l’étendue d’autorisation du job de build sera 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 emplois. 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 maintenant.

Prise en charge d’Azure Pipelines pour les versions 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 sur site pour exécuter des builds d’intégration continue et de pull request. 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 le pull request
  • Rapport sur l’état de la compilation

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.

nouvelle connexion de service de registre Docker pour le changement des approbations

Remarque

L’identité managée utilisée pour accéder à Azure Container Registry devra disposer de l’attribution appropriée de Contrôle d’accès basé sur les rôles Azure (RBAC), par exemple le rôle AcrPull ou AcrPush.

Jetons automatiques créés pour la connexion Kubernetes Service

Depuis la version Kubernetes 1.24, les jetons ne sont plus créés automatiquement lors de la création d'une nouvelle connexion de service Kubernetes. 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 d’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

Découvrez les améliorations des autorisations de pipeline

Nous avons amélioré l’expérience de gestion des autorisations de pipeline pour rappeler le système d’autorisations si un pipeline avait précédemment utilisé une ressource protégée, telle qu’une connexion de service.

Dans le passé, si vous avez désactivé « Accorder l’autorisation d’accès à tous les pipelines » lorsque vous avez créé une ressource protégée, mais que vous avez restreint l’accès à la ressource, votre pipeline a 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 désormais résolu.

Nouveaux champs PAT pour gérer les autorisations, approbations et contrôles des pipelines

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.

Capture d’écran montrant les mises à jour de l’API REST pipelines.

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

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 si vous n'avez pas suffisamment de droits, l'option Accorder l'accès à toutes les pipelines est désactivée.

Connexions de service En outre, lorsque vous essayez d’ouvrir l’accès à une ressource existante et que vous n’avez pas suffisamment de droits, vous obtenez un message vous n’êtes pas autorisé à ouvrir l’accès pour ce message de ressource.

Autorisations des pipelines

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 pleinement délimités. 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 à Azure DevOps pour éliminer la nécessité de jetons avec une portée complète en incorporant chaque API REST dans une portée 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 complètement défini. 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 granulaires 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 pouvaient y accéder était sommaire. 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.

Pool d’agents FabrikamFiber pour les modifications des approbations

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 la case Accorder l’autorisation d’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.

L’autorisation d’accès à tous les pipelines est par défaut désactivé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 des secrets, des variables provenant de groupes de variables liés à Azure Key Vault ou des éléments d’une connexion de service marquée comme secrète par le fournisseur de connexions de service.

Toutes les occurrences de la valeur secrète sont masquées. Masquage de secrets courts, par exemple «1 »,2 « », «Dev » permet de deviner facilement leurs valeurs, par exemple dans une date : «Jan 3, 202*** »
Il est maintenant clair que c’est3 un secret. Dans ce cas, vous pouvez préférer ne pas masquer le secret complètement. 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 du gestionnaire de nœuds

Lors de l’adoption de versions d’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épendant des exécuteurs Node arrivés en fin de vie ; consultez l'article de blog.

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. Consultez le billet de blog pour obtenir des conseils sur Node runner, car TFX a été mis à jour pour effectuer des validations sur les versions de Node runner.

Les extensions qui contiennent des tâches à l’aide de 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 pipeline- flux de l'agent, le Nœud 6 n'est pas 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 propriété progressPreference des tâches PowerShell@2 et AzurePowerShell@5 est désormais définie sur 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 ajoute la prise en charge native d'Apple Silicon et de 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.

Important

N’oubliez pas que les agents s’exécutant sur l’un des systèmes d’exploitation ci-dessus ne seront plus mis à jour ou échouent une fois que nous avons déployée l’agent .NET 6.

Spécifier la version de l’agent dans l’extension de la VM

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",
        ...
      },
      ...
     }

Nouveaux interrupteurs 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 de s’exécuter et vous pourrez les modifier, mais il ne sera pas possible d'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 de s’exécuter et vous pourrez les modifier, mais il ne sera pas possible d'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 commutateurs se trouvent dans Project / Project Settings -> Pipelines -> Settings. Il existe deux bascules : une pour les pipelines de build classiques et une pour les pipelines de livraison classiques, les groupes de déploiement et les groupes de tâches.

Désactiver la création de pipelines classiques

L’état des commutateurs est à l'arrêt par défaut, et vous aurez besoin de droits d’administrateur pour modifier l’état. Si le commutateur est activé au niveau de l’organisation, la désactivation est imposé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 déclenchement de service « Changement d'état de l'étape d'exécution »

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 de modification de l'état de l'étape de l'exécution 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 du processus. Avec cette mise à jour, nous avons apporté des modifications à l’événement pour inclure des informations manquantes.

Hook de service pour le changement d’état du travail

Les hooks de service vous permettent de réagir en réponse aux événements liés aux modifications d’état dans vos exécutions de pipeline. Jusqu’à présent, vous pouviez configurer des hooks de service pour les changements d’état d’exécution et d’étape du pipeline.

Dès maintenant, vous pouvez configurer des hooks de service qui se déclenchent lorsque l’état d’une tâche dans votre exécution de pipeline change. La structure de charge utile du nouvel événement est illustrée dans l’exemple suivant.

{
    "subscriptionId": "8d91ad83-1db5-4d43-8c5a-9bb2239644b1",
    "notificationId": 29,
    "id": "fcad4962-f3a6-4fbf-9653-2058c304503f",
    "eventType": "ms.vss-pipelines.job-state-changed-event",
    "publisherId": "pipelines",
    "message":
    {
        "text": "Run 20221121.5 stage Build job Compile succeeded.",
        "html": "Run 20221121.5 stage Build job <a href=\"https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088\">Compile</a> succeeded.",
        "markdown": "Run 20221121.5 stage Build job [Compile](https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088) succeeded."
    },
    "detailedMessage":
    {
        "text": "Run 20221121.5 stage Build job Compile succeeded.",
        "html": "Run 20221121.5 stage Build job <a href=\"https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088\">Compile</a> succeeded.",
        "markdown": "Run 20221121.5 stage Build job [Compile](https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088) succeeded."
    },
    "resource":
    {
        "job":
        {
            "_links":
            {
                "web":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088"
                },
                "pipeline.web":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/definition?definitionId=4647"
                }
            },
            "id": "e87e3d16-29b0-5003-7d86-82b704b96244",
            "name": "Compile",
            "state": "completed",
            "result": "succeeded",
            "startTime": "2022-11-21T16:10:28.49Z",
            "finishTime": "2022-11-21T16:10:53.66Z"
        },
        "stage": { ... },
        "run": { ... },
        "pipeline": { ... },
        "repositories": [ ... ]
    },
    "resourceVersion": "5.1-preview.1",
    "createdDate": "2022-11-21T16:11:02.9207334Z"
}

Les événements de raccordement de service de modification d’état d’exécution, d’étape et de travail contiennent désormais une repository propriété qui répertorie les dépôts Azure consommés par l’exécution du pipeline. Par exemple:

"repositories":
[
    {
        "type": "Git",
        "change":
        {
            "author":
            {
                "name": "Fabrikam John",
                "email": "john@fabrikamfiber.com",
                "date": "2022-11-11T15:09:21Z"
            },
            "committer":
            {
                "name": "Fabrikam John",
                "email": "john@fabrikamfiber.com",
                "date": "2022-11-11T15:09:21Z"
            },
            "message": "Added Viva support"
        },
        "url": "https://fabrikamfiber@dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_git/fabrikamfiber"
    }
]

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

Auparavant, l'interface utilisateur des pipelines affichait le dernier message de validation lors de l'exécution d'un pipeline.

Exemple de dernier message de validation

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 pris en compte vos retours de la Communauté des développeurs qui nous demande un moyen pour activer ou désactiver l’ajout du dernier message de commit 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 définissez false, l’exécution du pipeline n’affiche que BuildNumber.

Exemple d’exécution de pipeline avec numéro de build

Exemple d’exécution de pipeline avec dernier message de validation

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 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, ce qui permet de résoudre les contraintes de taille lors de l’intégration de modèles volumineux.

Icône de vue d'ensemble du statut d'exécution du pipeline

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 connaître l’état d’une exécution de pipeline, autrement dit, s’il est toujours en cours d’exécution ou 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 icône de vue d’ensemble de l’état d’exécution.

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

Panneau latéral des étapes du 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 à ses logs directement.

Mettre à jour Pipelines

Mises à jour de l’interface utilisateur des pipelines

Rechercher des étapes dans le volet latéral

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

Mettre à jour les pipelines AZ

Actions rapides d’étape

L’écran des exécutions d’un pipeline vous permet d’accéder rapidement à toutes les phases 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.

Capture d’écran du pipeline avec trop d’étapes. Lorsque vous cliquez sur le signe « + » dans la colonne des étapes, le panneau des étapes s’affiche, et vous pouvez alors effectuer des actions relatives aux étapes.

Capture d’écran du volet étapes.

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, il était difficile de savoir qu'un chèque avait fourni des informations aussi critiques.

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

Image montrant le dernier journal de vérification. Pour éviter les approbations incorrectement validées, Azure DevOps affiche les instructions pour les approbateurs dans le volet latéral des approbations et contrôles sur la page de détails d'une exécution de pipeline.

En attente de l’image de révision du pipeline.

Désactiver une vérification

Nous avons rendu les 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 le contrôle corrigé, vous deviez l’ajouter à nouveau et le configurer correctement, en vous assurant que soit tous les en-têtes requis sont définis, soit 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 suivantes de l'ensemble de vérification.

Désactivez une image de vérification. Une fois que vous avez corrigé la vérification erronée, vous pouvez simplement l’activer.

Activez une image de vérification.

Ressources consommées et paramètres de modèle dans l'API REST des exécutions de pipelines

L’API REST étendue des exécutions de pipelines renvoie désormais plus de types d’artefacts utilisés par une exécution de pipeline et les paramètres de déclenchement. 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.

Mises à jour de l’API REST pipelines

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.DefinitionFolderPathFabrikamFiber\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, tels que le parcours 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 une chaîne et effectuer une itération sur each de 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é le support des expressions de modèle pour définir la propriété ref d'une ressource repository 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. De plus, supposons que votre pipeline utilise la même branche de bibliothèque que celle qu'il utilise lui-même. Par exemple, si votre pipeline s’exécute sur la branche main, il doit extraire la branche main du référentiel de la 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 etd’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 signifiait que vous deviez modifier le code du pipeline si vous vouliez que votre pipeline : étendre un modèle depuis une autre branche étendre un modèle ayant le même nom de branche que votre pipeline, quelle que soit la branche depuis laquelle vous avez exécuté 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 fichier template.yml de la branche dev du référentiel templates.

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 propriété ref d’une ressource de référentiel, vous pouvez utiliser les variables prédéfinies de parameters et du système, mais vous ne pouvez pas utiliser les variables définies par l’interface utilisateur YAML ou Pipelines.

Expressions de gabarit dans la définition des ressources de conteneur

Nous avons ajouté la prise en charge des expressions de modèle lors de la définition des propriétés endpoint, volumes, ports et options d’une ressource container 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 constructions planifiées

Nous avons résolu un problème qui entraînait l’endommagement des informations de planification d’un pipeline et empêchait son chargement. 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 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 de paiement synchronise les balises même lorsque vous activez l’option d’extraction superficielle, ce qui peut compromettre 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.

Ce comportement peut être contrôlé à partir du fichier YAML ou de l’interface utilisateur.

Pour désactiver la synchronisation des balises via le fichier YAML, ajoutez fetchTags: false à l'étape de validation. Lorsque l’option fetchTags n’est pas spécifiée, elle est la même que si fetchTags: true elle est utilisée.

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

Si vous souhaitez modifier le comportement des pipelines YAML existants, il peut être plus pratique de définir cette option dans l’interface utilisateur au lieu de mettre à jour le fichier YAML. Pour accéder à l’interface utilisateur, ouvrez l’éditeur YAML du pipeline, sélectionnez Déclencheurs, puis Traiter, puis l’étape De validation.

Si vous spécifiez ce paramètre à la fois dans le fichier YAML et dans l’interface utilisateur, la valeur spécifiée dans le fichier YAML est prioritaire.

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.

Artéfacts

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.

Auparavant, vous pouviez voir les packages en amont si vous aviez une copie du flux. Le problème principal était que vous ne pouviez pas rechercher les paquets disponibles en amont et qui ne sont pas encore stocké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.

Rapports

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.

Créer des jetons d’accès personnels à déployer sur la Place de marché

Copier le tableau de bord

Avec cette version, nous incluons Copy Dashboard.

Image avec le tableau de bord de copie

Tableaux de bord date de dernière consultation et modifié par

L’un des défis liés à l’autorisation des é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 dernière date d’accès effectue le suivi du moment où le tableau de bord a été visité le plus récemment. Modifié par indique quand le tableau de bord a été modifié pour la dernière fois et par qui.

Les informations modifiées par seront également affichées sur la page du tableau de bord elle-même.

Aperçu du tableau de bord

Nous espérons que ces nouveaux champs aident les administrateurs de projet à comprendre le niveau d’activité des tableaux de bord pour 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 vues Analytics sont déplacées de l’onglet Vue d’ensemble vers l’onglet Tableaux .

vue analytique dans la navigation des tableaux.

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

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 jusqu’à 10 référentiels différents dans une liste simple et simplifiée, ce qui facilite le suivi de vos demandes de tirage.

Widget de référentiel multiple en disponibilité générale

Ticket de suggestion de la communauté

Présentation des tâches résolues comme complétées dans les diagrammes de baisse et d'augmentation

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 simple option de bascule, vous pouvez désormais choisir d'afficher les éléments résolus comme complétés, offrant une véritable réflexion sur l'état d'avancement 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 de meilleurs aperçus avec les graphiques de burndown et de burnup mis à jour dans Reporting.

Gif pour la démonstration résolue comme terminée dans les graphiques burn-down et burn-up.

Site collaboratif 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 :

  • Diagramme de flux
  • Diagrammes de séquences
  • 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 Mermaid.

Commentaires

Nous aimerions connaître votre opinion ! 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.

Haut de page