Azure Artifacts simplifie l’intégration à d’autres services

Avec cette mise à jour, nous avons facilité l’authentification d’Azure Artifacts auprès d’autres gestionnaires de packages populaires. Trouvez plus d’informations sur l’implémentation réelle ci-dessous.

Fonctionnalités

Azure Boards

• Ajouter le filtre « Élément de travail parent » au tableau des tâches et au backlog de sprint
• Améliorer l’expérience de gestion des erreurs : champs obligatoires sur bogue/tâche

Azure Pipelines

• Préversion des agents de groupe identique
• Ubuntu 20.04 en préversion pour les pool hébergés Azure Pipelines
• Prise en charge des packages GitHub dans les pipelines YAML

Azure Artifacts

• Notifications des sources amont désactivées
• Expressions de licence et licences incorporées
• Tâches d’authentification légères

Azure Boards

Ajouter le filtre « Élément de travail parent » au tableau des tâches et au backlog de sprint

Nous avons ajouté un nouveau filtre à la fois au tableau Sprint et au backlog Sprint. Cela vous permet de filtrer les éléments de backlog au niveau des exigences (première colonne à gauche) par leur parent. Par exemple, dans la capture d’écran ci-dessous, nous avons filtré la vue pour afficher uniquement les récits utilisateur où le parent est « Ma grande fonctionnalité ».

Améliorer l’expérience de gestion des erreurs : champs obligatoires sur bogue/tâche

Historiquement, à partir du tableau Kanban, si vous avez déplacé un élément de travail d’une colonne vers une autre où l’état change les règles de champ déclenchées, l’carte affiche simplement un message d’erreur rouge qui vous oblige à ouvrir l’élément de travail pour comprendre la cause racine. Dans sprint 170, nous avons amélioré l’expérience afin que vous puissiez maintenant cliquer sur le message d’erreur rouge pour afficher les détails de l’erreur sans avoir à ouvrir l’élément de travail lui-même.

Azure Pipelines

Préversion des agents de groupe identique

Nous préversions une nouvelle fonctionnalité appelée agents de groupe identique qui associe la capacité pratique et élastique des agents hébergés par Microsoft avec le contrôle et la flexibilité des agents auto-hébergés. Avec cette préversion, nous vous permettent désormais de gérer les agents à votre spécification, complètement automatisées, dans votre abonnement Azure. Vous pouvez envisager d’utiliser des agents de groupe identique au lieu d’agents hébergés par Microsoft ou auto-hébergés lorsque vous :

• besoin de plus de mémoire, plus de processeur, plus de stockage ou plus d’E/S que ce que nous proposons dans les agents hébergés par Microsoft natifs
• ne souhaitez pas autoriser la liste d’un grand nombre d’adresses IP au sein de votre pare-feu d’entreprise pour permettre aux agents hébergés par Microsoft de communiquer avec vos serveurs
• besoin d’un plus grand nombre d’agents hébergés par Microsoft que nous pouvons fournir pour répondre à vos besoins à grande échelle
• besoin de partitionner des travaux parallèles hébergés par Microsoft pour des projets ou des équipes individuels dans votre organisation
• ne souhaitez pas exécuter d’agents dédiés autour de l’horloge, mais souhaitez plutôt déprovisionner des machines d’agent qui ne sont pas utilisées activement

Pour utiliser des agents de groupe identique, vous allez d’abord créer un groupe de machines virtuelles identiques dans votre abonnement Azure, puis créer un pool d’agents dans Azure Pipelines pour pointer vers ce groupe identique. Azure Pipelines met automatiquement à l’échelle ce pool en fonction du nombre de travaux en attente et du nombre de machines inactives que vous souhaitez conserver à tout moment. Azure Pipelines installe également l’agent pour vous sur ces machines virtuelles. Pour plus d’informations, consultez les agents de groupe identique. Lorsque vous affichez un aperçu de la fonctionnalité, incluez vos commentaires sur la page de documentation.

Ubuntu 20.04 en préversion pour les pool hébergés Azure Pipelines

L’image Ubuntu 20.04 est désormais disponible en préversion pour les pools hébergés Par Azure Pipelines. Pour utiliser cette image, mettez à jour votre fichier YAML pour inclure vmImage : « ubuntu-20.04 ». Notez que l’étiquette d’image ubuntu la plus récente continuera à pointer vers ubuntu-18.04 jusqu’à ce que ubuntu-20.04 sorte de la préversion plus tard cette année.

Notez que l’image ubuntu 20.04 est en préversion, elle ne prend actuellement pas en charge tous les outils disponibles dans ubuntu-18.04. En savoir plus

Prise en charge des packages GitHub dans les pipelines YAML

Nous avons récemment introduit un nouveau type de ressource appelé packages qui ajoute la prise en charge de l’utilisation de packages NuGet et npm à partir de GitHub en tant que ressource dans les pipelines YAML. Dans le cadre de cette ressource, vous pouvez maintenant spécifier le type de package (NuGet ou npm) que vous souhaitez consommer à partir de GitHub. Vous pouvez également activer les déclencheurs de pipeline automatisés lors de la publication d’une nouvelle version de package. Aujourd’hui, la prise en charge est disponible uniquement pour consommer des packages à partir de GitHub, mais nous prévoyons d’étendre la prise en charge pour consommer des packages à partir d’autres référentiels de packages tels que NuGet, npm, AzureArtifacts et bien plus encore. Pour plus d’informations, reportez-vous à l’exemple ci-dessous :

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # GitHub service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Remarque : Les packages GitHub d’aujourd’hui prennent uniquement en charge l’authentification basée sur pat, ce qui signifie que la connexion de service GitHub dans la ressource de package doit être de type PAT. Une fois cette limitation levée, nous allons prendre en charge d’autres types d’authentification.

Par défaut, les packages ne sont pas téléchargés automatiquement dans vos travaux. Par conséquent, nous avons introduit une macro getPackage qui vous permet d’utiliser le package défini dans la ressource. Pour plus d’informations, reportez-vous à l’exemple ci-dessous :

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

Azure Artifacts

Notifications des sources amont désactivées

L’interface web Azure Artifacts vous avertit maintenant quand une ou plusieurs sources amont de votre flux ne fonctionnent pas. Les sources en amont vous permettent de pointer un flux (flux A) vers un autre flux (flux B) et de permettre aux consommateurs de flux A d’accéder aux packages à partir du flux B sans avoir à se connecter directement à celui-ci. Pour plus d’informations sur les sources amont, consultez la documentation Azure Artifacts. Les sources en amont peuvent ne pas fonctionner si elles sont désactivées à la source, par exemple si le flux B est supprimé en mode silencieux, les clients ne pourront pas extraire des packages à partir de celui-ci via le flux A. Dans le passé, cette situation peut se produire sans avertissement et entraîner des problèmes opérationnels difficiles à diagnostiquer, tels que des interruptions de build soudaines en raison de dépendances manquantes (c’est-à-dire des packages provenant du flux B dans l’exemple ci-dessus). À présent, Azure Artifacts vous avertit lorsqu’il existe des problèmes avec les sources amont de vos flux. Lorsqu’un problème existe, vous verrez une bannière (flèche rouge ci-dessous) dans la page de détails du flux Azure Artifacts.

Cliquez sur le lien dans la bannière pour ouvrir une page qui affiche l’état de chaque amont source de votre flux. En plus des informations sur chaque source amont pour le flux actuel, vous pouvez voir l’état actuel sous la colonne « Dernière synchronisation ». Les sources en amont qui fonctionnent correctement affichent une case activée mark verte avec la dernière fois que l’intégrité de la source a été vérifiée. Les sources en amont qui sont rompues affichent un X rouge avec le moment où il a été case activée ed. Les sources en amont qui sont en attente de vérification affichent une icône d’informations bleues.

Lorsque vous cliquez sur la dernière heure de synchronisation d’une source de amont rompue, une boîte de dialogue ouvre le partage de détails sur la cause racine du problème (le cas échéant). Par exemple, dans l’image ci-dessous, la source amont en question ne fonctionne pas, car le flux cible a été supprimé. La boîte de dialogue contient également un lien vers le journal d’audit pour vous aider à comprendre qui a apporté des modifications pertinentes récemment. Les liens vers les paramètres d’autorisations et la documentation Azure Artifacts peuvent également être utilisés pour vous aider à examiner la cause racine.

Expressions de licence et licences incorporées

Vous pouvez maintenant voir les détails des informations de licence pour les packages NuGet stockés dans Azure Artifacts lors de la navigation dans Visual Studio. Cela s’applique aux licences représentées à l’aide d’expressions de licence ou de licences incorporées. Vous pouvez maintenant voir un lien vers les informations de licence dans la page de détails du package Visual Studio (flèche rouge dans l’image ci-dessous).

En cliquant sur le lien, vous accédez à une page web dans laquelle vous pouvez afficher les détails de la licence. Cette expérience est identique pour les expressions de licence et les licences incorporées. Vous pouvez donc voir les détails de licence pour les packages stockés dans Azure Artifacts à un emplacement unique (pour les packages qui spécifient les informations de licence et sont pris en charge par Visual Studio).

Tâches d’authentification légères

Vous pouvez désormais vous authentifier auprès des gestionnaires de packages populaires à partir d’Azure Pipelines à l’aide de tâches d’authentification légères. Cela inclut NuGet, npm, PIP, Twine et Maven. Auparavant, vous pouvez vous authentifier auprès de ces gestionnaires de packages à l’aide de tâches qui ont fourni une grande quantité de fonctionnalités, notamment la possibilité de publier et de télécharger des packages. Toutefois, cela nécessite l’utilisation de ces tâches pour toutes les activités qui interagissent avec les gestionnaires de package. Si vous aviez vos propres scripts à exécuter pour effectuer des tâches telles que la publication ou le téléchargement de packages, vous ne pourrez pas les utiliser dans votre pipeline. À présent, vous pouvez utiliser des scripts de votre propre conception dans votre pipeline YAML et effectuer l’authentification avec ces nouvelles tâches légères. Exemple utilisant npm :

L’utilisation de la commande « ci » et « publish » dans cette illustration est arbitraire, vous pouvez utiliser toutes les commandes prises en charge par Azure Pipelines YAML. Cela vous permet d’avoir un contrôle complet de l’appel de commandes et facilite l’utilisation de scripts partagés dans votre configuration de pipeline. Pour plus d’informations, consultez la documentation de la tâche d’authentification NuGet, npm, PIP, Twine et Maven .

Étapes suivantes

Notes

Ces fonctionnalités seront déployées au cours des deux à trois prochaines semaines.

Accédez à Azure DevOps et jetez un coup d’œil.

accéder à Azure DevOps

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu Aide pour signaler un problème ou faire une suggestion.

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.

Merci,

Aaron Hallberg