Notes de publication de Team Foundation Server 2018 Update 2

---

Developer Community | Configuration requise et compatibilité | Termes du contrat de licence | Blog TFS DevOps | Codes de hachage SHA-1 | | Dernières notes de publication Visual Studio 2019

---

Remarque

Si vous accédez à cette page à partir d’une version autre que la version anglaise et que vous voulez voir le contenu le plus à jour, visitez cette page de notes de publication en anglais. Vous pouvez modifier la langue de cette page en cliquant sur l’icône en forme de globe dans le pied de page, puis en sélectionnant la langue de votre choix.

---

Dans cet article, vous trouverez des informations sur la dernière version de Team Foundation Server 2018. Cliquez sur le bouton pour télécharger.

Pour en savoir plus sur Team Foundation Server 2018, consultez la page Configuration requise et compatibilité de Team Foundation Server. Visitez la page visualstudio.com/downloads pour télécharger d’autres produits TFS 2018.

La mise à niveau directe vers Team Foundation Server 2018 Update 2 est prise en charge à partir de TFS 2012. Si votre déploiement TFS est sur TFS 2010 ou antérieur, vous devez effectuer certaines étapes intermédiaires avant la mise à niveau vers TFS 2018 Update 2. Pour plus d’informations, consultez le graphique ci-dessous et la page d’installation TFS.

Tableau de mise à niveau TFS

Important

Vous n’avez pas besoin d’effectuer une mise à niveau vers TFS 2018 RTM avant une mise à niveau vers TFS 2018 Update 2.

---

Date de publication : 7 mai 2018

Vous pouvez maintenant effectuer une mise à niveau vers TFS 2018 Update 2 et continuer à connecter vos contrôleurs XAML et exécuter vos builds XAML. Lorsque nous avons supprimé la prise en charge de Build XAML dans TFS 2018 RTW et Update 1, certains d’entre vous n’ont pas pu effectuer la mise à niveau en raison de la présence de builds XAML héritées. Nous souhaitons régler le problème. Même si TFS 2018 Update 2 prend en charge les builds XAML de vos builds héritées, Build XAML est dépréciée et ne fera plus l’objet d’investissement, c’est pourquoi nous vous recommandons vivement de procéder à une conversion dans un format de définition de build plus récent.

Récapitulatif des nouveautés de TFS 2018 Update 2

Nous avons ajouté un grand nombre de nouvelles fonctionnalités à Team Foundation Server 2018 Update 2. Voici les principales :

• Afficher une validation de fusion de demande de tirage (pull request)
• Aider les réviseurs à utiliser les étiquettes de demande de tirage (pull request)
• Mentionner une demande de tirage (pull request)
• Les notifications de commentaires de demande de tirage (pull request) incluent le contexte de thread
• Extensibilité de l’état des demandes de tirage (pull requests)
• Filtre d’étiquettes et de champs personnalisés dans les notifications de suivi d’éléments de travail
• Options de colonne modernisées
• Ajout de la prise en charge de l’opérateur de requête Pas dans
• Query for @MyRecentActivity and @RecentMentions
• Filtrage des plans
• Portes de mise en production
• Builds avec intégration continue à partir de GitHub Enterprise
• Améliorations apportées aux builds multiphases
• Ignorer les builds planifiées si rien n’a changé dans le dépôt
• Utiliser sans interruption des packages publics à l’aide de sources amont
• Stratégies de rétention dans les flux TFS
• Filtrage dans la gestion des packages
• Recherches dans le Wiki
• Référencer des éléments de travail dans le Wiki
• Afficher l’aperçu du contenu quand vous modifiez des pages de Wiki
• Coller du contenu Wiki enrichi au format HTML
• Cartes de visite
• Avatars arrondis

---

Détails des nouveautés de TFS 2018 Update 2

Vous pouvez trouver des informations sur les fonctionnalités dans chaque zone :

• Code
• Travail
• Générer et publier
• Package
• Test
• Wiki
• Général

Code

Obtenir un lien permanent vers le code

Quand vous consultez un fichier, vous voyez généralement sa version à l’extrémité de la branche sélectionnée. La version d’un fichier à l’extrémité d’une branche peut changer au fil des nouvelles validations. Si vous copiez un lien à partir de cet affichage, il risque de se périmer, car l’URL inclut uniquement le nom de la branche, et non l’algorithme SHA de validation. Vous pouvez désormais changer facilement l’affichage Fichiers pour mettre à jour l’URL et faire référence à la validation au lieu de la branche. Si vous appuyez sur la touche « y », votre affichage passe à la validation de l’extrémité de la branche actuelle. Vous pouvez ensuite copier des liens permanents.

Récupérer un dépôt supprimé récemment via une l’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 est 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.

SSH : prendre en charge les chiffrements/clés supplémentaires et déprécier les chiffrements obsolètes

Pour améliorer la sécurité et la compatibilité, nous avons mis à jour la liste des chiffrements pris en charge pour le protocole SSH. Nous avons ajouté deux nouveaux chiffrements et nous en avons déprécié trois, conformément à la directive OpenSSH. Les chiffrements dépréciés continuent de fonctionner dans cette version. Ils seront supprimés plus tard quand leur utilisation diminuera.

Ajout :

• AES128 CTR
• AES256 CTR

Dépréciation :

• AES128
• AES192
• AES256

Éviter les remplacements et protéger le niveau de performance à l’aide des paramètres de dépôt

Dans cette mise à jour, vous trouverez deux nouveaux paramètres de dépôt pour permettre à Git de fonctionner correctement.

Application de la casse fait passer le serveur du mode par défaut avec respect de la casse, où « Fichier.txt » et « fichier.txt » référencent le même fichier, à un mode compatible avec Windows et macOS, où « Fichier.txt » et « fichier.txt » représentent le même fichier. Ce paramètre affecte les fichiers, les dossiers, les branches et les étiquettes. Il empêche également les contributeurs d’introduire accidentellement des différences au niveau de la casse uniquement. L’activation de l’application de la casse est recommandée quand la plupart de vos contributeurs exécutent Windows ou macOS.

Limiter les tailles de fichiers vous permet d’éviter que les fichiers nouveaux ou mis à jour ne dépassent la limite de taille définie. Plus le nombre de grands fichiers est important dans l’historique d’un dépôt Git, plus le niveau de performance des opérations de clonage et de récupération (fetch) est faible. Ce paramètre empêche l’introduction accidentelle de ces fichiers.

Amélioration de la fonctionnalité de filtrage pour les validations comportant plus de 1 000 fichiers ayant changé

La recherche d’un fichier dans les validations ou les demandes de tirage (pull requests) qui comportaient plus de 1 000 fichiers était inefficace ; vous deviez cliquer sur le lien Charger plus à plusieurs reprises pour trouver le fichier souhaité. Désormais, quand vous filtrez du contenu dans l’arborescence, la recherche du fichier est effectuée parmi tous les fichiers de la validation, et non simplement dans les 1 000 premiers fichiers chargés. Les performances de la page des détails de la validation sont également améliorées en cas de modification de plus de 1 000 fichiers.

Trouver les validations perdues à la suite d’un envoi (push) forcé

Vous pouvez forcer un envoi (push) Git et mettre à jour une référence distante, même s’il ne s’agit pas d’un ancêtre de la référence locale. Cela peut entraîner la perte des validations d’autres utilisateurs et rendre très difficile l’identification de la cause racine. Dans la nouvelle vue des envois, nous avons fait en sorte que les envois forcés soient plus visibles pour faciliter la résolution des problèmes liés aux validations manquantes.

Si vous cliquez sur l’étiquette de l’envoi forcé, vous accédez à la validation supprimée.

Historique des responsabilités

La vue Rendre responsable est idéale pour identifier la dernière personne à avoir modifié une ligne de code. Toutefois, vous avez parfois besoin de savoir qui a effectué le changement précédent dans une ligne de code. La dernière amélioration apportée à la fonctionnalité d’identification des responsabilités peut s’avérer utile - Afficher le responsable avant d’effectuer cette validation. Comme son nom l’indique, cette fonctionnalité vous permet de remonter dans le temps jusqu’à la version du fichier qui précède la version où une ligne particulière a été changée. Ainsi, vous pouvez afficher les informations de responsabilité relatives à cette version. Vous pouvez continuer à remonter dans le temps en consultant chaque version du fichier où la ligne de code sélectionnée a été changée.

Activer/désactiver le retour automatique à la ligne et l’espace blanc dans les affichages de différences

Deux nouvelles fonctionnalités sont disponibles dans la visionneuse des différences de fichiers : Activer/Désactiver le retour automatique à la ligne et Activer/désactiver l’espace blanc. La première permet d’appliquer le paramètre de retour automatique à la ligne dans un affichage de différences. C’est particulièrement utile pour examiner les demandes de tirage qui contiennent des fichiers sans sauts de ligne fréquents, par exemple les fichiers Markdown. L’option qui permet de d’activer/de désactiver les espaces blancs est utile quand seuls les espaces blancs ont changé dans une ligne ou un fichier. Le fait d’activer/désactiver ce paramètre entraîne l’affichage et la mise en surbrillance des caractères d’espace (des points pour les espaces, des flèches pour les tabulations, etc.) dans l’affichage des différences.

Pour gérer ces paramètres, cliquez sur l’engrenage des préférences de l’éditeur de demandes de tirage ou dans la vue des différences. Dans l’affichage Fichiers, dans le menu contextuel, sélectionnez l’option Préférences utilisateur.

Sélectionnez les différentes fonctionnalités de l’éditeur, notamment Afficher et différencier les espaces blancs, Activer le retour automatique à la ligne, Activer le pliage de code et Afficher la minicarte.

Le pliage de code (appelé « mode Plan » dans certains éditeurs) est également activé pour l’affichage web. Quand le pliage de code est activé, cliquez sur les signes moins pour réduire les sections de code, et cliquez sur les signes plus pour développer les sections réduites. La palette de commandes F1 expose également des options permettant d’effectuer des pliages selon divers niveaux de retrait dans un fichier entier, ce qui facilite la lecture et le passage en revue des fichiers volumineux.

Effectuer le suivi des Push de code vers un dépôt Git pour les builds et les mises en production

Désormais, vous pouvez afficher l’état des builds et des mises en production des validations de fusion dans la page Envois (push). En cliquant sur l’état en regard de l’envoi (push), vous accédez à la build ou la mise en production spécifique dont l’envoi fait partie, ce qui vous permet de vérifier la réussite de l’opération ou de rechercher les causes de son échec.

Rendu Markdown dans les notifications par e-mail

Markdown est idéal pour ajouter une mise en forme enrichie, des liens et des images aux descriptions et aux commentaires des demandes de tirage (pull requests). Les notifications par e-mail des demandes de tirage affichent désormais le rendu Markdown à la place du contenu brut, ce qui améliore la lisibilité.

Les images incorporées ne font pas encore l’objet d’un rendu inline (elles sont affichées seulement sous forme de liens), mais nous avons ajouté ce point à notre backlog.

Exécuter des commandes TFVC directement à partir de l’Explorateur Windows

L’extension d’interpréteur de commandes Windows de TFVC, qui introduit une expérience utilisateur allégée de la gestion de versions dans l’Explorateur de fichiers Windows, prend désormais en charge TFS 2018. Cet outil fournit un accès pratique à de nombreuses commandes TFVC directement depuis le menu contextuel de l’Explorateur Windows.

Intégré auparavant à Team Foundation Server Power Tools, l’outil a été publié en tant qu’outil autonome sur Visual Studio Marketplace.

Contrôle pouvant contribuer aux demandes de tirage

Avant, toute personne pouvant voir un dépôt Git pouvait utiliser ses demandes de tirage. Nous avons ajouté une nouvelle autorisation appelée Contribuer aux demandes de tirage (pull requests). Elle permet de contrôler l’accès à la création et au commentaire des demandes de tirage. Tous les utilisateurs et groupes qui avaient auparavant l’autorisation Lire reçoivent également cette nouvelle autorisation par défaut. L’introduction de cette nouvelle autorisation donne plus de flexibilité et de contrôle aux administrateurs. Si vous souhaitez que le groupe Lecteurs dispose uniquement d’un accès en lecture seule, vous pouvez lui refuser l’autorisation Contribuer aux demandes de tirage (pull requests).

Pour plus d’informations, consultez la documentation du Guide de démarrage rapide sur la définition d’autorisations d’accès au dépôt.

Les notifications de commentaires de demande de tirage incluent le contexte de thread

Bien souvent, les réponses aux commentaires de demande de tirage sont assez brèves. Elles indiquent simplement qu’un changement va être ou a été fait. Ceci ne pose pas de problème quand vous consultez ces commentaires dans la vue web. Cependant, si vous lisez un commentaire dans une notification par e-mail, le contexte du commentaire d’origine est perdu. Un simple « Je vais corriger » n’a pas de sens.

Désormais, chaque fois qu’une réponse est faite à un commentaire de demande de tirage, les e-mails de commentaires incluent les réponses précédentes dans le corps de l’e-mail. Cela permet aux participants du fil de discussion de voir le contexte complet du commentaire depuis leur boîte de réception, sans avoir à ouvrir la vue web.

Paramètres de complétion des éléments de travail

La fonctionnalité qui permet la complétion des éléments de travail au moment de la complétion des demandes de tirage comporte désormais un nouveau paramètre de dépôt pour contrôler le comportement par défaut. Le nouveau paramètre Mémoriser les préférences de l’utilisateur pour l’exécution des éléments de travail avec demandes de tirage (Pull requests) est activé par défaut. Il conserve le dernier état de l’utilisateur pour l’exécution des futures demandes de tirage dans le dépôt. Si le nouveau paramètre est désactivé, l’option Exécuter les éléments de travail liés après la fusion est désactivée par défaut pour toutes les demandes de tirage du dépôt. Les utilisateurs peuvent toujours choisir de changer l’état des éléments de travail liés au moment de l’exécution des demandes de tirage, mais ils doivent le spécifier explicitement à chaque fois.

Extensibilité de l’état des demandes de tirage

L’utilisation de stratégies de branche peut être un excellent moyen d’améliorer la qualité de votre code. Toutefois, ces stratégies sont limitées aux intégrations fournies nativement par TFS. En utilisant la nouvelle API d’état des demandes de tirage et la stratégie de branche correspondante, les services de tiers peuvent participer au workflow des demandes de tirage comme s’il s’agissait de fonctionnalités TFS natives.

Quand un service appelle l’API d’état pour une demande de tirage, elle apparaît immédiatement dans la vue Détails de la demande de tirage (pull request) dans une nouvelle section État. La section État affiche la description et crée un lien vers l’URL fournie par le service. Les entrées d’état prennent également en charge un menu d’actions (...), qui est extensible pour les nouvelles actions ajoutées via des extensions web.

L’état à lui seul ne bloque pas l’achèvement d’une demande de tirage : c’est là qu’intervient la stratégie. Une fois que l’état de la demande de tirage a été publié, une stratégie peut alors être configurée. Dans l’expérience des stratégies de branche, une nouvelle stratégie est disponible pour Exiger l’approbation de services externes. Sélectionnez + Ajouter un service pour commencer le processus.

Dans la boîte de dialogue, sélectionnez le service qui publie l’état dans la liste, puis sélectionnez les options de stratégie souhaitées.

Une fois que la stratégie est active, l’état est affiché dans la section Stratégies sous Obligatoire ou Facultatif selon le cas, et l’achèvement de la demande de tirage est appliqué de façon appropriée.

Pour en savoir plus sur l’API d’état et pour l’essayer par vous-même, consultez la documentation et les exemples.

Événements de fusion de crochets de services de demande de tirage

Les extensions utilisant des crochets de services de demande de tirage comportent désormais plus de détails et d’options de filtrage pour les événements de fusion. Chaque fois qu’une fusion est tentée, l’événement est déclenché indépendamment de la réussite ou de l’échec de la fusion. En cas d’échec d’une tentative de fusion, les détails relatifs à l’échec sont inclus.

Messages d’erreur améliorés pour les éléments de travail qui s’effectuent avec une demande de tirage

Quand vous tentez d’effectuer les éléments de travail liés à une demande de tirage, il est possible que l’élément de travail associé ne puisse pas passer à l’état terminé. Par exemple, un champ spécifique obligatoire peut nécessiter une entrée de l’utilisateur pour permettre un changement d’état. Nous avons amélioré l’expérience utilisateur pour que vous soyez informé en cas de blocage du changement d’état d’un élément de travail. Cela vous permet de prendre les mesures appropriées pour effectuer les changements nécessaires.

Mentionner une demande de tirage

Vous pouvez désormais mentionner des demandes de tirage dans les commentaires de demande de tirage et les discussions relatives aux éléments de travail. La mention d’une demande de tirage est similaire à celle d’un élément de travail, à ceci près qu’elle implique l’utilisation d’un point d’exclamation ! au lieu du signe dièse #.

Chaque fois que vous voulez mentionner une demande de tirage, entrez un !. Vous avez alors accès à une expérience utilisateur interactive qui vous permet de choisir une demande de tirage dans la liste des demandes de tirage récentes. Entrez des mots clés pour filtrer la liste des suggestions, ou entrez l’ID de la demande de tirage à mentionner. Une fois qu’une demande de tirage est mentionnée, elle fait l’objet d’un rendu inline avec l’ID et le titre complet, et elle est liée à la page des détails de demande de tirage.

Aider les réviseurs à utiliser les étiquettes de demande de tirage (pull request)

Parfois, il est important de communiquer des informations supplémentaires sur une demande de tirage aux réviseurs. Il est possible que la demande de tirage corresponde à un travail encore en cours d’exécution, ou qu’il s’agisse du correctif logiciel d’une prochaine version (vous ajoutez donc un texte supplémentaire dans le titre, par exemple « [TEC] » ou « NE PAS FUSIONNER »). Les étiquettes permettent désormais d’associer aux demandes de tirage des informations supplémentaires qui peuvent être utilisées pour communiquer des détails importants et faciliter la gestion des demandes de tirage.

Les commentaires de demande de tirage suivent les fichiers renommés

Parfois, des fichiers sont renommés ou déplacés quand une demande de tirage est active. S’il existait des commentaires pour les fichiers renommés, la dernière vue du code n’indiquait pas ces commentaires. Nous avons amélioré le suivi des commentaires en les associant aux renommages, ce qui vous permet d’afficher les commentaires de la dernière version des fichiers renommés ou déplacés.

Afficher une validation de fusion de demande de tirage (pull request)

Les vues des différences de demandes de tirage sont très utiles pour mettre en évidence les changements introduits dans la branche source. Toutefois, les changements apportés à la branche cible peuvent entraîner une variation inattendue de l’affichage des différences. Une nouvelle commande permet désormais de voir les différences de l’« aperçu » de la validation de fusion pour la demande de tirage - Afficher la validation de fusion. Cette validation de fusion permet de rechercher les conflits de fusion pour une build de demande de tirage. Elle reflète le résultat de la validation de fusion, une fois la complétion de la demande de tirage effectuée. Quand la branche cible présente des changements qui ne sont pas reflétés dans la recherche des différences, la différenciation de la validation de fusion permet de voir les derniers changements dans les branches source et cible.

Il existe une autre commande pratique quand elle est utilisée avec la commande Afficher la validation de fusion : il s’agit de la commande Redémarrer la fusion (disponible dans le même menu de commandes). Si la branche cible a changé depuis la création de la demande de tirage, l’exécution de cette commande permet de créer un aperçu de la validation de fusion, ce qui entraîne la mise à jour de la vue des différences de validation de fusion.

Réviseurs récemment utilisés

Si votre code est fréquemment revu par les mêmes personnes, il vous sera plus facile que jamais d’ajouter des réviseurs. Quand vous ajoutez des réviseurs à vos demandes de tirage, une liste des réviseurs ajoutés récemment s’affiche automatiquement au moment où vous placez le focus dans la zone de saisie des réviseurs. Il est inutile d’effectuer une recherche par le nom. Sélectionnez-les, tout simplement.

Afficher les critères de stratégie restants pour la complétion automatique d’une demande de tirage

La complétion automatique est une fonctionnalité utile pour les équipes qui utilisent les stratégies de branche. Toutefois, avec les stratégies facultatives, il est parfois difficile de savoir exactement ce qui bloque la complétion d’une demande de tirage. Désormais, quand vous définissez la complétion automatique d’une demande de tirage, la liste exacte des critères de stratégie qui bloquent la complétion est clairement indiquée dans la zone de légende. Au fur et à mesure que chaque exigence est satisfaite, les éléments sont supprimés de la liste jusqu’à ce qu’il ne reste plus d’exigences et que la demande de tirage soit fusionnée.

Discuter calcul dans les demandes de tirage

Vous avez besoin d’inclure une équation ou une expression mathématique dans vos commentaires de demande de tirage ? Vous pouvez désormais inclure des fonctions KaTeX dans vos commentaires, à l’aide des fonctionnalités de commentaire inline et en bloc. Pour plus d’informations, consultez la liste des fonctions prises en charge.

Suggestions de demande de tirage pour les duplications (forks)

Chaque fois qu’une branche de rubrique est mise à jour dans un dépôt, une « suggestion » de création de demande de tirage s’affiche pour la branche de rubrique concernée. Ceci est très utile pour créer des demandes de tirage. Nous avons donc également activé cette fonctionnalité pour tous ceux qui utilisent un dépôt faisant l’objet d’une duplication. Si vous mettez à jour une branche dans une duplication (fork), la prochaine fois que vous visitez le hub Code pour la duplication ou le dépôt amont, vous voyez s’afficher une suggestion de création de demande de tirage. Si vous sélectionnez le lien « Create a pull request », vous êtes redirigé vers l’expérience utilisateur de création de demande de tirage, où les branches et les dépôts sources et cibles sont présélectionnés.

Filtres de chemin pour les stratégies de demande de tirage

Bien souvent, un même dépôt contient du code généré par plusieurs pipelines d’intégration continue (CI) pour valider la build et exécuter les tests. La stratégie de build intégrée prend désormais en charge une option de filtrage de chemin, qui facilite la configuration de plusieurs builds de demande de tirage pouvant être demandées et déclenchées automatiquement à chaque demande de tirage. Spécifiez simplement un chemin pour chaque build afin de définir les options relatives au déclencheur et aux exigences.

En plus de la définition de build, les stratégies d’état proposent également une option de filtrage de chemin. Ceci permet à toutes les stratégies personnalisées ou de tiers de configurer l’application de la stratégie pour des chemins spécifiques.

Travailler

Raccourcis clavier dans le formulaire d’élément de travail

Assignez-vous un élément de travail (Alt+I), passez à la discussion (Ctrl+Alt+D) et copiez un lien rapide vers l’élément de travail (Maj+Alt+C) à l’aide des raccourcis clavier. Pour obtenir la liste complète des nouveaux raccourcis, tapez « ? » dans un formulaire d’élément de travail ouvert, ou consultez le tableau ci-dessous.

Options de colonne modernisées

La boîte de dialogue Options de colonne utilisée pour configurer les colonnes de la grille d’éléments de travail dans les hubs Backlog, Requêtes et Test a été mise à jour, et comporte un nouveau panneau. Recherchez un champ, effectuez des opérations de glisser-déplacer pour réorganiser les colonnes, ou supprimez les colonnes dont vous n’avez plus besoin.

Informations sur l’auteur de la dernière exécution d’une requête

À mesure que l’arborescence Requêtes partagées de votre projet s’accroît, il peut s’avérer difficile de déterminer si une requête n’est plus utilisée et si elle peut être supprimée. Pour vous aider à gérer vos Requêtes partagées, nous avons ajouté deux nouvelles métadonnées à nos API REST de requête, l’auteur de la dernière exécution et la date de la dernière exécution. Ainsi, vous pouvez écrire des scripts de nettoyage pour supprimer les requêtes périmées.

Balises HTML supprimées dans les grilles d’éléments de travail

En fonction des commentaires client, nous avons mis à jour le comportement des champs de texte multilignes au sein des affichages des résultats de requête d’élément de travail dans le web, dans Excel et dans l’IDE Visual Studio pour supprimer la mise en forme HTML. Quand vous ajoutez à la requête des champs de texte multilignes en tant que colonnes, ils s’affichent désormais en texte brut. Voici un exemple de fonctionnalité avec du contenu HTML dans la description.

Avant, les résultats de la requête auraient affiché quelque chose de semblable à <div><b><u>Customer Value</u>...

Ajout de la prise en charge de l’opérateur de requête Pas dans

Les champs qui prennent en charge l’opérateur de requête « Dans » prennent désormais en charge « Pas dans ». Écrivez des requêtes pour les éléments de travail qui ne sont « Pas dans » une liste d’ID, « Pas dans » une liste d’états, et bien plus encore, sans avoir à créer de nombreuses clauses « Ou » imbriquées.

Requête pour @MyRecentActivity et @RecentMentions

Nous avons introduit deux nouvelles macros de requête pour le champ ID afin de vous aider à trouver les éléments de travail susceptibles de vous intéresser. Découvrez les éléments dans lesquels vous avez été mentionné au cours des 30 derniers jours à l’aide de @RecentMentions, ou examinez les éléments de travail que vous avez récemment consultés ou modifiés à l’aide de @MyRecentActivity.

Filtre d’étiquettes et de champs personnalisés dans les notifications de suivi d’éléments de travail

Vous pouvez désormais définir des notifications en utilisant des conditions sur des étiquettes et des champs personnalisés. Non seulement vous êtes averti quand les valeurs changent, mais aussi quand certaines sont atteintes. Vous bénéficiez aussi d’un ensemble de notifications plus robuste que vous pouvez définir pour des éléments de travail.

Prise en charge de Mentionné pour la page Mes éléments de travail

Nous avons ajouté un nouveau champ pivot Mentionné dans la page Mes éléments de travail. Dans ce champ pivot, vous pouvez passer en revue les éléments de travail dans lesquels vous avez été mentionné au cours des 30 derniers jours. Avec cette nouvelle vue, vous pouvez agir rapidement sur les éléments qui réclament votre attention, et être tenu informé des conversations qui vous intéressent.

Cette vue est également disponible via notre expérience mobile, ce qui permet de maintenir une cohérence entre le monde mobile et celui des postes de travail.

Filtrage des plans

L’extension Plans de livraison utilise désormais notre composant de filtrage commun. Elle est cohérente avec nos expériences utilisateur de filtrage de grille pour les éléments de travail et les Tableaux. Ce contrôle du filtrage apporte une convivialité améliorée et une interface cohérente à tous les membres de votre équipe.

Navigation parmi les plans mis à jour

Beaucoup d’entre vous s’intéressent tout particulièrement à un plan spécifique ou à un ensemble de plans, et utilisent des favoris pour accéder rapidement au contenu. Nous avons d’abord mis à jour le hub Plans pour accéder au dernier plan visité au lieu de passer par la page du répertoire. Utilisez ensuite le sélecteur de favoris pour passer rapidement d’un plan à un autre, ou utilisez la barre de navigation pour revenir à la page d’annuaire.

Développer/réduire des exigences/personnes dans le tableau des tâches

Vous pouvez désormais développer ou réduire tous les éléments du sprint Tableau des tâches en un seul clic.

Accorder l’autorisation de contourner des règles à des utilisateurs spécifiques

Bien souvent, au moment d’effectuer la migration d’éléments de travail provenant d’une autre source, les organisations souhaitent conserver toutes les propriétés d’origine de l’élément de travail. Par exemple, vous pouvez être amené à créer un bogue qui conserve les valeurs de la date de création et de l’auteur en provenance du système d’origine.

L’API qui permet de mettre à jour un élément de travail a un indicateur de contournement de règles pour rendre ce scénario possible. Avant, la personne qui effectuait cette requête d’API devait être membre du groupe Administrateurs de la collection de projets. Nous avons ajouté une autorisation au niveau du projet pour permettre l’exécution de l’API avec l’indicateur de contournement de règles.

Génération et mise en production

Builds XAML

Dans TFS 2015, nous avons introduit un système de génération multiplateforme basé sur le web. Les builds XAML ne sont pas prises en charge dans TFS 2018 RTW ni dans Update 1, mais nous les avons réactivées dans TFS 2018 Update 2. Nous vous encourageons à migrer vos builds XAML.

Quand vous effectuez la mise à niveau vers TFS 2018 Update 2 :

• Si vous avez des données de build XAML dans votre collection de projets d’équipe, vous recevez un avertissement sur la dépréciation des fonctionnalités de build XAML.

• Vous devez alors utiliser VS ou Team Explorer 2017 pour modifier les définitions de build XAML ou pour mettre de nouvelles builds en file d’attente.

• Si vous avez besoin de créer des agents de build XAML, vous devez les installer en utilisant le programme d’installation de l’agent de build TFS 2015.

Pour une description de notre plan de désapprobation de build XAML, consultez le billet de blog sur l’évolution des fonctionnalités d’automatisation de génération pour TFS/Team Services.

Améliorations apportées aux builds multiphases

Vous avez pu utiliser des phases pour organiser vos étapes de build et cibler différents agents avec différentes demandes pour chaque phase. Nous avons ajouté plusieurs fonctionnalités de génération de phases pour que vous puissiez désormais :

• Spécifier une file d’attente d’agents distincte pour chaque phase. Cela signifie que vous pouvez, par exemple :

  • Exécuter une phase d’une build sur un agent macOS et une autre phase sur un agent Windows. Pour voir un exemple intéressant, consultez cette vidéo de Connect(); de 2017 : Pipeline DevOps d’intégration continue (CI)/de livraison continue (CD) pour les services et applications mobiles.
  • Exécuter les étapes de build sur un pool d’agents de build, et tester les étapes sur un pool d’agents de test.

• Exécuter les tests plus rapidement en les exécutant en parallèle. Toute phase dont le parallélisme est configuré comme « Multi-agent » et qui contient une tâche « VSTest » parallélise désormais automatiquement l’exécution des tests sur le nombre d’agents configurés.

• Autoriser ou empêcher les scripts d’accéder au jeton OAuth de chaque phase. Cela signifie, par exemple, que vous pouvez désormais autoriser les scripts qui s’exécutent dans votre phase de build à communiquer avec les API REST via VSTS, et dans la même définition de build, bloquer les scripts qui s’exécutent dans votre phase de test.

• Exécuter une phase uniquement dans des conditions spécifiques. Par exemple, vous pouvez configurer une phase pour qu’elle s’exécute uniquement en cas de succès des phases précédentes, ou quand vous générez du code dans la branche principale.

Pour en savoir plus, consultez Phases dans la gestion des builds et des mises en production.

Ignorer les builds planifiées si rien n’a changé dans le dépôt

À la demande générale, vous pouvez maintenant spécifier qu’une build planifiée ne doit pas s’exécuter quand rien ne change dans votre code. Vous pouvez contrôler ce comportement à l’aide d’une option de la planification. Par défaut, nous ne programmons pas de nouvelle build si votre dernière build planifiée (dans la même planification) a réussi, et si aucun changement n’a été archivé dans votre dépôt.

Builds avec intégration continue à partir de GitHub Enterprise

Vous disposez désormais d’une meilleure intégration pour l’exécution de builds d’intégration continue (CI) si vous utilisez GitHub Enterprise pour la gestion de versions. Avant, vous étiez limité à l’interrogation des modifications du code à l’aide du connecteur Git Externe, ce qui a éventuellement augmenté la charge sur vos serveurs et entraîné des retards de déclenchement des builds. Désormais, avec la prise en charge officielle de GitHub Enterprise, les builds d’intégration continue (CI) d’équipe sont immédiatement déclenchées. De plus, la connexion peut être configurée à l’aide de diverses méthodes d’authentification, par exemple les comptes intégrés ou LDAP.

Vous pouvez télécharger des fichiers sécurisés vers les agents durant la build ou la mise en production

La nouvelle tâche Télécharger un fichier sécurisé prend en charge le téléchargement (vers les machines d’agents) des fichiers chiffrés à partir de la bibliothèque de fichiers sécurisés VSTS. Une fois le fichier téléchargé, il est déchiffré et stocké sur le disque de l’agent. À la fin de la build ou de la mise en production, le fichier est supprimé de l’agent. Cela permet à votre build ou votre mise en production d’utiliser des fichiers sensibles, par exemple des certificats ou des clés privées, qui sont en principe chiffrés de manière sécurisée et stockés dans VSTS. Pour plus d’informations, consultez la documentation relative aux fichiers sécurisés.

Les profils de provisionnement Apple peuvent être installés à partir de dépôts de code source

La tâche Installer le profil d’approvisionnement Apple prend déjà en charge l’installation (sur les machines d’agents) des profils de provisionnement stockés dans la bibliothèque de fichiers sécurisés VSTS. Les profils de provisionnement permettent à Xcode de signer les applications Apple et de les inclure dans des packages pour iOS, macOS, tvOS et watchOS, par exemple. Désormais, vous pouvez installer les profils de provisionnement à partir des dépôts de code source. Bien qu’il soit recommandé d’utiliser la bibliothèque de fichiers sécurisés pour renforcer la sécurité de ces fichiers, cette amélioration concerne les profils de provisionnement déjà stockés dans le contrôle de code source.

Tracer les sources GitHub vers les builds à l’aide des étiquettes de build

Les builds de GitHub ou GitHub Enterprise sont déjà liées à la validation appropriée. Il est tout aussi important de pouvoir tracer une validation vers les builds correspondantes. C’est désormais possible si vous activez l’étiquetage de la source dans TFS. Quand vous choisissez votre dépôt GitHub dans une définition de build, sélectionnez les types de build à étiqueter, ainsi que le format de l’étiquette.

Découvrez ensuite les étiquettes de build qui s’affichent dans votre dépôt GitHub ou GitHub Enterprise.

Vous pouvez installer des kits JDK (Java Development Kit) spécifiques durant les builds et les mises en production

Pour générer certains projets Java, vous devez parfois disposer de kits JDK spécifiques qui ne sont pas disponibles sur les machines d’agents. Par exemple, certains projets peuvent nécessiter des versions plus anciennes ou différentes de kits JDK d’IBM, d’Oracle ou open source. La tâche Programme d’installation d’outils Java télécharge et installe le kit JDK nécessaire à votre projet durant une build ou une mise en production. La variable d’environnement JAVA_HOME est donc définie de manière appropriée pour la durée de la build ou de la mise en production. Des kits JDK spécifiques sont disponibles pour le Programme d’installation d’outils Java via un partage de fichiers, un dépôt de code source ou un Stockage Blob Azure.

Configuration de build Xcode améliorée

La tâche Xcode a été mise à jour avec une nouvelle version principale (4.*) qui améliore la configuration de la génération, des tests et de la création de packages Xcode. Si votre projet Xcode a un schéma partagé unique, il est automatiquement utilisé. Une aide inline supplémentaire a été ajoutée. Les fonctionnalités dépréciées, telles que la création de paquets xcrun, ont été supprimées des propriétés de la tâche Xcode. Vous devez modifier les définitions de build et de mise en production existantes pour pouvoir utiliser la dernière version 4.* de la tâche Xcode. Pour les nouvelles définitions, si vous avez besoin de fonctionnalités dépréciées liées à une version précédente de la tâche Xcode, vous pouvez sélectionner cette version dans votre définition.

Portes de mise en production

La surveillance continue fait partie intégrante des pipelines DevOps. La vérification de l’intégrité de l’application dans une mise en production après un déploiement est aussi essentielle que la réussite du processus de déploiement. Les entreprises ont adopté différents outils qui permettent de détecter automatiquement l’intégrité de l’application en production et de suivre les incidents signalés par les clients. Jusqu’à présent, les approbateurs devaient surveiller manuellement l’intégrité des applications à partir de tous les systèmes avant de promouvoir la mise en production. Toutefois, Release Management prend désormais en charge l’intégration de la surveillance continue dans les pipelines de mise en production. Utilisez cette fonctionnalité pour vérifier que le système interroge à plusieurs reprises tous les signaux d’intégrité de l’application jusqu’à ce qu’il n’y ait plus aucun problème détecté, avant de poursuivre la mise en production.

Vous devez commencer par définir les portes de prédéploiement ou de postdéploiement dans la définition de mise en production. Chaque porte peut surveiller un ou plusieurs signaux d’intégrité correspondant à un système de surveillance de l’application. Des portes intégrées sont disponibles pour les « alertes Azure Monitor (Application Insight) » et les « éléments de travail ». Vous pouvez effectuer une intégration avec d’autres systèmes en vous servant de la flexibilité qu’offrent les fonctions Azure.

Au moment de l’exécution, la mise en production commence à échantillonner toutes les portes et à collecter les signaux d’intégrité de chacune d’elles. Elle répète l’échantillonnage à chaque intervalle jusqu’à ce que les signaux collectés à partir de toutes les portes du même intervalle ne montrent plus aucun problème.

Les échantillons initiaux des systèmes de surveillance peuvent éventuellement manquer de précision, si les informations disponibles pour le nouveau déploiement ne sont pas suffisantes. L’option « Délai avant l’évaluation » permet de garantir que la mise en production ne progresse pas durant cette période, même si tous les échantillons sont réussis.

Aucun agent ou pipeline n’est consommé durant l’échantillonnage des portes. Pour plus d’informations, consultez la documentation relative aux portes de mise en production.

Déployer de manière sélective en fonction de l’artefact qui déclenche une mise en production

Vous pouvez ajouter plusieurs sources d’artefacts à une définition de mise en production, et les configurer pour déclencher une mise en production. Une mise en production est créée quand une nouvelle build est disponible pour l’une des sources. Le même processus de déploiement est exécuté, quelle que soit la source qui a déclenché la mise en production. Vous pouvez désormais personnaliser le processus de déploiement en fonction de la source de déclenchement. Pour les mises en production déclenchées automatiquement, la variable de mise en production Release.TriggeringArtifact.Alias identifie désormais la source d’artefact ayant déclenché la mise en production. Vous pouvez l’appliquer aux conditions de tâches, aux conditions de phases et aux paramètres de tâches pour ajuster dynamiquement le processus. C’est le cas, par exemple, si vous avez uniquement besoin de déployer les artefacts qui ont changé au travers des environnements.

Gérer la sécurité spécifique à une entité

Jusqu’à maintenant, avec la sécurité basée sur les rôles, les rôles d’accès de sécurité étaient définis pour un utilisateur ou un groupe au niveau du hub. Cela s’appliquait aux groupes de déploiement, aux groupes de variables, aux files d’attente d’agents et aux points de terminaison de service. Vous pouvez désormais activer ou désactiver l’héritage d’une entité particulière pour configurer la sécurité comme vous le souhaitez.

Approuver plusieurs environnements

La gestion des approbations pour les mises en production est plus simple. Quand des pipelines ont le même approbateur pour plusieurs environnements déployés en parallèle, l’approbateur doit agir séparément sur chacune des approbations. Avec cette fonctionnalité, vous pouvez désormais effectuer plusieurs approbations en attente en même temps.

Extensibilité des modèles de mise en production

Les modèles de mise en production vous permettent de créer une base de référence durant la définition d’un processus de mise en production. Jusqu’ici, vous pouviez en charger de nouveaux dans votre compte. À présent, les auteurs peuvent inclure des modèles de mise en production dans leurs extensions. Vous pouvez consulter un exemple dans le dépôt GitHub.

Tâches et phases de mise en production conditionnelles

Comme pour les tâches de build conditionnelles, vous pouvez désormais exécuter une tâche ou une phase uniquement si certaines conditions sont remplies. Cela vous permet de modéliser des scénarios de restauration.

Si les conditions intégrées ne répondent pas à vos besoins, ou si vous souhaitez avoir un contrôle plus précis de l’exécution de la tâche ou de la phase, vous pouvez spécifier des conditions personnalisées. Exprimez la condition sous la forme d’un ensemble imbriqué de fonctions. L’agent évalue la fonction la plus intérieure et progresse vers l’extérieur. Il en résulte une valeur booléenne qui détermine si la tâche doit être exécutée.

Historique des requêtes pour les points de terminaison de service

Les points de terminaison de service permettent de se connecter à des services externes et distants pour exécuter des tâches de build ou de déploiement. Les points de terminaison sont configurés dans la portée du projet et sont partagés entre plusieurs définitions de build et de mise en production. Les propriétaires de points de terminaison de service peuvent désormais obtenir un affichage consolidé des builds et des déploiements utilisant un point de terminaison, ce qui permet d’améliorer l’audit et la gouvernance.

Les propriétés par défaut des types d’artefact Git et GitHub sont désormais modifiables

Vous pouvez désormais modifier les propriétés par défaut des types d’artefact Git et GitHub même une fois que l’artefact a été lié. Cela est particulièrement utile dans les scénarios où la branche de la version stable de l’artefact a changé, et où les futures mises en production de livraison continue doivent utiliser cette branche pour obtenir des versions plus récentes de l’artefact.

Déployer en bloc des environnements manuellement à partir de la vue de mise en production

Vous pouvez désormais déclencher manuellement l’action Déployer sur plusieurs environnements d’une mise en production en même temps. Cela vous permet de sélectionner plusieurs environnements dans une mise en production comportant des configurations ou des déploiements non réussis, et de les redéployer sur tous les environnements en une seule opération.

Prise en charge des pipelines multibranches Jenkins et liaison des travaux organisés en dossiers

La consommation de projets à partir de Jenkins a encore été améliorée.

En premier lieu, vous pouvez désormais consommer les projets de pipelines multibranches Jenkins en tant que sources d’artefact dans une définition de mise en production.

En second lieu, vous n’êtes plus limité à la liaison de projets Jenkins en tant qu’artefacts à partir du dossier racine d’un serveur Jenkins. Désormais, les projets Jenkins peuvent être consommés quand ils sont organisés en dossiers. Vous voyez la liste des projets Jenkins, ainsi que les chemins des dossiers, dans la liste des sources à partir desquelles vous sélectionnez le projet à consommer en tant que source d’artefact.

Registre Docker Hub ou Azure Container Registry en tant que source d’artefact

Cette fonctionnalité permet aux mises en production d’utiliser les images stockées dans un registre Docker Hub ou un registre ACR (Azure Container Registry). Il s’agit d’une première étape vers la prise en charge de scénarios tels que le déploiement de nouveaux changements région par région à l’aide de la fonctionnalité de géoréplication d’ACR, ou le déploiement sur un environnement (de production, par exemple) à partir d’un registre de conteneurs ayant uniquement des images pour l’environnement de production.

Vous pouvez désormais configurer Docker Hub ou ACR en tant qu’artefact de premier plan via l’expérience utilisateur d’artefact + Ajouter d’une définition de mise en production. Pour l’instant, la mise en production doit être déclenchée manuellement ou par un autre artefact, mais nous comptons ajouter prochainement un déclencheur basé sur l’envoi (push) d’une nouvelle image au registre.

Versions d’artefacts par défaut

Il existe désormais plusieurs options de version par défaut pour la liaison des artefacts de gestion de versions à une définition de mise en production. Vous pouvez configurer une validation/un ensemble de modifications spécifique, ou simplement configurer la dernière version à choisir dans la branche par défaut. Normalement, vous effectuez la configuration nécessaire pour récupérer la dernière version, mais cela est particulièrement utile dans certains environnements où une version d’artefact finale doit être spécifiée pour tous les déploiements continus futurs.

Améliorations de la branche des déclencheurs de mise en production

Vous pouvez désormais configurer un filtre de déclencheur de mise en production en fonction de la branche par défaut spécifiée dans la définition de build. Cela est particulièrement utile si votre branche de build par défaut change à chaque sprint, et que les filtres de déclencheur de mise en production doivent être mis à jour dans l’ensemble des définitions de mise en production. Désormais, il vous suffit juste de changer la branche par défaut dans la définition de build pour que toutes les définitions de mise en production utilisent automatiquement cette branche. Par exemple, si votre équipe crée des branches de mise en production pour chaque charge utile de mise en production de sprint, vous devez la mettre à jour dans la définition de build pour qu’elle pointe vers une nouvelle branche de mise en production de sprint et que la mise en production la récupère automatiquement.

Déclencheur de mise en production pour un artefact de gestion des packages

Désormais, vous pouvez définir un déclencheur sur un artefact Package Management dans une définition de mise en production pour qu’une mise en production soit automatiquement créée quand une nouvelle version du package est publiée. Pour plus d’informations, consultez la documentation relative aux déclencheurs dans Release Management.

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. Vous avez désormais à la place la possibilité de limiter les groupes de variables à des environnements spécifiques. Ceci les rend disponibles pour un environnement, mais pas pour d’autres environnements de 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.

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.

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. Jusqu’à maintenant, les artefacts Jenkins n’avaient pas de paramètre de version par défaut. Vous ne pouviez donc pas définir un déclencheur de déploiement continu pour 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 :

• Plus récent
• Spécifier au moment de la création de la mise en production
• Version spécifique

Contribuer aux portes de mise en production à partir des extensions

Les portes de mise en production permettent d’ajouter des approbations basées sur des informations aux pipelines de mise en production. Un ensemble de signaux d’intégrité sont collectés à plusieurs reprises avant ou après le déploiement pour déterminer si la mise en production doit être promue ou non à la phase suivante. Un ensemble de portes intégrées sont fournies. La porte « Appeler la fonction Azure » a jusqu’à présent été recommandée en tant que méthode d’intégration à d’autres services. Nous simplifions désormais l’intégration aux autres services et l’ajout de portes via les extensions de Marketplace. Vous pouvez contribuer à des tâches de porte personnalisées et permettre aux auteurs de définitions de mise en production d’accéder à une expérience utilisateur améliorée pour configurer la porte.

Découvrez-en plus sur la création de tâches de porte.

Mettre à l’échelle des déploiements sur des machines virtuelles à l’aide de Groupes de déploiement

La fonctionnalité Groupes de déploiement, une solution robuste et prête à l’emploi de déploiement sur plusieurs machines, est désormais mise à la disposition générale. Avec Groupes de déploiement, vous pouvez orchestrer des déploiements sur plusieurs serveurs et effectuer des mises à jour propagées, tout en assurant la haute disponibilité de votre application tout au long du processus. Vous pouvez également effectuer un déploiement sur des serveurs locaux ou des machines virtuelles sur Azure ou n’importe quel cloud, tout en bénéficiant de la traçabilité de bout en bout des versions des artefacts déployées jusqu’au niveau serveur.

La fonctionnalité de déploiement basée sur un agent s’appuie sur les mêmes agents de build et de déploiement généralement disponibles. Vous pouvez utiliser le catalogue complet des tâches sur vos machines cibles lors de la phase Groupe de déploiement. Du point de vue de l’extensibilité, vous pouvez également utiliser les API REST pour les groupes de déploiement et les cibles dans le cadre d’un accès par programme.

Package

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

Les sources amont pour nuget.org et npmjs.com sont désormais disponibles. 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é.

Stratégies de rétention dans les flux TFS

Jusqu’à présent, les flux de packages TFS ne fournissaient aucun moyen de nettoyer automatiquement les anciennes versions de package inutilisées. Pour les éditeurs de packages récurrents, cela pouvait se traduire par un ralentissement des requêtes de flux dans le Gestionnaire de package NuGet et d’autres clients tant que certaines versions n’étaient pas supprimées manuellement.

Nous avons maintenant activé les stratégies de conservation sur les flux TFS. Les stratégies de conservation suppriment automatiquement la version la plus ancienne d’un package une fois que le seuil de conservation est atteint. Les packages promus en vues sont conservés indéfiniment, ce qui vous permet de protéger les versions utilisées en production ou largement utilisées dans votre organisation.

Pour activer les stratégies de rétention, modifiez votre flux et entrez une valeur dans la zone Nombre maximal de versions par package de la section Stratégies de rétention.

Filtrage dans la gestion des packages

La page Packages a été mise à jour pour utiliser notre disposition et notre contrôle de barre de commandes standard, ainsi que la nouvelle barre de filtre standard.

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. Vous pouvez désormais créer des badges pour les packages de vos flux. Cochez simplement 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.

Les versions précédentes de packages s’affichent désormais dans une liste en pleine page

Nous avons reçu beaucoup de commentaires sur la mise à jour de l’expérience utilisateur de Package Management. Nous avions déplacé la liste des versions précédentes de packages vers un sélecteur de barre de navigation dans la page des détails du package. Nous avons ajouté un nouveau champ pivot Versions, qui fournit plus d’informations sur les versions antérieures, et facilite la copie du numéro de version ou l’obtention d’un lien vers une ancienne version.

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 pour plus d’informations.

Prise en charge de Gulp, de Yarn et de flux authentifiés supplémentaires

La tâche npm fonctionne aujourd’hui sans problème avec les flux npm authentifiés (dans Package Management ou les registres externes tels que npm Enterprise et Artifactory). Toutefois, jusqu’à maintenant, il était difficile d’utiliser un exécuteur de tâches tel que Gulp ou un autre client npm tel que Yarn, sauf si la tâche prenait également en charge les flux authentifiés. Nous avons ajouté une nouvelle tâche de build Authentification npm, qui ajoute des informations d’identification à votre fichier .npmrc pour permettre aux tâches suivantes d’utiliser correctement les flux authentifiés.

Les autorisations par défaut du flux de packages incluent désormais les administrateurs de projet

Dans le passé, la création d’un flux définissait l’utilisateur qui l’avait créé en tant qu’unique propriétaire du flux. Cela pouvait entraîner des problèmes d’administration dans les grandes organisations, si cet utilisateur changeait d’équipe ou quittait l’organisation. Pour supprimer ce point de défaillance unique, la création d’un flux utilise désormais le contexte de projet actuel de l’utilisateur pour obtenir le groupe Administrateurs de projet et en faire également le propriétaire du flux. Comme pour toute autorisation, vous pouvez supprimer ce groupe et personnaliser davantage les autorisations de flux à l’aide de la boîte de dialogue des paramètres de flux.

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.

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 en utilisant une URL qui sélectionne automatiquement un projet auquel le destinataire a accès.

Le format de l’URL est le suivant : « https://<URL_serveur_TFS>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package »

Tous les paramètres, à l’exception de « <TFSserverURL> » sont facultatifs, mais si vous spécifiez un package, vous devez indiquer le type du protocole.

Test

La tâche Test Visual Studio n’a pas besoin de Visual Studio dans son intégralité

La tâche Test Visual Studio dans une build/mise en production nécessite la présence de Visual Studio sur l’agent pour exécuter les tests. Au lieu d’installer Visual Studio pour exécuter des tests dans des environnements de production ou distribuer simplement des tests sur plusieurs agents, utilisez la nouvelle tâche Programme d’installation de Visual Studio Test Platform. Cette tâche récupère la plateforme de test à partir de nuget.org, et l’ajoute au cache d’outils. La tâche d’installation répond à la demande de vstest, et la tâche Test Visual Studio qui suit dans la définition peut s’exécuter sans avoir besoin d’une installation complète de Visual Studio sur l’agent.

Dans le catalogue de tâches, ajoutez la tâche d’installation à votre définition.

Configurez la tâche Visual Studio Test suivante pour utiliser les éléments acquis via le programme d’installation.

Remarque

Limitations : le package de plateforme de test sur NuGet ne prend pas en charge la fonctionnalité de test codé de l’interface utilisateur. L’activation de la prise en charge du test codé de l’interface utilisateur s’effectue sur le backlog. Le package de plateforme de test sur NuGet est multiplateforme. Toutefois, la tâche VSTest ne prend pas en charge l’exécution des tests .NET Core. Pour exécuter des tests .NET Core, utilisez la tâche « dot net ».

Les tâches Exécuter les tests fonctionnels et Déployer l’agent de test sont dépréciées

L’année dernière, nous avons commencé à unifier les agents de build, de mise en production et de test. Cela nous a permis d’améliorer divers points faibles associés à l’utilisation des tâches WinRM Déployer l’agent de test et Exécuter les tests fonctionnels. Cela vous permet également d’utiliser la tâche Test Visual Studio (VSTest) pour tous vos besoins liés aux tests :

• Tests unitaires
• Tests fonctionnels (IU/non IU)
• Tests MSTest
• Tests de frameworks de tiers
• Spécification de tests d’assembly ou exécution de tests avec plan de test/suite de tests
• Exécution de tests sur un seul agent et distribution de tests sur plusieurs agents

L’approche relative aux agents unifiés permet également aux administrateurs de gérer toutes les machines utilisées pour une intégration continue (CI)/livraison continue (CD) de manière uniforme.

Nous avons mis à disposition plusieurs éléments cruciaux pour permettre l’accès à cette fonctionnalité :

• Les agents peuvent être configurés pour les tests d’IU
• Le programme d’installation de Visual Studio Test Platform permet à la tâche VSTest de s’exécuter sans nécessiter l’installation préalable de Visual Studio
• Les définitions de build et de mise en production peuvent être créées avec plusieurs phases et utiliser des files d’attente d’agents distinctes pour chaque phase
• Les cas de test automatisés peuvent être exécutés à partir du hub de test à l’aide de la tâche VSTest

Tout ce qui précède étant désormais en place, nous sommes prêts à déprécier ces deux tâches. Bien que les définitions existantes basées sur les tâches dépréciées continuent à fonctionner, nous vous encourageons à utiliser VSTest pour tirer parti d’une amélioration continue au fil du temps.

Filtrer un grand nombre de résultats des tests

Avec le temps, les composants de test s’accumulent, et les applications volumineuses peuvent facilement atteindre des milliers de tests. Les équipes recherchent de meilleures façons de naviguer parmi les grands jeux de résultats des tests pour rester productives tout en identifiant les échecs de tests, la cause racine associée ou la responsabilité des problèmes. Pour cela, nous avons ajouté trois nouveaux filtres sous l’onglet Tests dans Build et mise en production : Nom du test, Conteneur (DLL) et Propriétaire (propriétaire du conteneur).

En outre, le filtre Résultat existant offre désormais la possibilité de filtrer plusieurs résultats. Les différents critères de filtre sont cumulatifs par nature. En tant qu’utilisateur, si je souhaite afficher le résultat de mes tests pour une modification que je viens de valider, je peux appliquer un filtre de type Conteneur (nom de la DLL), Propriétaire (propriétaire de la DLL) ou Nom du test, ou tous ces filtres à la fois, pour obtenir des résultats adaptés à mes besoins.

Identifier les tests non fiables

Parfois, les tests ne sont pas fiables. Ils oscillent entre réussite et échec au cours des exécutions, sans avoir fait l’objet de changements. Les tests non fiables peuvent être frustrants et faire douter du Rapport d’efficacité de test. En effet, les échecs ignorés risquent d’entraîner des bogues qui passeront inaperçus. Avec cette mise à jour, nous avons déployé la première partie d’une solution visant à prendre en charge le problème des tests non fiables. Vous pouvez désormais configurer la tâche Test Visual Studio pour réexécuter les tests non réussis. Les résultats des tests indiquent alors quels sont les tests qui sont passés d’un état d’échec initial à un état de réussite après avoir été réexécutés. La prise en charge de la réexécution des tests pilotés par les données et des tests ordonnés viendra plus tard.

Vous pouvez configurer la tâche Test Visual Studio pour contrôler le nombre maximal de tentatives de réexécution de tests non réussis, ainsi qu’un seuil d’échecs en pourcentage (par exemple, les tests doivent être réexécutés uniquement en cas d’échec de moins de 20 % de l’ensemble des tests). Cela permet d’éviter de réexécuter les tests si le nombre d’échecs est trop important.

Sous l’onglet Tests de Build et mise en production, vous pouvez filtrer les résultats des tests dont l’état est « Réussi(s) après réexécution » pour identifier les tests dont le comportement n’était pas fiable au moment de l’exécution. Ainsi, vous voyez s’afficher la dernière tentative de chaque test réussi après sa réexécution. L’affichage Résumé a également été modifié pour afficher « Réussi(s) après réexécution (n/m) » sous Nombre total de tests, où n est le nombre de tests réussis au moment de la réexécution et m est le nombre total de tests réussis. Un affichage hiérarchique de toutes les tentatives est prévu dans les prochains sprints.

Améliorations de l’aperçu et prise en charge de différents types de journal générés par la tâche Test Visual Studio

Nous avons amélioré la tâche VSTest pour publier les journaux générés par les différents genres d’instruction de journalisation correspondant aux sorties standard et aux erreurs standard des tests non réussis. Nous avons également amélioré l’expérience utilisateur relative à l’aperçu pour prendre en charge l’affichage des formats de fichiers texte et de fichiers journaux, ainsi que la recherche dans les fichiers journaux.

Wiki

Recherches dans le Wiki

Vous pouvez rechercher vos pages de Wiki favorites par titre ou par contenu, juste à côté du code et des éléments de travail. Pour en savoir plus sur les recherches dans le Wiki, consultez le blog consacré à Microsoft DevOps.

Imprimer des pages de Wiki

Vous pouvez utiliser le contenu du Wiki de diverses manières. Parfois, il vous sera utile d’imprimer le contenu du Wiki pour pouvoir le lire pendant votre temps libre, y ajouter des commentaires au stylo sur le papier, ou même partager une copie PDF hors connexion avec des personnes externes à votre projet VSTS. Désormais, cliquez simplement sur le menu contextuel d’une page, puis sélectionnez Imprimer la page.

Remarque

Cette fonctionnalité n’est pas prise en charge sur Firefox.

Contribuer facilement aux pages de Wiki à l’aide des raccourcis clavier

Vous pouvez désormais utiliser des raccourcis pour effectuer des modifications courantes et afficher des actions dans le Wiki, de manière encore plus rapide, simplement à l’aide de votre clavier.

Quand vous affichez une page, vous pouvez ajouter, modifier ou créer une sous-page, par exemple :

Quand vous modifiez une page, vous pouvez rapidement l’enregistrer, l’enregistrer et la fermer, ou simplement la fermer.

Il existe également d’autres raccourcis d’édition standard tels que Ctrl+B pour la mise en gras, Ctrl+I pour la mise en italique, Ctrl+K pour la création d’un lien, etc. Pour plus d’informations, consultez la liste complète des raccourcis clavier.

Rendu Markdown enrichi dans le Markdown de dépôt de code

Vous pouvez désormais créer des fichiers README.MD enrichis dans les dépôts de code. Le rendu Markdown des fichiers MD dans les dépôts de code prend désormais en charge les balises HTML, les citations, les emojis, le redimensionnement d’image et les formules mathématiques. Il existe une parité du rendu Markdown des fichiers Wiki et MD dans le code.

Le Wiki prend en charge les formules mathématiques

Si votre application utilise des formules mathématiques et des équations, vous pouvez désormais les mettre dans le Wiki à l’aide du format LaTeX.

Référencer des éléments de travail dans le Wiki

Vous pouvez désormais référencer des éléments de travail dans les pages de Wiki en appuyant sur la touche « # » pour obtenir la liste des derniers éléments de travail auxquels vous avez accédé, et sélectionner l’élément de travail qui vous intéresse. Cela est particulièrement utile pour rédiger des notes de publication, des épopées, des spécifications ou d’autres pages nécessitant une référence à un élément de travail.

Lier des éléments de travail et des pages de Wiki

Vous pouvez désormais lier un élément de travail à un Wiki, et inversement. Vous pouvez lier des éléments de travail au Wiki pour créer des pages longues (épopées), des notes de publication et un contenu de planification afin de suivre les éléments de travail associés à une page de Wiki et valider le pourcentage d’achèvement de votre page.

Les éléments de travail liés s’affichent ensuite dans la page de Wiki.

Ajoutez un lien vers une page de Wiki à partir d’un élément de travail via le nouveau type de lien « Page de Wiki ».

Ctrl+S pour enregistrer une page de Wiki

Nous avons entendu dire que vous souhaitiez un moyen plus rapide et plus facile d’enregistrer une page de Wiki. Désormais, utilisez simplement le raccourci clavier Ctrl+S pour enregistrer une page avec un message de révision par défaut, puis continuez votre travail de modification. Pour ajouter un message de révision personnalisé, cliquez simplement sur le chevron à côté du bouton d’enregistrement.

Coller du contenu Wiki enrichi au format HTML

Vous pouvez désormais coller du texte enrichi dans l’éditeur Markdown du Wiki à partir de n’importe quelle application basée sur un navigateur, par exemple Confluence, OneNote, SharePoint et MediaWiki. Cela est particulièrement utile quand vous créez du contenu enrichi, par exemple des tableaux complexes, et que vous souhaitez l’afficher dans le Wiki. Copiez simplement le contenu, puis collez-le au format HTML.

Déplacer une page dans le Wiki à l’aide du clavier

Jusqu’à maintenant, dans le Wiki, les utilisateurs ne pouvaient pas effectuer une réorganisation ou un reparentage des pages à l’aide du clavier. Cela avait un impact sur les utilisateurs qui préféraient exécuter les opérations au clavier. Vous pouvez désormais réorganiser les pages à l’aide des commandes Ctrl+Haut ou Ctrl+Bas. Vous pouvez également effectuer un reparentage des pages en cliquant sur Déplacer la page dans le menu contextuel d’une page, puis en sélectionnant la nouvelle page parente à déplacer.

Mise en surbrillance du texte de filtrage

Le filtrage du volet de navigation dans le Wiki affiche l’intégralité de la hiérarchie des pages. Par exemple, si vous filtrez une page intitulée « foobar », le volet de navigation filtré affiche également toutes les pages parentes. Cela peut créer une confusion concernant la raison pour laquelle les pages non intitulées « foobar » apparaissent dans les jeux de résultats filtrés. Désormais, le filtrage du contenu du Wiki met en surbrillance le texte recherché pour donner une image claire des titres filtrés et de ceux qui ne le sont pas.

Vous allez observer également un comportement similaire dans tous les volets de navigation du code. C’est le cas, par exemple, du volet de navigation des fichiers dans les demandes de tirage, les validations, les ensembles de modifications et les jeux de réservations.

Afficher l’aperçu du contenu quand vous modifiez des pages de Wiki

Certaines données montrent que les utilisateurs affichent l’aperçu d’une page de Wiki à plusieurs reprises pendant la modification d’un contenu. Pour chaque modification de page, les utilisateurs cliquent sur Aperçu 1 à 2 fois en moyenne. Cela se traduit par une expérience utilisateur lente, peu efficace et parfois trop longue pour les débutants en Markdown. Vous pouvez désormais consulter l’aperçu de votre page pendant que vous effectuez des modifications.

Général

Cartes de visite

Il existe plusieurs zones dans TFS où sont affichées les informations associées à une personne particulière, notamment (mais pas seulement) les demandes de tirage créées par un utilisateur et les éléments de travail affectés à un utilisateur. Toutefois, les informations relatives à cette personne ne sont pas suffisantes pour que vous puissiez obtenir un profil un peu plus complet. La nouvelle carte de visite remplace la carte de visite existante dans TFS. La mise à jour de la carte de visite vous permet d’interagir avec les utilisateurs de votre compte TFS, et d’en savoir plus sur ces derniers. Grâce aux intégrations avec votre client d’e-mail et de messagerie instantanée par défaut, les utilisateurs Active Directory peuvent envoyer des e-mails et démarrer des conversations instantanées directement à partir de la carte de visite. Les utilisateurs Active Directory peuvent également consulter la hiérarchie de l’organisation dans la carte de visite. Vous pouvez activer les cartes de visite dans la page d’accueil du projet, dans les sections relatives aux membres de l’équipe, à la gestion de versions, aux éléments de travail et au Wiki, en cliquant sur l’icône de carte de visite, l’avatar ou le nom d’utilisateur dans les commentaires.

Avatars arrondis

Les avatars arrondis sont là ! Toutes les images de profil du service s’affichent désormais dans un cercle au lieu d’un carré. À titre d’exemple, voici la demande de tirage réelle pour ce changement (notez que les avatars sont circulaires, et non carrés).

Étiquettes de projet

Vous pouvez désormais orner des projets avec des mots clés importants (étiquettes). Les administrateurs peuvent facilement ajouter et supprimer des étiquettes directement dans la page d’accueil du projet, ce qui permet aux utilisateurs de mieux comprendre l’objectif et la portée du projet. Nous avons d’autres choses en réserve pour vous aider à tirer parti des étiquettes de projet, alors restez à l’écoute pour plus d’actualités.

Réorganiser les groupes de favoris

Vous pouvez désormais réorganiser les groupes dans la page Mes favoris du compte, à l’aide des flèches vers le haut et vers le bas de chaque en-tête de groupe.

---

Commentaires et suggestions

Nous sommes à votre écoute ! Vous pouvez signaler et suivre un problème sur Developer Community et obtenir des conseils sur Stack Overflow.

---

Haut de page