Notes de publication Azure DevOps Server 2022 Update 1

  • Article

| | Developer Community System Requirements and Compatibility | License Terms | DevOps Blog | SHA-256 Hashes |

Dans cet article, vous trouverez des informations sur la dernière version pour Azure DevOps Server.

Pour en savoir plus sur l’installation ou la mise à niveau d’un déploiement de Azure DevOps Server, consultez Azure DevOps Server Configuration requise.

Pour télécharger Azure DevOps Server produits, visitez la page Téléchargements Azure DevOps Server.

La mise à niveau directe vers Azure DevOps Server 2022 Update 1 est prise en charge à partir de Azure DevOps Server 2019 ou de Team Foundation Server 2015 ou version ultérieure. Si votre déploiement TFS est sur TFS 2013 ou une version antérieure, vous devez effectuer certaines étapes intermédiaires avant de procéder à la mise à niveau vers Azure DevOps Server 2022. Pour plus d’informations, consultez la page Installer .

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

Fichier Hachage SHA-256
devops2022.1patch3.exe E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

Nous avons publié le correctif 3 pour Azure DevOps Server 2022 Update 1 qui inclut les correctifs suivants.

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

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

Fichier Hachage SHA-256
devops2022.1patch2.exe 59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

Nous avons publié le correctif 2 pour Azure DevOps Server mise à jour 2022 1 qui inclut les correctifs suivants.

  • Résolution du problème de rendu de la page des détails sur l’extension de recherche.
  • Correction d’un bogue dans lequel l’espace disque utilisé par le dossier de cache proxy n’était pas calculé correctement et le dossier n’était pas correctement nettoyé.
  • CVE-2024-20667 : Azure DevOps Server vulnérabilité d’exécution de code à distance.

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

Fichier Hachage SHA-256
devops2022.1patch1.exe 9D0FDCCD1F20461E58689B756E600CC16424018A3377042F7DC3A6EEF096FB6

Nous avons publié le correctif 1 pour Azure DevOps Server 2022 Update 1 qui inclut les correctifs suivants.

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

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

Notes

Cette version présente deux problèmes connus :

  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 le Developer Community à mesure que nous progressons. En attendant, vous trouverez une solution de contournement pour ce problème dans ce ticket Developer Community.
  2. Compatibilité Maven 3.9.x. Maven 3.9.x a introduit des modifications cassants avec Azure Artifacts en mettant à jour le transport Maven Resolver par défaut vers http natif à partir de Wagon. Cela entraîne des problèmes d’authentification 401 pour les clients qui utilisent 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 force 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. Il inclut toutes les fonctionnalités du Azure DevOps Server 2022.1 RC2 précédemment publié.

Notes

Il existe un problème connu avec la compatibilité maven 3.9.x. Maven 3.9.x a introduit des modifications cassants avec Azure Artifacts en mettant à jour le transport Maven Resolver par défaut vers http natif à partir de Wagon. Cela entraîne des problèmes d’authentification 401 pour les clients qui utilisent 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 force Maven à utiliser Wagon Resolver Transport. Consultez la documentation ici pour plus d’informations.

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

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

Notes

Il existe un problème connu avec la compatibilité maven 3.9.x. Maven 3.9.x a introduit des modifications cassants avec Azure Artifacts en mettant à jour le transport Maven Resolver par défaut vers http natif à partir de Wagon. Cela entraîne des problèmes d’authentification 401 pour les clients qui utilisent 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 force 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 amont ne résolvaient pas les changements de nom d’affichage.
  • Une erreur inattendue s’est produite lors du basculement d’onglets de Code vers un autre onglet de la page 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 s’affichait sur le journal RAW sur les case activée fermées lorsque le nom du projet d’équipe ou les fichiers incluaient CJK.
  • Correction d’un problème lors de l’installation de la recherche où la machine virtuelle Java (JVM) ne pouvait pas 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 à tout environnement Java Runtime Environment (JRE) préinstallé sur le serveur ciblé.

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

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

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

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) ce qui a 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 de portée complète augmente le risque lorsqu’ils peuvent atterrir entre les mains d’un utilisateur malveillant. C’est l’une des main raisons pour lesquelles bon nombre de nos clients n’ont pas pleinement tiré parti des stratégies de plan de contrôle pour restreindre 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 se trouvent dans la section Sécurité des pages de documentation. En outre, il existe une table des étendues ici.

Les extensions doivent afficher leurs étendues

Lorsque vous installez des extensions sur 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 doivent 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 à examiner et à prendre une décision éclairée sur leur conservation ou non.

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

Boards

Colonne Last Accessed (Dernier accès) dans la page Plans de livraison

La page d’annuaire Plans de livraison fournit la liste des plans définis pour votre projet. Vous pouvez trier par : Nom, Créé par, Description, Dernier configuré ou Favoris. Avec cette mise à jour, nous avons ajouté une colonne Dernier accès à la page du répertoire. Cela permet d’avoir une visibilité sur la date de la dernière ouverture et de la dernière fois qu’un plan de livraison a été examiné. Par conséquent, il est facile d’identifier les plans qui ne sont plus utilisés et qui peuvent être supprimés.

Gif vers le champ de démonstration Dernier accès sur la page Plans de livraison.

Visualiser toutes les dépendances sur les plans de livraison

Les plans de livraison 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 dépendances en haut à droite de votre plan de livraison. Cliquez à nouveau dessus pour désactiver les lignes.

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

Limites de révision des nouveaux éléments de travail

Au cours des dernières années, nous avons vu des collections 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 de convivialité 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 dans le service Azure DevOps. La limite affecte uniquement les mises à jour à l’aide de l’API REST, et non le 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 d’é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’équipe, y compris une combinaison de backlogs et d’équipes 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 d’élément de travail de création de rapports pour retourner la valeur remoteUrl correcte pour System.LinkTypes.Remote.Related les types de liens. Avant ce correctif, nous renvoyions un 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 tenter 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 la chaîne de requête élimine ce problème.

Pour en savoir plus, consultez la page de documentation sur 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 par un. Il peut s’agir d’un processus lent et soumis à une limitation de débit lorsque vous essayez d’effectuer n’importe quel type de masse propre. 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 lot.

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

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 pour le suivi des fonctionnalités et des épopées. Certains choisissent d’utiliser une combinaison de dates et de chemin d’itération. Dans cette version, nous avons amélioré la logique pour définir de manière appropriée le chemin d’itération et les combinaisons de champs de date en fonction de la façon dont elles sont utilisées.

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.

Lien GIF vers les commentaires de copie de démonstration.

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

Nous avons apporté plusieurs modifications à la version 7.1 de l’API de mise à jour par lot 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 sont terminés avec succè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 autorisons les administrateurs de processus à ajouter ou 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 « bloquer » la modification d’un champ. 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.

Modification gif pour la démonstration des champs de liste de choix partageables.

Autorisation Nouvel enregistrement des commentaires

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

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

Pour ce faire, vous devez accéder à Paramètres > du projet Chemin de la zone de configuration > du projet. Sélectionnez ensuite le chemin de zone de votre choix, puis cliquez sur Sécurité.

Chemin de 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 Non défini. Cela signifie que l’élément de travail se comportera exactement comme avant. Pour autoriser un ou plusieurs utilisateurs à enregistrer des commentaires, sélectionnez ce groupe/ces utilisateurs et modifiez l’autorisation sur Autoriser.

Nouvelle autorisation

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

Modification de démonstration des champs de liste de choix partageables.

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

Rapports de tableaux interactifs

Les rapports interactifs, situés dans le hub Boards, sont 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. Avec cette version, nous les mettons à disposition.

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

Rapports interactifs

Repos

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

Auparavant, lorsque vous avez créé une nouvelle branche, nous vous avons l’autorisation de modifier les 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.

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 de travail 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 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, artefacts et autres ressources Access.

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. Elle n’impacte que les nouveaux pipelines de build classiques que vous créez à partir de ce point.

Prise en charge d’Azure Pipelines pour Les versions de ServiceNow à San Diego, Tokyo & Utah

Azure Pipelines a 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 & 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 de proxy pour l’intégration de GitHub Enterprise

Azure Pipelines s’intègre aux serveurs GitHub Enterprise Server locaux pour exécuter l’intégration continue et les builds de demande de tirage. Dans certains cas, GitHub Enterprise Server se trouve derrière un pare-feu et nécessite que le trafic soit routé 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, tout le trafic d’Azure DevOps n’était pas routé via cette URL de proxy. Avec cette mise à jour, nous nous assurons que nous acheminons le trafic suivant à partir d’Azure Pipelines pour passer par l’URL du proxy :

  • Obtenir des branches
  • Obtenir des informations de demande de tirage
  • 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 au 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 au service Docker Registry pour les modifications apportées aux approbations

Notes

L’identité managée utilisée pour accéder à Azure Container Registry a besoin de l’attribution de Access Control en fonction du rôle (RBAC) Azure appropriée, par exemple le rôle AcrPull ou AcrPush.

Jetons automatiques créés pour la connexion Kubernetes Service

Depuis Kubernetes 1.24, les jetons n’étaient plus créés automatiquement lors de la création d’une connexion Kubernetes Service. Nous avons rajouté cette fonctionnalité. Toutefois, il est recommandé d’utiliser la connexion de service Azure lors de l’accès à AKS. Pour en savoir plus, consultez le billet de blog Conseils sur la connexion de service pour les clients AKS utilisant 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-le en insérant la tâche KubeloginInstaller@0 avant la tâche qui en dépend :

 - 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 coactiviez « 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 nécessaire. 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.

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 de ressources protégées aux administrateurs de ressources

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

Par exemple, un rôle Administrateur de service Connections général est requis pour autoriser n’importe quel pipeline à 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, lorsque vous créez une connexion de service et que vous ne disposez pas de droits suffisants, l’option Accorder l’autorisation d’accès à tous les pipelines est désactivée.

Service Connections En outre, lorsque vous tentez d’ouvrir l’accès à une ressource existante et que vous ne disposez pas de droits suffisants, vous obtenez un message Vous n’êtes pas autorisé à ouvrir l’accès pour cette ressource.

Autorisations de pipelines

Améliorations apportées à la sécurité de l’API REST des pipelines

La majorité des API REST dans Azure DevOps utilisent des jetons PAT étendus. Toutefois, certains d’entre eux nécessitent des jetons PAT entièrement étendus. En d’autres termes, vous devez créer un jeton PAT en sélectionnant « Accès complet » pour utiliser certaines de ces API. Ces jetons posent 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 permettant de 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 de 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 Autorisations de pipeline - Mettre à jour les autorisations de pipeline pour les ressources .

Gestion de l’accès affinée 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 pouvant y accéder était grossière. Vous pouvez autoriser tous les pipelines à l’utiliser, ou vous pouvez exiger chaque demande d’autorisation de pipeline. Malheureusement, une fois que vous avez accordé une autorisation d’accès de pipeline à un pool d’agents, vous ne pouvez pas le révoquer à l’aide de l’interface utilisateur des pipelines.

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

Pool d’agents FabrikamFiber pour les modifications apportées aux approbations

Empêcher l’octroi à tous les pipelines de 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 cocher la case Accorder l’autorisation d’accès à tous les pipelines . Jusqu’à présent, cette option était activé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 à un trop grand nombre de pipelines du droit d’accéder à la ressource.

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

Accorder l’autorisation d’accès à tous les pipelines est désactivé par défaut

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 secrets par le fournisseur de connexion de service.

Toutes les occurrences de valeur de secret sont masquées. Le masquage des secrets courts, par exemple « », «2 », «Dev » permet de deviner facilement leurs valeurs, par exemple dans une date : «Jan 3, 202*** »1
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 d’agentpipeline-, 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 Microsoft API Graph

Nous avons mis à jour nos tâches de publication pour utiliser microsoft API Graph. Cela supprime l’utilisation de l’API Graph AAD 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 un script PowerShell afin de 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 désormais 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 et AzurePowerShell@5 est désormais définie SilentlyContinue sur 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 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 abandonnons 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 du logiciel 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 exécutés sur l’un des systèmes d’exploitation ci-dessus ne seront plus mis à jour ou échoueront une fois l’agent .NET 6 mis à jour.

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

Les machines virtuelles Azure peuvent être incluses dans des 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 organization 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 se trouvent dans Project/Project Settings -> Pipelines -> Settings. Il existe deux bascules : l’une pour les pipelines de build classiques et l’autre pour les pipelines de mise en production classiques, les groupes de déploiement et les groupes de tâches.

Désactiver la création de pipelines classiques

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 organization, la désactivation est appliquée pour tous les projets. Sinon, chaque projet est libre de choisir d’appliquer ou non la désactivation.

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

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

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 Run stage state changed doit contenir des informations sur l’exécution, y compris le nom du pipeline. Auparavant, il contenait 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 les informations manquantes.

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

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

Exemple de message de dernière validation

Ce message peut prêter à confusion, par exemple, lorsque le code de votre pipeline YAML réside dans un dépôt différent de celui qui contient le code qu’il est en cours de création. Nous avons entendu vos commentaires du Developer Community 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 le définissez sur false, l’exécution du pipeline affiche uniquement le BuildNumber.

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

Exemple d’exécution de pipeline avec le message de dernière validation

Augmentation des limites 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 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 vous permet de connaître plus facilement la status globale d’une exécution de pipeline.

Pour les pipelines YAML qui ont de nombreuses phases, il était auparavant difficile de connaître la status d’une exécution de pipeline, c’est-à-dire si elle est toujours en cours d’exécution ou terminée. Et s’il s’est terminé, 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.

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

Panneau latéral des phases de pipeline

Les pipelines YAML peuvent comporter des dizaines d’étapes, et elles ne tiennent pas toutes sur 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 phase 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.

Mettre à jour les pipelines

Mises à jour de l’interface utilisateur des pipelines

Rechercher des phases 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 phases en fonction de leur status, 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.

Mettre à jour les pipelines AZ

Actions rapides de mise en scène

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 de phases à partir duquel vous pouvez effectuer des actions pour chaque étape. Par exemple, vous pouvez facilement réexécuter des travaux ayant échoué ou réexécuter toute la phase. Le panneau est disponible lorsque toutes les étapes ne tiennent pas dans 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 phases, le panneau étapes s’affiche, puis vous pouvez effectuer des actions de phase.

Capture d’écran du panneau des étapes.

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

Nous rendons la lecture des journaux de vérification plus facile. Vérifie que les journaux 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 si vous devez mettre à jour un ticket dans ServiceNow. Auparavant, il était difficile de savoir qu’un case activée fournissait de telles informations critiques.

À présent, la page des détails de l’exécution du pipeline affiche la dernière case activée journal. Il s’agit uniquement des vérifications qui suivent notre utilisation recommandée.

Image montrant le journal case activée le plus récent. Pour empêcher les approbations approuvées par erreur, Azure DevOps affiche les Instructions pour les approbateurs dans le volet Approbations et vérifications latérales dans la page de détails d’une exécution de pipeline.

Image en attente de révision de pipeline.

Désactiver un case activée

Nous avons rendu les vérifications de débogage moins fastidieuses. Parfois, une case activée Invoke Azure Function ou Invoke REST API ne fonctionne pas correctement et vous devez la corriger. Auparavant, vous deviez supprimer ces vérifications pour éviter qu’elles bloquent par erreur un déploiement. Une fois que vous avez corrigé le case activée, vous devez le rajouter et le 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 un case activée. Le case activée désactivé ne s’exécutera pas dans les évaluations de suite case activée suivantes.

Désactivez une image case activée. Une fois que vous avez corrigé le case activée erroné, vous pouvez simplement l’activer.

Activez une image case activée.

Ressources consommées et paramètres de modèle dans l’API REST Exécutions de pipelines

L’API REST d’exécutions de pipelines étendues retourne désormais d’autres 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 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 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 constituent également un mécanisme puissant pour vérifier ou appliquer la sécurité et la gouvernance via votre pipeline.

Azure Pipelines prend en charge un éditeur YAML, qui peut être utile lors de la modification de votre pipeline. Toutefois, l’éditeur ne prenait pas en charge les modèles jusqu’à présent. Les auteurs de pipelines YAML n’ont pas pu obtenir d’aide 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 main, 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 classiques.

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

Ajout de 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, comme le bouclage each de la valeur d’une liste ou d’une propriété d’un objet.

Parfois, l’ensemble d’éléments à parcourir est représenté sous la forme d’une chaîne. Par exemple, lorsque la liste d’environnements dans lequel effectuer le déploiement est définie par la chaîne integration1, integration2.

À mesure que nous avons écouté vos commentaires du Developer Community, nous avons entendu que vous souhaitiez 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 de dépôt

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é très demandée par notre Developer Community.

Il existe des cas d’usage où vous souhaitez que votre pipeline case activée 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 dépôt et, pour cela, il doit case activée une bibliothèque à partir d’un référentiel de ressources. En outre, supposons que vous souhaitez que votre pipeline case activée la même branche de bibliothèque que celle utilisée par elle-même. Par exemple, si votre pipeline s’exécute sur la main branche, il doit case activée la main branche du dépôt de bibliothèque. Si les pipelines s’exécutent sur la dev branche, il doit case activée la branche de bibliothèquedev.

Jusqu’à aujourd’hui, vous deviez spécifier explicitement la branche à case activée 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 dépôt. Consultez l’exemple suivant de code YAML à utiliser pour les branches non main 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 à case activée pour le library dépôt.

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

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 courant 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 dépôt lors de l’utilisation du dépôt comme source de modèle. Cela signifiait que vous deviez modifier le code du pipeline si vous souhaitez que votre pipeline : étendre un modèle à partir d’une autre branche étendre un modèle à partir du même nom de branche que votre pipeline, quelle que soit la branche sur laquelle vous avez exécuté votre pipeline

Avec l’introduction d’expressions de modèle dans la définition de ressource de dépôt, 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

Ce faisant, votre pipeline étend le modèle dans la même branche que la branche sur laquelle le pipeline s’exécute, de sorte que vous pouvez vous assurer que les branches de votre pipeline et celles 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 dépôt.

Vous pouvez également choisir, au moment de la file d’attente de génération, la branche de dépôt de modèle à 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 faire en sorte que votre pipeline sur la branche main étende un modèle à partir d’une branche dev dans une exécution et étende 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 parameters et des variables prédéfinies système, 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 endpointdéfinition des propriétés , volumes, portset options d’une container ressource dans un pipeline YAML. Il s’agissait d’une fonctionnalité très demandée par notre Developer Community.

À 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 pouvez utiliser uniquement celles définies dans le fichier YAML, mais pas celles définies dans l’interface utilisateur des pipelines. Si vous redéfinissez la variable, par exemple à l’aide des commandes de journal de l’agent, cela n’aura aucun effet.

Améliorations apportées aux builds planifiées

Nous avons résolu un problème qui entraînait l’endommagement des informations de planification d’un pipeline et le non-chargement du pipeline. Cela s’est produit, par exemple, lorsque le nom de la branche a dépassé un certain nombre de caractères.

Message d’erreur amélioré en cas d’échec du chargement des pipelines

Azure Pipelines fournit plusieurs types de déclencheurs pour configurer le démarrage de votre pipeline. L’une des façons 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 était introuvable. Avec cette mise à jour, nous avons résolu ce problème et renvoyons un message d’erreur informatif. À l’avenir, vous recevez le message semblable à : Les données de planification de génération sont endommagées si un pipeline ne parvient pas à se charger.

Ne pas synchroniser les balises lors de l’extraction d’un dépôt Git

La tâche de validation utilise l’option --tags pour extraire le contenu d’un dépôt Git. Le serveur récupère alors toutes les étiquettes ainsi que de tous les objets désignés par ces étiquettes. Cela augmente le temps d’exécution de la tâche dans un pipeline, en particulier si vous disposez d’un dépôt volumineux avec un certain nombre de balises. En outre, la tâche d’extraction synchronise les balises même lorsque vous activez l’option d’extraction superficielle, ce qui peut aller à l’échec de son objectif. Pour réduire la quantité de données extraites ou extraites d’un dépôt Git, nous avons maintenant ajouté une nouvelle option à la tâche pour contrôler le comportement de synchronisation des balises. 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 à l’étape fetchTags: false de validation. Lorsque l’option fetchTags n’est pas spécifiée, elle est identique à celle fetchTags: true 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 pour le pipeline, sélectionnez Déclencheurs, puis Traiter, puis l’étape Extraction.

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 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 seront 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 collection de projets auront 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 amont packages si vous disposiez d’une copie du flux. Le point problématique était que vous ne pouviez pas rechercher les packages disponibles dans le amont et qui ne sont pas encore enregistrés dans le flux. À présent, vous pouvez rechercher les packages 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 amont et d’enregistrer les versions des 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 copier le tableau de bord.

Image avec copie du tableau de bord

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 Tableaux de bord. Date de la dernière consultation permet de suivre le moment où le tableau de bord a été visité le plus récemment. Modified By suit le moment 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.

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 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 analytiques a été dans un état de préversion 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 la navigation, les affichages Analytics ont été déplacés 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 des données Analytics. Si vous n’êtes pas familiarisé avec les vues d’analyse, voici une documentation pour vous faire prendre en compte :

Le widget 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 dépôts est disponible dans Azure DevOps Server 2022.1. Avec ce nouveau widget, vous pouvez facilement afficher les demandes de tirage à partir de jusqu’à 10 dépôts différents dans une seule liste rationalisée, ce qui facilite plus que jamais le suivi de vos demandes de tirage.

Widget de plusieurs référentiels en disponibilité générale

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 tels qu’ils sont terminés dans les graphiques. Avec une option bascule simple, vous pouvez désormais choisir d’afficher les éléments résolus comme terminés, ce qui fournit une véritable réflexion de l’état de burndown de l’équipe. Cette amélioration permet un suivi et une planification plus précis, ce qui permet aux équipes de prendre des décisions éclairées en fonction des progrès réels. Profitez d’une transparence améliorée et de meilleures insights avec les graphiques de burndown et de burnup mis à jour dans Reporting.

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

Wiki

Prise en charge d’autres types de diagrammes 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 des exigences
  • 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 mermaid.

Commentaires

Nous aimerions connaître votre opinion ! Vous pouvez signaler un problème ou fournir une idée et le suivre dans Developer Community et obtenir des conseils sur Stack Overflow.

Haut de la page