Package amont sources et serveur de symboles en disponibilité générale – VSTS Sprint 130 Update

Dans sprint 130 Update of Visual Studio Team Services (VSTS), nous continuons d’améliorer notre intégration avec les outils et services qui vous aident à établir un pipeline DevOps complet. Gérez les packages à partir de sources amont pour prendre le contrôle de vos dépendances et utiliser VSTS comme serveur de symboles pour simplifier le débogage. Vous pouvez également intégrer des éléments de travail dans votre conversation d’équipe avec l’extension de messagerie VSTS pour Microsoft Teams.

Parmi les autres points clés :

• Mentionner un groupe dans les discussions d’élément de travail et de demande de tirage
• Publier automatiquement à partir de Azure Container Registry et de Docker Hub et uniquement certaines branches de builds à partir de GitHub
• Tirez parti de ce que vous pouvez avoir dans Jenkins avec un contrôle et une efficacité plus finsà l’aide du Stockage Azure
• Gérer l’accès et les extensions pour un grand nombre d’utilisateurs à l’aide de groupes

Nouveautés de VSTS

Code

Récupérer un dépôt supprimé récemment via une API

Parfois, des erreurs peuvent se produire durant le nettoyage d’anciens dépôts dans le contrôle de code source. Si un dépôt Git a été supprimé au cours des 30 derniers jours, vous pouvez le récupérer via l’API REST. Pour plus d’informations, consultez la documentation relative aux opérations list et recover.

Travail

Discuter des éléments de travail dans Microsoft Teams à l’aide de l’extension de messagerie VSTS

Microsoft Teams est devenu la plaque tournante du travail d’équipe au sein de nombreuses équipes d’ingénierie. Nous avons étendu notre intégration à Microsoft Teams avec la nouvelle extension de messagerie VSTS pour vous permettre de rechercher et de discuter d’éléments de travail spécifiques en même temps que vos autres contenus et outils. Pour plus d’informations, consultez l’extension d’intégration Microsoft Teams sur la Place de marché.

Mentionner un groupe dans les discussions d’élément de travail et de demande de tirage

Lorsque les discussions sur les éléments de travail ou les demandes de tirage incluent plusieurs personnes(ou tous les membres d’une équipe particulière), il faut du temps à @mention tous ceux que vous souhaitez notifier. Maintenant, vous pouvez simplement @mention une équipe ou un groupe de sécurité dans les discussions. Si vous êtes membre d’un groupe mentionné dans un élément de travail ou une demande de tirage, vous recevrez une notification par e-mail. Si vous êtes membre d’un groupe mentionné dans un élément de travail, cet élément de travail s’affiche également dans votre tableau croisé dynamique Mentionné dans le hub Éléments de travail .

Build et mise en production

Utiliser VSTS comme serveur de symboles

Le serveur de symboles VSTS, qui vous permet d’héberger et de partager des symboles avec votre organization, est désormais en disponibilité générale. Les symboles fournissent des informations supplémentaires qui facilitent le débogage des exécutables, en particulier ceux écrits dans des langages natifs comme C et C++. Pour plus d’informations, consultez la documentation relative à la publication de symboles pour le débogage .

Cette fonctionnalité a été hiérarchisée en fonction d’une suggestion de haut niveau.

Filtrer les branches pour les artefacts GitHub

Maintenant, vous pouvez également configurer des filtres de branche pour les dépôts GitHub. Par exemple, vous pouvez déployer uniquement des builds provenant de la branche master/*.

Filtrer les branches à l’aide de l’inclusion et de l’exclusion

Jusqu’à présent, vous avez pu spécifier des branches et des balises qui doivent déclencher une mise en production. Nous avons reçu des commentaires clairs indiquant que cela était limité et nécessitait des mises à jour fréquentes des définitions de mise en production. Comme dans Build, vous pouvez maintenant spécifier des branches qui ne doivent pas déclencher une mise en production. Par exemple, vous pouvez déclencher une mise en production pour toutes les branches dev/* mais pas pour la branche dev/featureX .

Créer automatiquement une mise en production à partir d’Azure Container Registry et de Docker Hub

Quand vous déployez des applications conteneurisées, l’image conteneur est d’abord envoyée (push) à un registre de conteneurs. Une fois l’envoi (push) effectué, l’image conteneur peut être déployée sur un cluster Web App pour conteneurs ou Kubernetes. Vous pouvez désormais activer la création automatique de mises en production pour les mises à jour d’images stockées dans Docker Hub ou Azure Container Registry en les ajoutant en tant que sources d’artefact.

Propager des artefacts Jenkins vers Stockage Azure

Les artefacts générés par les builds Jenkins sont généralement propagés vers des référentiels de stockage à des fins d’archivage et de partage. Le stockage blob Azure est l’un des dépôts pris en charge pour les artefacts créés par une build Jenkins. Vous pouvez désormais utiliser des projets Jenkins qui publient sur le stockage Azure en tant que sources d’artefacts dans une définition de mise en production.

Les détails du stockage blob Azure où les artefacts sont publiés sont requis lors de l’ajout des artefacts à une définition. Les déploiements téléchargent ensuite automatiquement les artefacts à partir d’Azure vers les agents. Avec cette configuration, l’agent peut être déconnecté du serveur Jenkins. Les agents hébergés peuvent être utilisés sans exposer le serveur à Internet.

Spécifier une version par défaut pour les artefacts Jenkins

Quand une mise en production comportant plusieurs artefacts se déclenche automatiquement, les versions par défaut enregistrées dans la définition de mise en production sont récupérées pour tous les artefacts. Auparavant, les artefacts Jenkins n’avaient pas de paramètre de version par défaut. Par conséquent, vous ne pouviez pas définir un déclencheur de déploiement continu sur une mise en production en utilisant Jenkins comme artefact secondaire.

Désormais, vous pouvez spécifier une version par défaut pour les artefacts Jenkins, avec les options que vous connaissez :

• Dernière
• Spécifier au moment de la création de la mise en production
• Version spécifique

Limiter la portée d’un groupe de variables à des environnements spécifiques

Jusqu’à maintenant, quand un groupe de variables était ajouté à une définition de mise en production, les variables qu’il contenait étaient disponibles pour tous les environnements de la mise en production. Désormais, vous pouvez limiter les groupes de variables à des environnements spécifiques, ce qui les rend disponibles pour un environnement mais pas pour d’autres dans la même mise en production. Il s’agit d’une fonctionnalité très utile quand vous avez un service externe, par exemple un service de messagerie SMTP, qui diffère d’un environnement à l’autre.

Installer des tâches à partir de la Place de marché directement à partir de la définition de build ou de mise en production

La recherche d’une tâche dans l’éditeur de définition de build ou de mise en production répertorie désormais les extensions de tâche pertinentes de la Place de marché en plus de celles déjà installées ou intégrées. Vous pouvez acquérir l’extension en cliquant sur Obtenir gratuitement et en terminant le flux de travail dans la Place de marché. Une fois que vous avez la nouvelle tâche, actualisez simplement la liste des tâches sur l’éditeur de définition pour voir les tâches nouvellement installées, prêtes à être ajoutées à votre définition.

Package

Utiliser sans interruption des packages publics à l’aide de sources amont

Les sources en amont pour les nuget.org et les npmjs.com sont désormais en disponibilité générale. Elles vous permettent notamment de gérer (retirer de la liste, déprécier, annuler la publication, supprimer, etc.) les packages enregistrés à partir de sources amont, ainsi que de garantir l’enregistrement de chaque package amont utilisé.

Pour l’instant, ces avantages s’appliquent uniquement aux flux créés après cette annonce, sauf si vous avez précédemment activé le bouton bascule amont sources en préversion dans votre panneau Fonctionnalités d’aperçu. Si vous avez activé le bouton bascule en préversion, tout flux créé après avoir activé le bouton bascule peut utiliser ces avantages. Dans une mise à jour ultérieure, vous pourrez mettre à niveau des flux plus anciens pour tirer parti de ces améliorations.

Voir la qualité d’une version de package dans la liste des packages

Dans la liste des packages, vous pouvez désormais consulter les vues de chaque version de package pour déterminer rapidement leur qualité. Consultez la documentation sur les vues de mise en production

Lier des packages depuis n’importe quel emplacement

Bien que vous puissiez partager l’URL d’un package trouvé dans le hub Packages, il était souvent difficile de le faire, car vous deviez inclure dans l’URL un projet qui ne s’appliquait pas toujours aux utilisateurs du lien. Avec cette mise à jour, vous pouvez désormais partager des packages à l’aide d’une URL au niveau du compte qui sélectionnera automatiquement un projet auquel le destinataire a accès. Le format de l’URL est : https://<account>.visualstudio.com/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|npm|Maven>&_a=package. Tous les paramètres à l’exception de <account> sont facultatifs, mais si vous spécifiez un package, vous devez indiquer le type du protocole.

Partager vos packages à l’aide d’un badge

Dans la communauté open source, il est courant d’utiliser un badge lié à la dernière version de votre package dans le fichier README de votre dépôt. Avec cette mise à jour, vous pouvez maintenant créer des badges pour les packages dans vos flux VSTS. Il vous suffit de case activée l’option Activer les badges de package dans les paramètres de flux, sélectionnez un package, puis cliquez sur Créer un badge. Vous pouvez copier l’URL du badge directement, ou copier le Markdown prégénéré qui lie le badge à la page des détails de votre package.

Recycler et restaurer les packages

La suppression des packages inutilisés peut contribuer au nettoyage de la liste des packages. Toutefois, elle peut être effectuée par erreur. Vous pouvez désormais restaurer les packages supprimés à partir de la Corbeille. Les packages supprimés sont conservés dans la Corbeille pendant 30 jours, ce qui vous laisse amplement le temps de les restaurer en cas de besoin.

Administration

Gérer l’accès et les extensions pour un grand nombre d’utilisateurs à l’aide de groupes

Nous avons facilité la gestion de grands groupes d’utilisateurs par les administrateurs en vous permettant d’attribuer des niveaux d’accès et des extensions à des groupes Azure AAD ou VSTS. Après avoir configuré les règles appropriées, l’ajout d’une personne au groupe lui accordera automatiquement les niveaux d’accès et les extensions appropriés lorsqu’elle accède au compte VSTS. Par conséquent, les niveaux d’accès et les extensions n’auront plus besoin d’être gérés individuellement.

Pour plus d’informations, consultez la feuille de route de gestion des utilisateurs des grands comptes sur le blog Microsoft DevOps de l’année dernière et la documentation Affecter des niveaux d’accès et des extensions aux utilisateurs par appartenance à un groupe .

Latence réduite pour les modifications d’appartenance aux groupes Azure AAD

Si vous gérez les autorisations via des appartenances de groupe Azure Active Directory (Azure AD), les modifications d’appartenance à Azure AAD dans le passé peuvent avoir pris 24 à 48 heures pour être reconnues par VSTS. Cette latence est désormais inférieure à 1 heure, ce qui vous permet d’accélérer l’exécution des nouveaux membres de l’équipe.

Gérer les utilisateurs avec les API REST Graph (préversion publique)

Les ressources de l’API REST Graph permettent aux développeurs d’écrire des applications qui gèrent les utilisateurs, les groupes et les appartenances aux groupes. L’ensemble d’API couvre les principaux scénarios de gestion des utilisateurs, notamment l’ajout d’un compte Microsoft (MSA) ou d’un utilisateur Azure Active Directory (Azure AD) à VSTS, la création d’un groupe VSTS et l’ajout/suppression de membres d’un groupe VSTS. Pour plus d’informations, consultez la documentation et les exemples de l’API REST Graph.

Quitter le compte

Auparavant, seuls les propriétaires ou administrateurs de comptes pouvaient supprimer des utilisateurs d’un compte. Vous pouvez maintenant laisser un compte dans lequel vous n’êtes plus impliqué seul. Pour quitter un compte, accédez à votre page de profil et recherchez le compte que vous souhaitez laisser dans votre liste de comptes. Sous la section Actions du compte, il existe désormais une option permettant de quitter le compte. Cette fonctionnalité a été rendue prioritaire à la suite d’une suggestion.

Étapes suivantes et commentaires

Accéder à VSTS

S’abonner à Mises à jour

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Signalez un problème ou fournissez une suggestion si vous avez des idées sur les éléments que vous souhaitez nous voir hiérarchiser, via le menu de commentaires.

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

Merci,

Henry Dixon et Aaron Bjork