Notes de publication de Team Foundation Server 2017

---

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|

---

---

Dans cet article, vous trouverez des informations sur Team Foundation Server 2017. Cliquez sur le bouton pour télécharger.

Pour en savoir plus sur Team Foundation Server 2017, consultez la page Configuration requise et compatibilité de Team Foundation Server.

Pour plus d’informations, consultez la page d’installation TFS.

---

Date de publication de de publication : 28 février 2018

Cette mise à jour corrige les vulnérabilités potentielles liées aux scripts de site à site potentiel (XSS) et d’autres aspects de la sécurité. Consultez le billet de blog pour plus d’informations. Cette mise à niveau est complète, donc vous pouvez effectuer directement la mise à niveau vers TFS 2017.0.1.

Date de publication de de publication : 16 novembre 2016

Récapitulatif des nouveautés de Team Foundation Server 2017

• Code Search
• Gestion des packages
• Améliorations apportées à Agile
• Améliorations apportées aux tableaux de bord et aux widgets
• Améliorations apportées dans Git
• Améliorations apportées aux builds
• Améliorations apportées à Release Management
• Améliorations apportées aux tests
• Améliorations apportées à Marketplace
• Améliorations apportées à l’administration
• Jetons d’accès personnels

Problèmes connus

• Problèmes connus

---

Détails des nouveautés de Team Foundation Server 2017

Code Search

Code Search fournit un moyen rapide, flexible et précis d’effectuer des recherches dans tout votre code. À mesure que votre code base se développe et qu’il est réparti sur plusieurs projets et référentiels, trouver ce dont vous avez besoin devient de plus en plus difficile. Pour optimiser la collaboration entre les équipes et le partage de code, Code Search permet de localiser rapidement et efficacement les informations pertinentes dans l’ensemble de vos projets.

Qu’il s’agisse de découvrir des exemples de l’implémentation d’une API, de parcourir sa définition ou de rechercher le texte d’une erreur, Code Search fournit une solution unique pour tous vos besoins en matière d’exploration et de dépannage du code (Figure 1) .

Code Search offre les fonctionnalités suivantes :

• Recherche dans un ou plusieurs projets
• Classement sémantique
• Filtrage enrichi
• Collaboration de code

Pour plus d’informations, consultez Rechercher dans l’ensemble de votre code.

Package Management

Les packages permettent de partager du code au sein de votre organisation : vous pouvez composer un produit de grande taille, développer plusieurs produits basés sur un framework commun partagé, ou créer et partager des bibliothèques et des composants réutilisables. La gestion des packages (Figure 2) facilite le partage du code en hébergeant vos packages, en les partageant avec les personnes que vous sélectionnez et en les rendant facilement accessibles à Team Build et Release Management.

La gestion des packages vous évite d’héberger un serveur ou un partage de fichiers NuGet distinct en hébergeant les packages NuGet directement dans votre serveur Team Foundation Server. Il fournit la meilleure prise en charge pour NuGet 3.x ainsi qu’une prise en charge pour les clients hérités de NuGet 2.x. Il fonctionne de manière transparente avec votre infrastructure, vos équipes et vos autorisations TFS existantes. Vous n’avez donc pas besoin de synchroniser les identités, gérer les groupes à plusieurs emplacements, etc. Il s’intègre également facilement avec Team Build pour que vous puissiez créer et utiliser des packages dans les workflows d’intégration continue.

Pour plus d’informations, consultez la vue d’ensemble de la gestion des packages.

Améliorations apportées à Agile

Dans Team Foundation Server 2017, nous avons ajouté de nouvelles fonctionnalités aux éléments de travail et aux tableaux Kanban.

Nouveau formulaire d’élément de travail

Le nouveau formulaire d’élément de travail (Figure 3) a une nouvelle apparence. En outre, il présente de nouvelles caractéristiques intéressantes :

• Enrichissement de l’expérience des discussions relatives à un élément de travail
• Prise en charge du glisser-déplacer pour les pièces jointes.
• Amélioration de l’expérience de l’historique (History & auditing (Historique et audit).
• Amélioration de l’intégration du code et des builds
• Coloration des états.
• Conception réactive.

Suivre un élément de travail

Vous pouvez désormais configurer une alerte pour suivre les modifications apportées à un seul élément de travail en cliquant simplement sur le nouveau bouton « Follow » (Suivre) (Figure 4) dans le formulaire. Quand vous suivez un élément de travail, vous recevez une notification chaque fois qu’il change, notamment en ce qui concerne les mises à jour de champs, les liens, les pièces jointes et les commentaires.

Pour plus d’informations, consultez Suivre un élément de travail.

Mises à jour dynamiques du tableau Kanban

Votre tableau Kanban est désormais dynamique !

Avez-vous déjà appuyé sur la touche F5 pour suivre l’évolution quotidienne à l’aide de votre tableau Kanban ? Essayez l’icône représentée dans la capture d’écran ci-dessous (Figure 5) .

Quand une personne de votre équipe crée, met à jour ou supprime un élément de travail dans le tableau, votre tableau est immédiatement mis à jour. De plus, si l’administrateur effectue des mises à jour au niveau du tableau ou de l’équipe, par exemple en ajoutant une nouvelle colonne ou en activant des bogues dans le backlog, vous recevez une notification vous invitant à actualiser le tableau pour mettre à jour sa disposition. Il vous suffit d’activer l’icône de tour dans votre tableau Kanban et de commencer à collaborer avec votre équipe.

Pour plus d'informations, consultez Kanban basics (Concepts de base Kanban).

Améliorations apportées aux listes de vérification

Nous avons apporté plusieurs améliorations au fonctionnement des listes de vérification.

Les titres des listes de vérification apparaissent maintenant sous la forme de liens hypertexte (Figure 6) . Vous pouvez cliquer sur le titre pour ouvrir le formulaire d’élément de travail.

Désormais, les listes de vérification prennent aussi en charge des menus contextuels à l’aide desquels vous pouvez ouvrir, modifier ou supprimer des éléments d’une liste de vérification (Figure 7) .

Pour plus d’informations, consultez Add task checklists (Ajouter des listes de vérification de tâche).

Exploration des tableaux d’épopées et de fonctionnalités

Vous pouvez maintenant explorer vos tableaux d’épopées et de fonctionnalités (Figure 8) . Le format des listes de vérification vous permet de marquer facilement le travail comme étant effectué. Il offre une vue d’ensemble pratique pour comparer le travail achevé au travail en attente.

Pour plus d'informations, consultez Kanban features and epics (Fonctionnalités et épopées Kanban).

Activation/désactivation des annotations dans les tableaux

Désormais, vous pouvez contrôler davantage les informations supplémentaires qui apparaissent dans les cartes des tableaux. Vous pouvez maintenant sélectionner les annotations à afficher dans vos cartes Kanban (Figure 9) . Désélectionnez simplement une annotation pour qu’elle disparaisse des cartes de votre tableau Kanban. Les deux premières annotations qui apparaissent sont des éléments de travail enfants (des tâches dans cet exemple) et l’annotation de test.

Pour plus d'informations, consultez Customize Cards (Personnaliser des cartes).

Commande Effacer la mise en forme

Nous avons ajouté une nouvelle commande à tous les contrôles de texte enrichi des éléments de travail. Elle vous permet d’effacer toute la mise en forme du texte sélectionné. Comme pour la plupart des utilisateurs, il vous est probablement déjà arrivé de copier et coller du texte mis en forme dans ce champ sans pouvoir annuler l’opération (ou effacer le texte). Désormais, il vous suffit de mettre un texte en surbrillance et de sélectionner le bouton de barre d’outils Effacer la mise en forme (ou d’appuyer sur Ctrl+Barre d’espace) pour que le texte retrouve sa mise en forme par défaut.

Filtrage dans le tableau Kanban

Personnalisez vos tableaux Kanban en définissant des filtres sur les utilisateurs, les itérations, les types d’éléments de travail et les balises (Figure 10) . Ces filtres sont conservés pour que vous puissiez visualiser votre tableau personnalisé, même quand vous vous connectez à partir de plusieurs appareils.

Les membres d’équipe peuvent également filtrer leurs tableaux pour afficher la progression d’un élément de travail parent spécifique. Par exemple, un utilisateur peut afficher les récits utilisateur liés à une fonctionnalité ou afficher le travail sur plusieurs fonctionnalités qui forment une épopée. Cette fonctionnalité, tout comme les listes de contrôle, est une étape supplémentaire dans nos efforts visant à rendre plus visibles les différents niveaux de backlog.

Pour plus d’informations, consultez Filter Kanban board (Filtrer un tableau Kanban).

Chemin d’itération par défaut pour les nouveaux éléments de travail

Quand vous créez un élément de travail à partir de l’onglet Requêtes ou du widget de tableau de bord Nouvel élément de travail, le chemin d’itération de cet élément de travail est toujours défini sur l’itération actuelle. Ce n’est pas du goût de toutes les équipes, car cela signifie que les bogues peuvent s’afficher immédiatement sur le tableau des tâches. Les équipes peuvent désormais choisir le chemin d’itération par défaut (une itération spécifique ou l’itération actuelle) à utiliser pour les nouveaux éléments de travail. Accédez à la zone d’administration de votre équipe pour choisir une itération par défaut.

Pour plus d’informations, consultez la page Customize area and iteration paths (Personnaliser les chemins d’itération et de zone).

Contrôle de case à cocher

Vous pouvez maintenant ajouter un contrôle de case à cocher à vos éléments de travail (Figure 11) . Ce nouveau type de champ (booléen) possède toutes les propriétés des champs normaux et peut être ajouté à n’importe quel type dans votre processus. Dans les cartes ou un résultat de requête, la valeur est affichée sous la forme Vrai/Faux.

Pour plus d’informations, consultez Customize a field (Personnaliser un champ).

Modification de balises en bloc

Vous pouvez désormais ajouter et supprimer des balises dans plusieurs éléments de travail à l’aide de la boîte de dialogue de modification en bloc (Figure 12) .

Pour plus d’informations, consultez Add tags to work items (Ajouter des balises aux éléments de travail).

Nouveaux points d'extension

Nous avons ajouté un nouveau point de contribution aux pages de tableau et de backlog pour vous permettre d’écrire des extensions sous la forme d’un onglet dynamique en regard des onglets Tableau/Backlog/Capacité.

Nous avons ajouté un nouveau point d’extension au backlog. Les extensions peuvent cibler le volet de droite, où se trouvent actuellement le mappage et les détails du travail (Figure 13) .

Améliorations apportées aux e-mails

Nous avons considérablement amélioré la mise en forme et l’utilisation des alertes et des suivis d’éléments de travail, ainsi que des e-mails @mention envoyés par TFS (Figure 14). Désormais, les e-mails incluent un en-tête cohérent, un appel d’action clair, ainsi qu’une mise en forme améliorée qui facilite la compréhension et l’exploitation des informations contenues dans le message. En outre, ces e-mails sont conçus pour s’afficher correctement sur les appareils mobiles.

Pour plus d’informations, consultez Work item alerts (Alertes d’élément de travail).

Modèles d’éléments de travail

Nous avons ajouté la possibilité de créer des modèles d’éléments de travail riches directement dans l’expérience web native (Figure 15) . Cette fonctionnalité était précédemment très limitée sur le web et uniquement disponible dans ce nouveau formulaire à travers un outil Power Tool de Visual Studio. Les équipes peuvent désormais créer et gérer un ensemble de modèles pour modifier rapidement les champs courants.

Pour plus d’informations, consultez Work item templates (Modèles d’élément de travail).

L’intégration de Project Server n’est plus prise en charge

Team Foundation Server 2017 et les versions ultérieures ne prennent plus en charge l’intégration de Project Server. À compter de la version RC2, si vous mettez à niveau une base de données TFS sur laquelle l’intégration Project Server est configurée, vous recevez l’avertissement suivant :

Nous avons détecté que l’intégration de Project Server est configurée pour cette base de données. Team Foundation Server 2017 et les versions ultérieures ne prennent plus en charge l’intégration de Project Server.

Après la mise à niveau, l’intégration Project Server ne fonctionnera plus.

À l’avenir, nous nous appuierons sur des partenaires pour fournir des solutions d’intégration.

Pour plus d’informations sur cette modification, consultez la rubrique suivante : Synchronize TFS with Project Server (Synchroniser TFS avec Project Server).

Améliorations apportées aux tableaux de bord et aux widgets

Team Foundation Server 2017 apporte des améliorations à plusieurs widgets, comme les widgets Vignette de requête et Demande Pull.

Catalogue de widgets remanié

Nous avons remanié notre catalogue de widgets pour prendre en charge l’ensemble croissant de widgets et offrir une meilleure expérience globale (Figure 16) . La nouvelle conception inclut une expérience de recherche améliorée et est adaptée à la conception des panneaux de configuration des widgets.

Pour plus d’informations, consultez Widget Catalog (Catalogue de widgets).

Mises à jour des widgets

Maintenant, le widget Vignette de requête prend en charge jusqu’à 10 règles conditionnelles et permet de choisir des couleurs (Figure 17) . Cela est très pratique quand vous souhaitez utiliser ces vignettes en tant qu’indicateurs de performance clés pour identifier une information relative à l’intégrité et/ou une action éventuellement nécessaire.

Le widget Requête de tirage prend désormais en charge plusieurs tailles, ce qui permet aux utilisateurs de contrôler la hauteur du widget. Nous faisons en sorte que la plupart des widgets que nous fournissons soient redimensionnables. N’hésitez pas à consulter le catalogue.

Grâce au widget Nouvel élément de travail, vous pouvez désormais sélectionner le type d’élément de travail par défaut. Vous n’êtes plus obligé de recourir systématiquement à la liste déroulante pour sélectionner le type que vous créez le plus souvent.

Nous avons rendu les widgets de graphique WIT (type d’élément de travail) redimensionnables. Cela permet aux utilisateurs d’afficher une vue développée de n’importe quel graphique WIT dans le tableau de bord, quelle que soit sa taille d’origine.

Nous avons mis à jour le widget Membres d’équipe pour faciliter l’ajout d’une personne à votre équipe (Figure 18) .

Les équipes peuvent maintenant configurer la taille du widget Résultats de la requête du tableau de bord, ce qui permet d’afficher plus de résultats.

Le widget Vue d’ensemble du sprint a été repensé pour permettre aux équipes de voir plus facilement où elles en sont par rapport à leurs objectifs.

Le widget Qui me sont assignées aide les utilisateurs à gérer les tâches qui leur sont assignées sans quitter le contexte du tableau de bord (Figure 19) . Grâce à un widget dédié à cet effet, les administrateurs d’équipe peuvent ajouter cette fonctionnalité à leurs tableaux de bord en moins de 16 clics, sans changer de contexte et sans avoir à saisir du texte. Les utilisateurs peuvent désormais afficher, trier, filtrer et gérer dans le contexte du widget les tâches qui leur sont assignées.

API REST de tableaux de bord

Vous pouvez maintenant utiliser des API REST pour ajouter, supprimer et obtenir des informations sur un tableau de bord par programmation. En outre, les API vous permettent d’ajouter, de supprimer, de mettre à jour, de remplacer et d’obtenir des informations sur un widget ou une liste de widgets sur un tableau de bord. Pour plus d’informations, consultez la documentation en ligne de Visual Studio.

Tableaux de bord autorisés

Les utilisateurs non administrateurs peuvent désormais créer et gérer des tableaux de bord d’équipe. Les administrateurs d’équipe peuvent restreindre les autorisations de non administrateur par le biais du gestionnaire de tableaux de bord.

Pour plus d'informations, consultez Dashboards (Tableaux de bord).

Améliorations apportées dans Git

Certaines modifications majeures ont été apportées dans Git pour Team Foundation Server 2017. Parmi ces changements, citons la redéfinition de la page Branches et une nouvelle option pour effectuer une « fusion Squash ».

Nouvelle page Branches

La page Branches a été complètement remodelée. Elle possède un tableau croisé dynamique d’exploration qui montre les branches que vous avez créées, celles vers lesquelles vous avez effectué un push ou celles que vous avez définies comme favorites (Figure 20) . Chaque branche affiche son état de build et de requête de tirage, ainsi que d’autres commandes telles que Supprimer. Si un nom de branche contient une barre oblique, comme dans « features/jeremy/fix-bug », il est représenté sous la forme d’une arborescence, ce qui facilite l’exploration d’une longue liste de branches. Si vous connaissez le nom de votre branche, vous pouvez la retrouver rapidement.

Pour plus d’informations sur les branches, consultez Manage branches (Gérer les branches).

Nouvelle expérience de demande Pull

L’expérience de demande Pull a fait l’objet d’importantes mises à jour dans cette version, avec l’arrivée de certaines fonctionnalités de comparaison vraiment puissantes, une nouvelle expérience d’ajout de commentaires et une interface utilisateur entièrement actualisée.

Pour plus d’informations, consultez Review code with Pull requests (Vérifier le code avec des demandes Pull).

Interface utilisateur repensée

Quand vous ouvrez une demande Pull, la nouvelle apparence saute aux yeux (Figure 21) . Nous avons réorganisé l’en-tête pour récapituler l’ensemble des états critiques et des actions, en les rendant accessibles à partir de tous les affichages de l’expérience.

Vue d'ensemble

La vue d’ensemble met désormais en évidence la description des demandes Pull et facilite plus que jamais l’envoi de commentaires (Figure 22) . Les événements et les commentaires apparaissent avec les éléments les plus récents en haut pour permettre aux réviseurs de voir les derniers commentaires et modifications au centre. Les stratégies, les éléments de travail et les réviseurs sont tous fournis en détail et réorganisés sous une forme plus claire et concise.

Fichiers

La nouvelle fonctionnalité la plus importante de cette version est la possibilité de voir les mises à jour antérieures d’une demande Pull (Figure 23) . Dans les versions préliminaires précédentes, nous avions lancé la possibilité de suivre correctement les commentaires à mesure des modifications apportées à une demande Pull. Toutefois, il n’est pas toujours facile de voir ce qui se passe entre les mises à jour. Dans la vue Fichiers, vous pouvez maintenant voir exactement ce qui a changé chaque fois que le nouveau code est envoyé à votre demande de tirage. Cela est très utile si vous avez envoyé des commentaires sur du code et que vous voulez voir exactement comment il a été modifié, indépendamment de toutes les autres modifications de la révision.

Mises à jour

Le nouvel affichage Mises à jour montre l’évolution de la demande de tirage au fil du temps (Figure 24) . Si la vue Fichiers montre comment les fichiers ont été modifiés au fil du temps, la vue Mises à jour montre les validations ajoutées à chaque mise à jour. Si une opération push forcée se produit, la vue Mises à jour continue de montrer les mises à jour antérieures à mesure qu’elles s’affichent dans l’historique.

Commentaires, désormais avec markdown et emoji

Utilisez la pleine puissance de Markdown dans toutes vos discussions, notamment la mise en forme, le code avec la coloration syntaxique, les liens, les images et les emoji (Figure 25) . Les contrôles de commentaires offrent également une expérience de modification conviviale qui permet de modifier (puis d’enregistrer) plusieurs commentaires en même temps.

Ajouter et supprimer des réviseurs dans les demandes Pull

Il est désormais plus facile d’ajouter et de supprimer des réviseurs de vos demandes de tirage. Pour ajouter un réviseur ou un groupe à votre requête de tirage, entrez simplement son nom dans la zone de recherche de la section Réviseurs. Pour supprimer un réviseur, pointez sur sa vignette dans la section Réviseurs et cliquez sur le signe X (Figure 26) .

Amélioration de la traçabilité des builds et des requêtes de tirage (Pull)

La traçabilité entre les builds et les requêtes de tirage a été améliorée, ce qui facilite la navigation entre une requête de tirage et une build, et inversement. Dans la vue Détails de la build relative à une build déclenchée par une requête de tirage, la source affiche maintenant un lien vers la requête de tirage qui a placé la build en file d’attente. Dans la vue Définitions de build, toute build déclenchée par une requête de tirage fournit un lien vers la requête de tirage dans la colonne « Déclenché(e) par ». Enfin, la vue Explorateur de builds répertorie les requêtes de tirage dans la colonne source.

Suivi des commentaires pour les demandes Pull

Les requêtes de tirage (Pull) dans VSTS ont été améliorées pour pouvoir afficher les commentaires laissés dans les fichiers à la ligne appropriée, même si ces fichiers ont été modifiés depuis l’ajout des commentaires. Auparavant, les commentaires restaient affichés sur la ligne du fichier dans lequel ils étaient ajoutés à l’origine, même si le contenu du fichier avait changé. Autrement dit, un commentaire à la ligne 10 était toujours affiché à la ligne 10. Avec les dernières améliorations, les commentaires suivent le code pour indiquer ce qui est attendu par l’utilisateur : si un commentaire est ajouté à la ligne 10, et si deux nouvelles lignes sont ajoutées par la suite au début du fichier, le commentaire s’affiche à la ligne 12.

Voici un exemple de changement avec un commentaire à la ligne 13 (Figure 27) :

Même après la modification du code pour déplacer la ligne avec le commentaire d’origine de la ligne 13 à la ligne 14, le commentaire apparaît à l’emplacement attendu à la ligne 14 (Figure 28) .

Saisie semi-automatique des demandes Pull en attente de stratégies

Les équipes qui utilisent des stratégies de branche pour protéger leurs branches vont être intéressées par l’action de saisie semi-automatique. Bien souvent, l’auteur d’une demande de tirage est prêt à fusionner celle-ci, mais il attend la fin d’une build pour pouvoir cliquer sur Terminer. Parfois, la build est validée, mais un réviseur n’a pas donné l’approbation finale. Dans ce cas, l’action de saisie semi-automatique permet à l’auteur de définir la demande Pull pour qu’elle soit automatiquement remplie dès que toutes les stratégies sont approuvées (Figure 29) .

Comme pour l’action de saisie manuelle, l’auteur a la possibilité de personnaliser le message de la validation de fusion et de sélectionner les options de fusion appropriées (Figure 30) .

Une fois la saisie semi-automatique définie, la demande Pull affiche une bannière qui confirme que la saisie semi-automatique est définie et qu’elle attend la fin des stratégies pour s’exécuter (Figure 31) .

Quand toutes les stratégies sont respectées (par exemple, la build est achevée ou l’approbation finale est accordée), la demande de tirage est fusionnée à l’aide des options et commentaires spécifiés. Comme prévu, en cas d’échec de la build, ou si le réviseur ne donne pas son approbation, la demande de tirage reste active jusqu’à ce que les stratégies soient validées.

Requêtes de tirage avec fusion avec « squash »

Quand vous exécutez une demande Pull, vous pouvez désormais effectuer une action squash merge (Figure 32) . Cette nouvelle option génère une validation unique qui contient les changements de la branche de rubrique appliquée à la branche cible. La différence la plus notable entre une fusion standard et une fusion avec « squash » est que la validation avec fusion avec « squash » comporte une seule validation parente. Le graphique d’historique s’en trouve simplifié, car les validations intermédiaires effectuées dans la branche de rubrique sont inaccessibles dans le graphique de validation résultant.

Pour plus d’informations, consultez Squash merge pull requests (Demandes Pull avec fusion avec « squash »).

Traçabilité des validations

L’état de la build (réussite ou échec) est désormais clairement visible dans les affichages Explorateur de code et Détails de la validation (Figure 33) . D’un simple clic, vous accédez à des détails supplémentaires. Ainsi, vous savez toujours si les changements présents dans la validation ont franchi avec succès la phase de build. Vous pouvez également décider quelles sont les builds qui peuvent publier l’état dans les options de dépôt pour la définition de build. En outre, les dernières modifications apportées à la vue Détails de la validation fournissent des informations plus précises sur vos modifications. Si vous utilisez des demandes de tirage pour fusionner vos changements, vous voyez le lien vers la demande de tirage à l’origine des changements dans la branche principale (ou dans le cas d’une validation de fusion, la demande de tirage qui l’a créée). Une fois que vos modifications ont atteint la branche principale, le lien de la branche s’affiche pour confirmer que les modifications ont été incluses.

Afficher des fichiers Git LFS sur le web

Si vous utilisez déjà des fichiers volumineux dans Git (audio, vidéo, jeux de données, etc.), vous savez que Git LFS (Large File Storage) remplace ces fichiers par des pointeurs dans Git, tout en stockant leur contenu sur un serveur distant. Cela permet d’afficher le contenu complet de ces fichiers volumineux en cliquant simplement sur le fichier dans votre dépôt.

Pour plus d’informations, consultez Manage large files with Git (Gérer les fichiers volumineux avec Git).

Créer et envoyer des liens vers des sections de code spécifiques

Partagez facilement des références de code avec des liens de code (Figure 34) . Sélectionnez simplement du texte dans un fichier et cliquez sur l’icône en forme de lien. Cette opération copie un lien vers le code sélectionné. Quand un utilisateur consulte ce lien, le code que vous avez mis en surbrillance a un arrière-plan doré. Ce dispositif fonctionne même pour les sélections de ligne partielle.

API d’état

La réussite ou l’échec de la build est désormais clairement visible dans les affichages Explorateur de code et Détails de la validation (Figure 35) . D’un simple clic, vous accédez à des détails supplémentaires. Ainsi, vous savez toujours si les changements présents dans la validation ont franchi avec succès la phase de build. Vous pouvez également décider quelles sont les builds qui peuvent publier l’état de la build dans les options de référentiel de la définition de build.

Icônes de type de fichier

Vous pouvez observer de nouvelles icônes de fichier correspondant à l’extension du fichier dans l’Explorateur, aux demandes Pull, aux détails de validation, au jeu de réservations, à l’ensemble de modifications ou à toute autre vue qui présente une liste de fichiers (Figure 36) .

Ajouter un fichier Readme pendant la création du dépôt

La création d’un dépôt Git a été améliorée en fournissant aux utilisateurs la possibilité d’ajouter un fichier Readme (Figure 37) . L’ajout d’un fichier Lisez-moi au dépôt permet non seulement aux autres utilisateurs de comprendre l’objectif de la base de code, mais aussi de cloner immédiatement le dépôt.

Améliorations apportées aux builds

Dans cette version, nous avons augmenté la taille des journaux, ajouté des modèles de build Java et apporté des améliorations à la prise en charge de Xamarin, entre autres choses.

Onglet File d’attente de builds repensé

Nous avons implémenté une nouvelle conception de la page Builds en file d’attente qui affiche de façon plus intuitive une liste plus longue des builds en file d’attente et des builds en cours d’exécution (Figure 38) .

Pour plus d'informations, consultez Administer your build system (Administrer votre système de génération).

Activer les extensions de résultats de build pour spécifier l’ordre et la colonne

Les extensions des sections des résultats de build peuvent désormais spécifier la colonne et l’ordre dans lequel ceux-ci apparaissent (Figure 39) . L’affichage des résultats comporte deux colonnes. Toutes les extensions se trouvent dans la première colonne par défaut. Remarque : Toutes les extensions tierces apparaissent après les sections des résultats de build que nous incluons.

De la build vers un numéro de ligne

Vous pouvez maintenant accéder directement à la ligne de code qui a engendré une erreur de build spécifique. La dernière erreur sur la build principale utilisée en interne comme stratégie de demande Pull révèle ceci (Figure 40) :

La vue du journal de génération prend en charge des journaux beaucoup plus volumineux

La vue de journal précédente ne prenait en charge que les journaux comportant jusqu’à 10 000 lignes. La nouvelle visionneuse est basée sur l’éditeur Monaco utilisé dans VS Code et prend en charge les journaux comportant jusqu’à 150 000 lignes.

Modèles de build Java

Nous avons simplifié la tâche aux développeurs Java qui souhaitent se familiariser avec le processus de génération en ajoutant des modèles de build pour Ant, Maven et Gradle (Figure 41) .

Pour plus d'informations sur les modèles, consultez Build steps (Étapes de génération).

Tâches de build Xamarin

Nous avons apporté des améliorations significatives à la prise en charge de Xamarin :

• L’étape Xamarin.Android prend désormais en charge Mac et Linux.
• L’étape Xamarin.iOS étape prend désormais en charge la signature et l’empaquetage.
• Les résultats Xamarin Test Cloud peuvent être affichés dans la page de résumé de la build.
• Une nouvelle étape de restauration de composant Xamarin a été ajoutée.
• L’étape Programme d’installation de NuGet prend désormais en charge Mac OS.

L’étape de licence Xamarin n’est plus nécessaire et a été supprimée des modèles de build. Dans le cadre de cet effort, nous déprécions la tâche. Toutes les définitions de build qui utilisent cette tâche doivent être mises à jour afin de la supprimer pour éviter toute interruption quand la tâche sera effectivement supprimée.

Enfin, nous avons amélioré les modèles de définition de build Xamarin pour permettre l’utilisation de ces nouvelles tâches. Générez votre application Xamarin.

Intégration de Docker pour la gestion des builds et des versions

Tirez parti des fonctionnalités de build pour générer vos images Docker et les charger sur le hub d’ancrage dans le cadre de votre flux d’intégration continue (Figure 42) . Ensuite, déployez ces images sur une série d’hôtes Docker dans le cadre de la gestion des versions. L’extension Marketplace ajoute tous les types de point de terminaison de service et tâches nécessaires à l’utilisation de Docker.

Résultats SonarQube dans la vue de requête de tirage

Si la build exécutée pour fusionner une demande Pull contient des tâches SonarQube MSBuild, de nouveaux problèmes d’analyse de code en tant que commentaires de discussion apparaissent dans la demande Pull (Figure 43) . Cette expérience vaut pour tout langage pour lequel un plug-in est installé sur le serveur SonarQube. Pour plus d’informations, consultez le billet de blog SonarQube Code Analysis issues integration into Pull Requests (Intégration des problèmes d’analyse de code SonarQube aux requêtes de tirage).

Configurer le signalement de l’état d’une définition de build à l’API

Vous pouvez maintenant choisir les définitions de build qui signalent leur état à l’API d’état Git. Cette fonctionnalité est particulièrement utile si de nombreuses définitions génèrent une branche ou un dépôt donné, alors qu’une seule représente l’état d’intégrité réel.

Pour plus d’informations, consultez Buid REST API reference (Informations de référence sur l’API REST de génération).

Prise en charge de Build vNext dans les salles d’équipe

Il a toujours été possible d’ajouter les notifications des builds XAML dans la salle d’équipe. Avec ce sprint, les utilisateurs peuvent également recevoir des notifications en provenance des réalisations Build vNext.

Activer les filtres de chemin pour les déclencheurs de CI Git

Les déclencheurs CI des dépôts Git hébergés peuvent inclure ou exclure certains chemins. Cela vous permet de configurer une définition de build à exécuter uniquement quand les fichiers de chemins spécifiques ont été modifiés (Figure 44) .

Améliorations apportées à Release Management

Depuis l’introduction de la gestion des mises en production web intégrée dans Team Foundation Server 2015, nous avons apporté plusieurs améliorations à cette version.

Cloner, exporter et importer des définitions de mise en production

Nous avons incorporé la possibilité de cloner, d’exporter et d’importer des définitions de mise en production dans le hub Mise en production, sans avoir à installer d’extension (Figure 45) .

Pour plus d’informations, consultez Cloner, exporter et importer une définition de mise en production.

Résultats des tests affichés dans le résumé de mise en production

Dans la page de résumé de mise en production, nous avons activé un point de contribution pour un service externe afin d’afficher les informations spécifiques de l’environnement.

Dans Team Services, cette fonctionnalité est utilisée pour afficher un résumé des résultats des tests quand les tests sont exécutés dans le cadre d’un environnement de mise en production (Figure 46) .

Pour plus d’informations, consultez Understand the summary view of a release (Présentation de l’affichage résumé d’une mise en production).

Passer des jetons OAuth aux scripts

Si vous avez besoin d’exécuter un script PowerShell personnalisé qui appelle les API REST sur Team Services, par exemple pour créer un élément de travail ou interroger une build pour plus d’informations, vous devez passer le jeton OAuth dans le script.

Quand vous configurez un environnement, une nouvelle option permet aux scripts de s’exécuter comme des tâches dans l’environnement pour accéder au jeton OAuth actuel (Figure 47) .

Pour plus d’informations, consultez Environment general options (Options générales de l’environnement).

Il s’agit d’un exemple simple illustrant la procédure d’obtention d’une définition de build (Figure 48) :

Déclencher des déploiements partiellement réussis

Chaque tâche de génération et de mise en production dispose d’une option Continuer en cas d’erreur dans les paramètres Options de contrôle.

Dans une définition de build, cette option génère un résultat Build partiellement réussie en cas d’échec d’une tâche définie avec cette option.

Le même comportement est maintenant disponible dans les définitions de mise en production. Si une tâche échoue, le résultat global de la mise en production indique « Mise en production partiellement réussie » (Figure 49) .

Par défaut, une mise en production partiellement réussie ne déclenche pas automatiquement une mise en production dans un environnement ultérieur, même si ce comportement est spécifié dans les options de déploiement de l’environnement.

Toutefois, une nouvelle option peut être définie dans chaque environnement de mise en production pour indiquer à Release Management de déclencher une mise en production dans un environnement ultérieur quand la mise en production précédente est partiellement réussie (Figure 50) .

Pour plus d’informations, consultez Environment deployment triggers (Déclencheurs de déploiement de l’environnement).

Consommer des artefacts enregistrés directement dans GitHub

Vous pouvez parfois être amené à consommer des artefacts stockés directement dans un système de gestion de version, sans les transmettre par l’intermédiaire d’un processus de génération, comme décrit dans cette rubrique.

Vous pouvez maintenant faire la même chose si votre code est stocké dans un dépôt GitHub (Figure 51) .

Pour plus d’informations, consultez TFVC, Git, and GitHub sources (Sources TFVC, Git et GitHub).

Déploiement d’applications web à l’aide d’ARM

Une nouvelle version de la tâche de déploiement d’application web Azure est disponible, sous le nom de déploiement d’application web AzureRM.

Elle utilise MSDeploy et une connexion de point de terminaison du service Azure Resource Manager. Cette tâche permet de déployer des tâches web Azure et des applications Azure API, en plus des applications web ASP.NET 4, Node et Python.

La tâche prend également en charge les options de publication courantes comme la possibilité de conserver les données d’application, de prendre une application hors ligne et de supprimer des fichiers supplémentaires dans la destination.

D’autres fonctionnalités, comme les transformations de configuration, peuvent apparaître dans les versions à venir (Figure 52) .

Groupes de tâches

Un groupe de tâches vous permet d’encapsuler une séquence de tâches déjà définie dans une définition de build ou de mise en production au sein d’une seule tâche réutilisable qui peut être ajoutée à une définition de build ou de mise en production comme toute autre tâche (Figure 53) .

Vous pouvez choisir d’extraire les paramètres de tâches encapsulées comme des variables de configuration et de faire abstraction du reste des informations de tâches.

Le nouveau groupe de tâches est automatiquement ajouté au catalogue de tâches, prêt à être ajouté à d’autres définitions de build et de mise en production.

Pour plus d’informations, consultez Task Groups (Groupes de tâches).

Suppression réversible de mises en production

Quand vous supprimez une mise en production, elle est supprimée automatiquement par une stratégie de rétention ou elle est supprimée dans les listes de présentation et de détails.

Toutefois, elle est conservée avec la définition de mise en production pendant un certain laps de temps (généralement 14 jours) avant d’être définitivement supprimée.

Pendant cette période, elle est affichée sous l’onglet Supprimé des listes de présentation et de détails.

Vous pouvez restaurer l’une de ces versions en ouvrant le menu contextuel et en choisissant Annuler la suppression(Figure 54).

Pour plus d’informations, consultez Restore deleted releases (Restaurer les mises en production supprimées).

Conserver des mises en production et des builds pour chaque environnement

La stratégie de rétention de mise en production pour une définition de mise en production détermine la durée de rétention d’une mise en production et de la build liée.

Par défaut, une mise en production est conservée pendant 60 jours. Les mises en production qui n’ont pas été déployées ou modifiées durant cette période sont automatiquement supprimées.

Toutefois, vous pouvez conserver plusieurs mises en production qui ont été déployées dans des environnements spécifiques, comme votre environnement de production, ou les conserver plus longtemps que celles qui ont été seulement déployées dans d’autres environnements comme les environnements de test, intermédiaire et d’assurance qualité.

Vous pouvez également conserver la build liée à une mise en production pendant la même période que la mise en production pour vous assurer que les artefacts sont disponibles si vous avez besoin de redéployer cette mise en production (Figure 55) .

Pour plus d’informations, consultez Release and build retention (Rétention de builds et de mises en production).

Améliorations apportées à l’artefact lié

Deux nouvelles fonctionnalités facilitent l’utilisation des artefacts et des sources d’artefact :

• Vous pouvez lier plusieurs sources d’artefact à une définition de mise en production (Figure 56) . Chaque artefact est téléchargé dans un dossier de l’agent, qui se nomme alias source. Vous pouvez maintenant modifier l’alias source d’un artefact lié. Par exemple, quand vous modifiez le nom de la définition de build, vous pouvez modifier l’alias source pour refléter le nom de la définition de build.

Pour plus d’informations, consultez la documentation [Alias source d’artefact](/vsts/pipelines/release/artifacts ?preserve-view=true&view=vsts#source-alias).

• Un certain nombre de variables du format Build.* (par exemple, Build.BuildId et Build.BuildNumber) sont exposées pour une utilisation dans les paramètres de tâche. Quand plusieurs sources sont associées à une mise en production, ces variables sont désormais remplies avec les valeurs de la source d’artefact que vous spécifiez en tant que source principale. Pour plus d’informations, consultez Artifact variables (Variables d’artefact).

Déploiement - tâche d’intervention manuelle

Vous pouvez désormais suspendre l’exécution pendant le déploiement dans un environnement.

En incluant une tâche d’intervention manuelle dans un environnement, vous pouvez temporairement arrêter un déploiement, effectuer des étapes manuelles, puis reprendre des étapes supplémentaires automatisées.

Vous pouvez également refuser le déploiement et empêcher l’exécution d’étapes supplémentaires après une intervention manuelle (Figure 57) .

Pour plus d’informations, consultez Manual intervention (Intervention manuelle).

Scripts des tâches de déploiement SQL Database

La tâche déploiement de base de données Azure SQL(Figure 58) a été améliorée pour exécuter des scripts SQL sur une base de données Azure SQL. Les scripts peuvent être fournis sous forme de fichier ou insérés dans la tâche.

Résumé de la définition de mise en production - widget du tableau de bord

Épingler une définition de mise en production sur le tableau de bord constitue un moyen simple de rendre visible un résumé des mises en production correspondant à cette définition pour toute votre équipe.

Pour plus d’informations, consultez Add release information to the dashboard (Ajouter des informations de mise en production au tableau de bord).

Promouvoir des mises en production dans un environnement à un moment donné

Vous voulez que tous vos déploiements de production aient lieu à minuit ? Vous pouvez configurer une condition sur un environnement qui sélectionne un déploiement réussi (ou simplement le plus récent) à partir d’un autre environnement, puis le déploie à l’heure spécifiée (Figure 59) .

Déployer selon des conditions dans plusieurs environnements

Jusqu’à la version précédente, vous pouviez effectuer des déploiements en parallèle (bifurcation de déploiements), mais vous ne pouviez pas démarrer un déploiement dans un environnement en fonction de l’état de plusieurs environnements (jonction de déploiements). Maintenant, vous pouvez.

Pour plus d’informations, consultez Parallel forked and joined deployments (Bifurcation et jonction de déploiements en parallèle).

API REST pour Release Management

Vous pouvez utiliser les API REST du service Release Management pour créer des définitions de mise en production et des mises en production, ainsi que pour gérer de nombreux aspects du déploiement d’une mise en production.

Pour plus d’informations, consultez la documentation de référence sur les API.

Intégration des raccordements de services

Envoyez des notifications de mise en production quand de nouvelles mises en production sont créées, des déploiements sont démarrés ou terminés, ou bien quand des approbations sont en attente ou terminées. Intégrez des outils tiers tels que Slack pour recevoir ces notifications.

Déploiement sur des clouds Azure nationaux

Utilisez le nouveau paramètre Environnement dans un point de terminaison de service Azure Classic pour cibler un cloud Azure en particulier, dont des clouds nationaux prédéfinis comme le cloud Azure China, le cloud Azure US Government et le cloud Azure German (Figure 60) .

Pour plus d’informations, consultez Azure Classic service endpoint (Point de terminaison du service Azure Classic).

Améliorations apportées aux tests

Des améliorations de test importantes ont été ajoutées à Team Foundation Server 2017.

Mis à jour du schéma de stockage des résultats de test

Dans cette version, nous migrons les artefacts de résultat de test vers un nouveau schéma de stockage compact et efficace. Comme les résultats des tests sont particulièrement gourmands en espace de stockage dans les bases de données TFS, nous pensons que cette fonctionnalité peut réduire l’encombrement du stockage pour les bases de données TFS. Pour les clients qui effectuent une mise à niveau à partir de versions antérieures de TFS, les résultats de test sont migrés vers le nouveau schéma pendant la mise à niveau de TFS. La quantité de données de résultat de test contenues dans vos bases de données peut avoir une incidence sur la durée de cette mise à niveau. Il est conseillé de configurer la stratégie de rétention des et d’attendre que la stratégie démarre et réduise le stockage utilisé par les résultats des tests afin que la mise à niveau TFS soit plus rapide. Après avoir installé TFS, mais avant de mettre à niveau l’instance TFS, vous pouvez utiliser TFSConfig.exe pour propre les résultats des tests. Consultez l’aide de TFSConfig.exe pour plus d’informations. Si vous ne pouvez pas configurer la rétention de test, ni nettoyer les résultats des tests avant la mise à niveau, planifiez la fenêtre de la mise à niveau de manière adaptée. Consultez Rétention des données de test avec Team Foundation Server 2015 pour plus d’exemples sur la configuration de la stratégie de rétention des tests.

Améliorations apportées au hub Test

Gestion de la configuration des tests dans le hub Test

Nous avons intégré la gestion de la configuration de test à l’IU web en ajoutant un nouvel onglet Configurations au hub de test (Figure 61) . Vous pouvez désormais créer et gérer des configurations de test et tester des variables de configuration à partir de hub Test.

Pour plus d’informations, consultez Create configurations and configuration variables (Créer des configurations et des variables de configuration).

Assignation de configurations aux plans de test, suites de tests et cas de test

L’assignation de configurations est devenue encore plus simple. Vous pouvez assigner des configurations de test à un plan de test, à une suite de tests ou à un ou plusieurs cas de test, directement à partir du hub de test (Figure 62) . Cliquez avec le bouton droit sur un élément, sélectionnez Assigner des configurations à, et vous voilà opérationnel. Vous pouvez également filtrer par configurations dans le hub Test (Figure 63) .

Pour plus d’informations, consultez Assign configurations to Test plans and Test suites (Attribuer des configurations à des plans de test et des suites de tests).

Afficher les colonnes de plan de test/suite de tests dans le volet Résultats des tests

Nous avons ajouté de nouvelles colonnes au volet Résultats des tests, qui montrent le plan de test et la suite de tests dans lesquels les résultats des tests ont été obtenus. Ces colonnes fournissent un contexte très utile pour explorer les résultats de vos tests (Figure 64) .

Tri des tests dans le hub Test et dans les cartes

Vous pouvez désormais trier les tests manuels à partir du hub de test (Figure 65) , quel que soit le type de suite dans lequel ils sont inclus : suites statiques, suites basées sur des exigences ou suites basées sur des requêtes. Pour réorganiser les tests, il vous suffit de faire glisser et déposer un ou plusieurs tests ou d’utiliser le menu contextuel. Une fois la réorganisation terminée, vous pouvez trier vos tests en fonction du champ Ordre et les exécuter dans cet ordre à partir de l’outil web Test Runner. Vous pouvez également trier les tests directement sur une carte de récit utilisateur dans le tableau Kanban (Figure 66) .

Trier les suites de tests dans le hub Test

Les équipes de test peuvent désormais classer dans l’ordre les suites de tests en fonction de leurs besoins. Auparavant, les suites étaient uniquement classées par ordre alphabétique. À présent, par un simple glisser-déplacer dans le hub Test, les suites de tests peuvent être réorganisées dans leurs suites homologues ou déplacées vers une autre suite dans la hiérarchie (Figure 67) .

Recherche d’utilisateurs dans le cadre de l’affectation des testeurs

Avec le lancement de nouveaux contrôles de sélecteur d’identité parmi les différents hubs, dans le hub Test, nous avons également activé l’option de recherche d’utilisateurs pendant l’affectation de testeurs à un ou plusieurs tests (Figure 68) . Cela s’avère particulièrement utile dans les scénarios où le nombre de membres d’équipe est important, alors que le menu contextuel affiche uniquement un ensemble limité d’entrées *(Figure 69).

Sélectionner une build pour le test

Vous pouvez désormais sélectionner la « build » à tester, puis lancer l’exécuteur web à l’aide de l’option « Exécuter avec des options » dans le hub de test (Figure 70) . Tout bogue que vous avez entré pendant l’exécution est automatiquement associé à la build sélectionnée. De plus, le résultat du test est publié par rapport à cette build spécifique.

Lancer le client Microsoft Test Runner à partir du hub Test avec des collecteurs de données

Vous pouvez désormais choisir vos collecteurs de données et la build à associer à la série de tests (Figure 71) , puis lancer Microsoft Test Runner 2017 (client) de façon performante à partir du hub Test sans avoir à les configurer dans le client Microsoft Test Manager. Microsoft Test Runner se lance sans ouvrir l’intégralité de l’interpréteur de commandes de Microsoft Test Manager, puis s’arrête à la fin de l’exécution du test.

Pour plus d'informations, consultez Run tests for desktop apps (Exécuter des tests pour des applications de bureau).

Choisir des collecteurs de données et lancer le client Exploratory Runner à partir du hub Test

Vous pouvez désormais choisir vos collecteurs de données et lancer le client Exploratory Runner 2017 de façon performante à partir du hub Test, sans avoir à les configurer dans le client Microsoft Test Manager. Appelez « Exécuter avec des options » dans le menu contextuel (Figure 72) pour une suite basée sur des exigences et choisissez Exploratory Runner ainsi que les collecteurs de données dont vous avez besoin. Exploratory Runner se lance de la même façon que Microsoft Test Runner, comme décrit ci-dessus.

Configurer les résultats de tests pour différentes suites de tests

Nous avons ajouté la possibilité de configurer le comportement des résultats des tests partagés entre différentes suites de tests sous le même plan de test (Figure 73) . Si cette option est sélectionnée et que vous définissez le résultat d’un test (que vous le marquez comme Réussite/Échec/Bloqué à partir du hub Test, de l’exécuteur web, de Microsoft Test Runner ou de cartes sur le tableau Kanban), ce résultat est propagé à tous les autres tests présents dans différentes suites de tests sous le même plan de test, avec la même configuration. Les utilisateurs peuvent définir l’option « Configurer les paramètres de résultat de test » pour un plan de test particulier dans le menu contextuel Plan de test du hub de test, ou à partir de la page de test du tableau Kanban dans la boîte de dialogue de configuration des paramètres communs. Cette option est désactivée par défaut et vous devez l’activer explicitement pour qu’elle prenne effet.

Vérifier les bogues à partir de l’élément de travail

Vous pouvez désormais vérifier un bogue en réexécutant les tests qui l’ont identifié (Figure 74) . Vous pouvez appeler l’option Vérifier dans le menu contextuel du formulaire d’élément de travail bogue pour lancer le cas de test approprié dans l’exécuteur web. Effectuez votre validation à l’aide de l’exécuteur web et mettez à jour l’élément de travail bogue directement dans l’exécuteur web.

API REST pour le clonage des plans de test / suites de tests

Nous avons ajouté des API REST pour le clonage des plans de test et des suites de tests. Vous pouvez les trouver dans la section Test management (Gestion des tests )sur notre site à la page Team Services > Integrate (Team Services > Intégration).

Tester la progression à partir de vos cartes Kanban

Vous pouvez maintenant ajouter, afficher et exploiter des cas de test directement à partir de vos récits sur le tableau Kanban. Utilisez la nouvelle option de menu Ajouter un test pour créer un cas de test lié, puis surveillez l’état directement à partir de la carte en continu (Figure 75) .

Grâce à cette nouvelle fonctionnalité, vous pouvez effectuer les actions suivantes directement à partir d’une carte sur votre tableau :

• Ajouter des tests.
• Ouvrir des tests.
• Réapparenter un test en effectuant un glisser/déplacer depuis un récit utilisateur vers un autre.
• Copier un test vers un autre récit utilisateur à l’aide de la touche Ctrl associée à une opération glisser/déplacer (si le même cas de test teste plusieurs récits utilisateur).
• Mettre à jour l’état de test en le marquant rapidement comme ayant réussi, échoué, etc.
• Exécuter le test dans l’outil web Test Runner, où vous pouvez déterminer l’issue (réussite ou échec) des différentes étapes, archiver des bogues, etc.
• Afficher un résumé de l’état cumulatif indiquant combien de tests ont réussi et combien il en reste pour le récit concerné.

Si vous avez besoin de fonctionnalités de gestion de test avancées (par exemple, pour affecter des testeurs, assigner des configurations, utiliser des paramètres centralisés ou exporter les résultats des tests), vous pouvez basculer vers le hub Test et commencer à utiliser les suites de plans de tests ou basées sur des spécifications par défaut qui ont été automatiquement créées pour vous. Pour plus d’informations, consultez Add, run, and update inline tests (Ajouter, exécuter et mettre à jour des tests inline).

Accéder à un plan de test/une suite de tests à partir de la carte

Vous pouvez désormais facilement parcourir le plan de test/la suite de tests sous lesquels les tests sont créés, directement depuis une carte dans le tableau Kanban. En cliquant sur ce lien (Figure 76) , vous accédez au hub Test, ouvrez le bon plan de test et sélectionnez la suite spécifique qui contrôle ces tests inline.

Page Tests dans la configuration des paramètres communs du tableau Kanban

La nouvelle page Tests de la boîte de dialogue de configuration des paramètres communs du tableau Kanban vous permet de contrôler le plan de test où les tests inline sont créés (Figure 77) . Auparavant, les tests créés sur une carte étaient automatiquement ajoutés à un nouveau plan de test créé s’il n’en existait aucun correspondant aux chemins de zone et d’itération de la carte. Désormais, vous pouvez remplacer ce comportement en configurant un plan de test existant de votre choix. Tous les tests sont ajoutés au plan de test sélectionné. Notez que cette fonctionnalité est activée uniquement si l’annotation Test est activée.

Améliorations apportées à l’exécuteur web

Ajouter des pièces jointes d’étapes de test pendant un test manuel

Nous avons amélioré l’outil web Test Runner pour que vous puissiez ajouter des pièces jointes d’étapes de test pendant un test manuel (Figure 78) . Ces pièces jointes de résultats d’étape s’affichent automatiquement dans les bogues que vous archivez pendant la session et, ensuite, dans le volet Résultats des tests.

Capture d’écran, enregistrement d’écran, journal des actions en images et prise en charge des informations système dans l’exécuteur web (à l’aide du navigateur Chrome)

Vous pouvez désormais effectuer des captures d’écran et les annoter inline à l’aide de l’exécuteur web dans Chrome (Figure 79) . Vous pouvez aussi capturer à la demande des enregistrements d’écran des applications web, mais aussi de vos applications de bureau. Ces captures d’écran et enregistrements d’écran sont automatiquement ajoutés à l’étape de test actuelle. En plus des captures d’écran et des enregistrements d’écran, vous pouvez capturer le journal des actions en images à la demande à partir de vos applications web. Vous devez spécifier la fenêtre du navigateur dans laquelle capturer vos actions. Toutes les actions dans cette fenêtre (tous les onglets existants ou nouveaux que vous ouvrez dans cette fenêtre) ou toutes les nouvelles fenêtres enfants de navigateur que vous lancez sont automatiquement capturées et mises en corrélation avec les étapes de test en cours dans l’exécuteur web. Ces captures d’écran, enregistrements d’écran et journaux des actions en images sont ensuite ajoutés aux bogues que vous archivez pendant l’exécution, puis joints au résultat du test actuel. De même, les données sur les informations système sont automatiquement capturées et incluses dans le cadre des bogues que vous archivez à partir de l’outil web Test Runner. Ces fonctionnalités tirent parti de l’extension Chrome Test & Feedback.

Pour plus d’informations, consultez Collect diagnostic data during tests (Collecter des données de diagnostic pendant les tests).

Bogues archivés sous forme d’enfants – Exécuteur web/Extension Test Feedback

Quand vous exécutez des tests dans l’outil web Test Runner, à partir d’une carte sur le tableau ou d’une suite basée sur des spécifications dans le hub Test, tous les nouveaux bogues archivés sont désormais automatiquement créés en tant qu’enfant du récit utilisateur concerné. De même, si vous explorez un récit utilisateur à partir de l’extension de tests exploratoires, tous les bogues que vous entrez sont également créés en tant qu’enfants de ce récit utilisateur. Ce nouveau comportement simplifie la traçabilité entre les récits et les bogues. Cela s’applique uniquement si le paramètre « Gestion des bogues » de la page de configuration des paramètres communs a pour valeur « Les bogues n’apparaissent pas dans les backlogs ou les tableaux » ou « Les bogues apparaissent dans les backlogs et les tableaux avec des tâches ». Pour tous les autres paramètres de l’option « Gestion des bogues » et dans certains autres scénarios, par exemple l’ajout à un bogue existant ayant déjà un parent défini, un lien Associé est créé à la place.

Mettre à jour les bogues existants à partir de l’exécuteur web

À partir de l’exécuteur web, en plus de la création de bogues, vous pouvez aussi maintenant mettre à jour un bogue existant (Figure 80) . L’ensemble des données de diagnostic collectées, des étapes de reproduction et des liens pour la traçabilité de la session active est automatiquement ajouté au bogue existant.

Extension Test Feedback - améliorations

L’extension Test & Feedback basée sur un navigateur peut être installée à partir de Visual Studio Marketplace. Elle prend en charge Visual Studio Team Services et Team Foundation Server (2015 ou versions ultérieures).

Explorer les éléments de travail

Vous pouvez désormais procéder à des tests exploratoires pour un élément de travail spécifique (Figure 81) . Vous pouvez associer l’élément de travail sélectionné à la session de test en cours et afficher les critères d’acceptation et la description dans l’extension. L’extension crée par ailleurs une traçabilité complète entre les bogues ou les tâches que vous archivez sur l’élément de travail sélectionné. Vous pouvez explorer l’élément de travail directement à partir d’un élément de travail ou à partir de l’extension :

• Directement à partir d’un élément de travail (Figure 81) : lancez une session de test exploratoire pour un élément de travail spécifique directement à partir du produit à l’aide de l’option « Effectuer des tests exploratoires » dans le menu contextuel. Nous avons ajouté des points d’entrée sur toutes les cartes, toutes les grilles et dans le hub de test.

• Dans l’extension (Figure 82) : recherchez un élément de travail à partir de la session XT, puis associez-le à la session en cours.

Pour plus d’informations, consultez Explore work items with the Test & Feedback extension (Explorer des éléments de travail avec l’extension Test & Feedback).

Capturer le journal des actions en images, les enregistrements d’écran et les données de chargement de page web à l’aide de Test Feedback

Journal des actions en images : l’extension vous offre une nouvelle option pour ajouter les étapes qui ont conduit au bogue automatiquement et d’un simple clic. Sélectionnez l’option « Activer le journal des actions en images » (Figure 83) pour capturer les actions liées à la souris et au clavier, ainsi que les actions tactiles, puis ajouter le texte et les images correspondants directement au bogue ou à la tâche.

Enregistrement d'écran en tant que vidéo : Vous pouvez également capturer des enregistrements à l’écran à la demande à l’aide de l’extension. Vous pouvez capturer ces enregistrements à l’écran à partir d’applications web, mais également de vos applications de bureau. Vous pouvez configurer l’extension pour arrêter automatiquement les enregistrements d’écran et les joindre à un bogue que vous êtes en train d’entrer, à l’aide de la page « Options » de l’extension.

Données de chargement de page : nous avons ajouté une nouvelle fonctionnalité de capture en arrière-plan à l’extension. Il s’agit de la capture des données de « chargement de page web ». Tout comme le « journal des actions d’image » capture vos actions effectuées sur une application web en cours d’exploration, sous la forme d’images en arrière-plan, la fonctionnalité de « chargement de page » capture automatiquement les détails d’une page web pour effectuer l’opération de chargement. Au lieu de compter sur la lenteur subjective/perçue du chargement de la page web, vous pouvez maintenant quantifier de façon objective la lenteur dans le bogue. Une fois que le bogue est archivé, en plus de l’affichage en mosaïque, un rapport détaillé est également joint au bogue, lequel peut aider le développeur dans son ensemble initial d’investigations.

Créer des cas de test en fonction des données du journal des actions en images

Quand vous créez des cas de test pendant la session exploratoire, les étapes de test avec des images sont automatiquement remplies (Figure 84) . La conception et l’exécution simultanées de tests sont la base d’un véritable test exploratoire, concrétisé par cette nouvelle fonctionnalité. Vous pouvez modifier le texte capturé, ajouter le résultat attendu, désactiver les lignes non pertinentes et enregistrer le cas de test en vue de futures passes/séries de tests.

Pour plus d’informations, consultez Create test cases based in image action log data (Créer des cas de test basés sur les données du journal des actions en images).

Informations sur les sessions de test exploratoire

Vous pouvez maintenant afficher les sessions de tests exploratoires terminées, au niveau d’une équipe ou d’un individu, pendant une période donnée créée à l’aide de l’extension Test & Feedback. Vous pouvez accéder à cette page d’insights en cliquant sur le lien « Sessions exploratoires récentes » dans le hub de séries au sein du groupe Hub de test en mode d’accès au web. Cette nouvelle vue vous permet de tirer des informations significatives, notamment :

• Mode Résumé qui montre une répartition des éléments de travail explorés, des éléments de travail créés et des propriétaires de session, ainsi que le temps total passé dans ces sessions (Figure 85) .
• L’affichage par regroupement peut être réorganisé dynamiquement en fonction des éléments de travail explorés, des sessions ou des propriétaires de session. Pour tout tableau croisé dynamique, vous pouvez afficher la liste de tous les éléments de travail (bogues, tâches, cas de test) créés ou étendre la liste à un type d’élément de travail spécifique.
• Le volet de détails, qui affiche des informations en fonction de la sélection effectuée dans la vue avec regroupement. Quand vous sélectionnez une ligne dans un tableau croisé dynamique (par exemple des éléments de travail explorés), vous pouvez consulter les informations récapitulatives dans le volet de détails, telles que le nombre total de sessions, le temps total passé dans ces sessions, les propriétaires de la session qui ont exploré les éléments de travail et les bogues/tâches/cas de test créés, ainsi que leur état et priorité. Quand vous sélectionnez une ligne d’un élément de travail, vous pouvez consulter le formulaire de ce dernier inline et apporter les modifications appropriées.

Pour plus d’informations, consultez Get insights across your exploratory testing sessions (Obtenir des informations à partir de vos sessions de tests exploratoires).

Sessions de test exploratoire : Afficher des éléments de travail non explorés

Vous pouvez voir les détails de tous les éléments de travail explorés dans l’affichage des « sessions exploratoires récentes », filtré à l’aide de Toutes les sessions/Mes sessions pendant une période donnée. Nous avons ajouté une fonctionnalité qui vous permet de voir également la liste de tous les éléments de travail qui n’ont PAS été explorés, dans le même affichage (Figure 86) . Vous commencez par spécifier une requête partagée pour les éléments de travail qui vous intéressent et la page des sessions affiche la liste de tous les éléments de travail issus de la requête, en distinguant les éléments explorés des éléments non explorés dans la section récapitulative. De plus, à l’aide du sélecteur de regroupement « Élément de travail non exploré », vous pouvez voir la liste des éléments qui n’ont pas encore été explorés. Cela s’avère extrêmement utile pour déterminer combien de récits n’ont pas encore été explorés ou n’ont pas encore subi un dépistage de bogues.

Flux de commentaires des participants de bout en bout

Obtenir des commentaires

Les utilisateurs avec le niveau d’accès de base peuvent désormais obtenir directement des commentaires des participants concernant des fonctionnalités/récits en cours ou terminés à l’aide de l’option Obtenir des commentaires dans le menu de l’élément de travail (Figure 87) . Cette option ouvre le formulaire Obtenir des commentaires dans lequel vous pouvez choisir les parties prenantes dont vous souhaitez recueillir les impressions. Éventuellement, vous pouvez fournir un ensemble d’instructions simples permettant de désigner les zones du produit pour lesquelles vous souhaitez obtenir des commentaires. Cette opération envoie des messages individuels aux participants sélectionnés avec des instructions, le cas échéant.

Pour plus d’informations, consultez Request stakeholder feedback using the Test & Feedback extension (Obtenir les commentaires des participants à l’aide de l’extension Test & Feedback).

Fournir des commentaires

Les participants peuvent répondre à la demande de commentaires en cliquant sur le lien Fournir un commentaire dans le message reçu. Cette action configure automatiquement l’extension Test & Feedback (anciennement extension Tests exploratoires) avec la demande de commentaires sélectionnée (vous êtes invité à installer l’extension, si ce n’est pas déjà fait). Les participants peuvent ensuite utiliser toutes les fonctionnalités de capture de l’extension pour capturer leurs conclusions et envoyer leurs commentaires sous la forme d’éléments de travail réponse/bogue/tâche de commentaires. De plus, les parties prenantes peuvent accéder à la page « Demandes de commentaires » pour consulter au même endroit toutes les demandes de commentaires qu’elles ont reçues. Dans la liste, elles peuvent sélectionner la demande de commentaires à laquelle elles souhaitent répondre, gérer leurs « Demandes de commentaires en attente » (Figure 88) en les marquant comme étant traitées ou en les refusant. Elles peuvent également naviguer entre les différents types de demande de commentaires en cliquant sur la case d’option souhaitée (Figure 89) .

Pour plus d’informations, consultez Provide feedback using the Test & Feedback extension (Fournir des commentaires à l’aide de l’extension Test & Feedback).

Commentaires volontaires

En plus du flux sollicité mentionné ci-dessus, les participants peuvent également utiliser l’extension pour fournir des commentaires volontaires (Figure 90) . Elles peuvent ouvrir l’extension, sélectionner le mode « Connecté » dans la page Paramètres de connexion, puis se connecter au compte et au projet/à l’équipe pour lesquels elles souhaitent fournir des commentaires. Ils peuvent ensuite utiliser l’extension pour capturer leurs conclusions et envoyer leurs commentaires sous la forme d’éléments de travail réponse/bogue/tâche de commentaires.

Pour plus d’informations, consultez Provide voluntary feedback using the Test & Feedback extension (Fournir des commentaires volontaires à l’aide de l’extension Test & Feedback).

Améliorations des tests automatisés

Journaux de la console et durée du test sous l’onglet Tests dans le résumé de la build et le résumé de la mise en production

Les journaux de la console des résultats des tests qui sont capturés dans des fichiers .trx sont extraits et publiés en pièces jointes des résultats des tests (Figure 91) . Vous pouvez en afficher l’aperçu sous l’onglet Tests. Vous n’avez plus besoin de télécharger le fichier trx pour consulter les journaux.

Widget de tendance des tests pour les builds

Nous avons ajouté un nouveau widget, « Test result trend » (Tendance des résultats des tests), à la galerie de widgets (Figure 92) . Utilisez ce widget pour ajouter au tableau de bord un graphique de tendance des résultats de test illustrant au maximum les 30 dernières builds d’une définition de build. À l’aide des options de configuration des widgets, vous pouvez personnaliser le graphique en y incluant des tableaux croisés dynamiques relatifs, par exemple, au nombre de tests réussis, au nombre de tests ayant échoué, au nombre total de tests, au pourcentage de réussite et à la durée du test.

État de test avec résumé de l’environnement de mise en production

Il est recommandé d’utiliser des environnements de mise en production pour déployer des applications et les tester. Avec cette mise en production, nous avons intégré le taux de réussite du test des environnements de mise en production dans la section Environnements de la page de résumé de la mise en production (Figure 93) . Comme indiqué dans la capture d’écran, si un environnement a échoué, vous pouvez rapidement déduire si l’échec est dû à des tests qui échouent en consultant la colonne Tests. Vous pouvez cliquer sur le taux de réussite pour accéder à l’onglet Tests et examiner les tests ayant échoué pour cet environnement.

Historique des tests automatisés pour les branches et les environnements de mise en production

L’exécution d’un test individuel sur plusieurs branches, environnements et configurations est un scénario courant. En cas d’échec de ce genre de test, il est important de déterminer si le problème se limite aux branches de développement telles que la branche principale, ou s’il a également un impact sur les branches de mise en production déployées sur les environnements de production. Vous pouvez désormais visualiser l’historique d’un test sur les différentes branches qu’il teste en examinant l’onglet Historique dans la page de résumé des résultats (Figure 94) . De même, vous effectuez un regroupement à l’aide du sélecteur Environnement pour visualiser l’historique d’un test sur les différents environnements de mise en production dans lesquels il s’exécute.

Traçabilité avec le test continu

Les utilisateurs peuvent désormais suivre la qualité de leurs spécifications directement sur leur tableau de bord (Figure 95) . Nous avons déjà une solution liée à la qualité des spécifications pour nos utilisateurs de tests planifiés. Nous la mettons maintenant à la disposition de nos utilisateurs qui suivent le test continu. Les utilisateurs peuvent lier les tests automatisés directement aux exigences, puis utiliser les widgets de tableau de bord pour suivre la qualité des exigences dignes d’intérêt, en tirant (pull) les données de qualité de la build ou de la mise en production.

Test à distance - Distribuer des tests selon le nombre d’ordinateurs

Nous avons permis aux tests issus d’un assembly d’être distribués à des ordinateurs distants à l’aide de la tâche Exécuter les tests fonctionnels (Figure 96) . Dans TFS 2015, vous pouviez uniquement distribuer des tests au niveau de l’assembly. Pour activer la distribution, cochez la case correspondante dans la tâche, comme indiqué ci-dessous.

Test automatisé pour SCVMM et VMWare

Les utilisateurs peuvent configurer dynamiquement des ordinateurs de test dans le cloud avec Azure, ou localement avec SCVMM ou VMWare, et utiliser ces ordinateurs pour exécuter les tests de façon distribuée. Les utilisateurs peuvent utiliser une des tâches de configuration de machine (Azure, SCVMM ou VMWare), suivie de la tâche Exécuter les tests fonctionnels pour exécuter des tests.

Analyse SonarQube dans des tâches Maven et Gradle

Vous pouvez désormais déclencher une analyse SonarQube dans la tâche de génération Maven et Gradle en cochant « Exécuter une analyse SonarQube » et en fournissant le point de terminaison, le nom du projet SonarQube, la clé du projet et sa version (Figure 97) .

Vous obtenez désormais également un lien sur le projet SonarQube (Figure 98) . Vous pouvez demander une analyse complète pour afficher les détails des points de contrôle qualité et choisir d’arrêter la build s’ils ne sont pas respectés.

Pour plus d’informations, consultez The Gradle build task now supports SonarQube analysis (La tâche de génération Gradle prend désormais en charge l’analyse SonarQube).

Améliorations apportées à la Place de marché

Les administrateurs de collections de projets peuvent désormais parcourir la Place de marché Visual Studio à partir d’un serveur Team Foundation Server et installer des extensions gratuites dans une collection de projets d’équipe. Les extensions sont automatiquement téléchargées à partir de la Place de marché Visual Studio, chargées vers Team Foundation Server et installées dans la collection de projets d’équipe sélectionnée (Figure 99) .

Acheter et installer des extensions payantes

Les administrateurs de collections de projets peuvent désormais accéder à la Place de marché Visual Studio à partir d’un serveur Team Foundation Server, acheter des extensions payantes et les installer dans une collection de projets d’équipe sélectionnée (Figure 100) . L’administrateur peut acheter les extensions avec un abonnement Azure et sélectionner le nombre d’utilisateurs pour l’affectation de ces extensions. Ces extensions sont automatiquement téléchargées à partir de Visual Studio Marketplace, chargées dans Team Foundation Server et installées dans la collection de projets d’équipe sélectionnée.

Pour plus d’informations, consultez Get extensions for Team Foundation Server (Obtenir des extensions pour Team Foundation Server).

Améliorations apportées à l’administration

Authentification Windows

Dans les versions précédentes, vous deviez choisir entre les fournisseurs SSP (Security Support Provider) NTLM et Negotiate pour l’authentification Windows lors de la configuration d’un déploiement TFS joint au domaine. En 2017, nous avons supprimé ce paramètre de l’expérience de configuration. Si vous souhaitez continuer à utiliser l’authentification NTLM en 2017, vous n’avez rien à faire. Si vous utilisiez l’authentification Kerberos et souhaitez continuer en 2017, vous n’avez rien à faire. Désormais, TFS 2017 configure toujours les fournisseurs SSP Negotiate et NTLM, dans cet ordre. Avec cette configuration, l’authentification Kerberos est utilisée autant que possible, ce qui permet de renforcer la sécurité. Quand l’authentification Kerberos ne peut pas être utilisée, l’authentification NTLM est utilisée. Nous avons effectué des tests approfondis pour vérifier l’absence d’impact sur les déploiements TFS existants avec l’authentification NTLM en raison de cette modification.

Une expérience de navigation moderne

Dans cette version, nous mettons en place une nouvelle barre de navigation supérieure améliorée. Il existe deux principaux objectifs pour la nouvelle navigation :

• Améliorer l’efficacité de la navigation entre les zones de produit en vous permettant d’accéder rapidement à tous les hubs en un seul clic.
• Moderniser l’esthétique visuelle et l’expérience utilisateur.

Dans la mesure où il s’agit d’un grand changement pour nos utilisateurs, et la fonctionnalité étant toujours en cours d’itération, nous avons décidé de désactiver par défaut la nouvelle expérience utilisateur de navigation. Si vous souhaitez l’essayer, vous pouvez l’activer en accédant au Panneau de configuration de la zone d’administration de Team Foundation Server et en choisissant « Activer la nouvelle navigation ». Notez qu’elle est ensuite activée pour tous les utilisateurs sur le serveur.

Autorisation de renommer le projet d’équipe

L’autorisation qui détermine les utilisateurs pouvant renommer un projet d’équipe a été modifiée. Auparavant, les utilisateurs disposant de l’autorisation Modifier les informations au niveau du projet pour un projet d’équipe pouvaient renommer ce projet. Désormais, les utilisateurs peuvent se voir accorder ou refuser la possibilité de renommer un projet d’équipe par le biais de la nouvelle autorisation Renommer le projet d’équipe.

Hub de travail dans les paramètres d’administration

Nous avons introduit un nouveau hub « Travail » dans la page des paramètres d’administration, qui combine les paramètres généraux (Figure 101) , les itérations et les zones sous un seul onglet. Grâce à cette modification, les utilisateurs distinguent aisément les paramètres au niveau du projet des paramètres d’équipe. Concernant les paramètres d’équipe, les utilisateurs ne voient que les zones et itérations qui correspondent à leur équipe. Au niveau d’un projet, la page des paramètres permet aux administrateurs de gérer les zones et itérations pour l’ensemble du projet. En outre, pour les chemins de zone de projet, une nouvelle colonne nommée « Équipes » a été ajoutée pour que les administrateurs puissent déterminer rapidement et facilement les équipes qui ont sélectionné un chemin de zone spécifique.

API REST des configurations de processus

Cette API publique permet aux utilisateurs d’obtenir la configuration de processus d’un projet donné. La configuration de processus comprend les paramètres suivants :

• TypeFields : abstractions de champs personnalisables qui sont utilisés dans les outils Agile. Par exemple, le type du champ « Story points » est « Effort ».
• Définitions de backlog : définissent les types d’éléments de travail associés à chaque backlog. Il s’agit d’une API fréquemment demandée par les clients qui créent des extensions. Grâce à ces données, une extension peut savoir comment tirer parti des champs spécifiques d’un processus pour autoriser des scénarios courants dans les outils Agile (par exemple, modifier l’activité ou l’effort d’un élément de travail, savoir quels sont les éléments de travail inclus à un niveau donné du backlog ou déterminer si les équipes sont identifiées par chemin de zone ou par un champ personnalisé). Reportez-vous à Vue d’ensemble du travail pour plus d’informations.

Nouvelle expérience d’administration avec la recherche AD selon le préfixe

Team Foundation Server 2017 introduit une nouvelle expérience pour gérer les groupes et l’appartenance aux groupes. Vous pouvez rechercher dans Active Directory ou sur l’ordinateur local des utilisateurs/groupes à l’aide de critères de recherche basés sur un préfixe des noms d’utilisateur/de groupe. Par exemple, vous pouvez rechercher « Jean D » ou un nom de compte SAM (par exemple, « domaine d’entreprise\jeand ») pour consulter la carte de visite d’un utilisateur/groupe.

Paramètres de sécurité utilisateur

Vous pouvez gérer vos jetons d’accès personnels et SSH dans la nouvelle expérience « Ma sécurité » (Figure 102) . Les utilisateurs qui utilisaient « Mon profil » pour gérer SSH doivent désormais gérer leurs clés publiques SSH dans les paramètres de sécurité utilisateur (Figure 103) .

Assistant Configuration unifiée

Dans les mises en production précédentes, vous deviez sélectionner l’un des Assistants Configuration de votre déploiement TFS en fonction de vos intentions. Les Assistants de base et complet pouvaient servir à configurer un nouveau déploiement ; l’Assistant Mise à niveau pouvait être utilisé pour les mises à niveau de préproduction et de production. De plus, l’Assistant Couche Application uniquement pouvait être utilisé pour divers scénarios, notamment la montée en charge d’un déploiement existant, en remplaçant une couche Application par du nouveau matériel, et ainsi de suite. Dans TFS 2017, tous ces scénarios ont été unifiés dans un seul Assistant Configuration de serveur, qui vous guide tout au long de chacun de ces scénarios en vous demandant de faire des choix simples. De plus, les configurations avancées telles que les mises à niveau de préproduction et le clonage d’un déploiement existant automatisent désormais les actions qui s’effectuaient auparavant via tfsconfig.exe, notamment le changement des ID de serveur, le remappage des chaînes de connexion de base de données et la suppression des références à des dépendances externes (avec tfsconfig.exe PrepareClone).

Nouveau niveau d’accès

Avec l’ajout du nouveau groupe Visual Studio Enterprise au portail d’administration des niveaux d’accès dans Team Foundation Server, vous pouvez désormais identifier rapidement les utilisateurs qui disposent d’un abonnement Visual Studio Enterprise. Une fois identifiés, ces utilisateurs bénéficient d’un accès complet à toutes les extensions TFS installées à partir de Visual Studio Marketplace sans frais supplémentaires.

Jetons d’accès personnels

Vous pouvez maintenant vous connecter à Team Foundation Server à l’aide d’un jeton d’accès personnel en plus de SSH (Figure 104) . Un tel jeton s’avère utile si vous développez sur Linux ou Mac et que vous voulez utiliser des outils d’automatisation et GIT. Vous pouvez gérer vos jetons d’accès personnels à partir de la page des paramètres de sécurité utilisateur.

---

Problèmes connus

Voici la liste complète des problèmes connus dans cette mise en production.

Aucun outil Power Tools pour Team Foundation Server 2017

• Problème :

  Aucun outil Power Tools n’a été publié pour TFS 2017.

• Solution de contournement :

  Nous sommes heureux de vous informer que la plupart des outils Power Tools précédents ont été intégrés à TFS 2017. Malheureusement, l’éditeur de modèles de processus n’a pas été intégré, mais vous pouvez l’obtenir dans Visual Studio Marketplace.

Mise à jour des extensions de contrôle personnalisé

• Problème :

  Le schéma des champs du formulaire d’élément de travail a été modifié. La documentation sur les extensions de contrôle personnalisé a également été modifiée.

• Solution de contournement :

  Consultez la nouvelle documentation : Add a custom control to the work item form (Ajouter un contrôle personnalisé au formulaire d’élément de travail).

Erreur pendant l’importation de la définition du type d’élément de travail

• Problème :

  Les clients qui ont installé une extension de page d’élément de travail, qui exportent, puis importent une définition de type d’élément de travail, obtiennent une erreur : « L’attribut ‘LayoutMode’ n’est pas déclaré ».

• Solution de contournement :

  Il existe un attribut LayoutMode supplémentaire sur l’élément PageContribution chaque fois que vous exportez une définition de type d’élément de travail. Avant d’importer la définition, recherchez le mode PageContribution et supprimez l’attribut LayoutMode. Par exemple, supprimez LayoutMode="FirstColumnWide".

Les clients doivent effectuer la mise à jour vers Git LFS version 1.3.1 ou supérieure

• Problème :

  Les versions de Git LFS antérieures à 1.3.1 ne seront pas prises en charge dans les futures versions.

• Solution de contournement :

  Les clients qui utilisent Git LFS sont vivement encouragés à effectuer la mise à jour vers la version 1.3.1 de Git LFS ou version supérieure. Les versions antérieures du client LFS ne sont pas compatibles avec les modifications d’authentification dans cette version de TFS. Afin d’accorder du temps aux clients pour la migration, nous avons implémenté une solution de contournement à court terme pour RTW. La solution de contournement sera supprimée dans Update 1 et les clients Git LFS dont la version est antérieure à 1.3.1 ne fonctionneront plus.

NuGet Restore ne trouve pas les packages qui existent dans nuget.org

• Problème :

  Quand vous utilisez NuGet 3.4.3 ou une version ultérieure, la tâche NuGet Restore ne restaure pas les packages à partir de NuGet.org, sauf s’il s’agit d’une source explicite dans le fichier NuGet.Config.

• Solution de contournement :

  Vérifiez que NuGet.org se trouve dans NuGet.Config.

  <packageSources><add key="nuget.org » value= »https://api.nuget.org/v3/index.json" ; protocolVersion="3 »>
  </packageSources>

Les tâches de génération et de mise en production NuGet ne s’authentifient pas

• Problème :

  Quand vous utilisez Team Foundation Server/Package Management, les tâches de build et de mise en production NuGet ne s’authentifient pas auprès des flux si l’agent s’exécute en tant qu’utilisateur SERVICE RÉSEAU, ce qui correspond à la valeur par défaut quand l’agent de build s’exécute en tant que service. Cela se produit, car les versions NuGet antérieures à 3.5 utilisent les informations d’identification du compte d’utilisateur qui exécute l’agent de build, et non les informations d’identification fournies par la tâche de génération.

• Solution de contournement :

  Pour utiliser les tâches de génération/mise en production NuGet avec les flux TFS à l’aide d’un agent qui s’exécute en tant que SERVICE RÉSEAU, vous devez utiliser NuGet 3.5 ou version supérieure.

Les tâches de build/mise en production NuGet utilisent les informations d’identification de l’agent

• Problème :

  Les versions NuGet antérieures à 3.5 utilisent les informations d’identification du compte d’utilisateur qui exécute l’agent de build, et non les informations d’identification fournies par la tâche de génération. Cela peut entraîner un accès inattendu ou impossible aux flux.

• Solution de contournement :

  Utilisez NuGet 3.5 ou version supérieure sur les agents de build TFS.

Les extensions externes ne se mettent pas automatiquement à niveau pendant la mise à niveau de TFS

• Problème :

  Si vous avez téléchargé une extension à partir de Visual Studio Marketplace, si vous l’avez publiée sur votre installation TFS 2015 et si vous l’avez mise à niveau vers TFS 2017, elle n’est pas automatiquement mise à jour quand de nouvelles versions de l’extension sont publiées sur Marketplace.

• Solution de contournement :

  Après la mise à niveau vers TFS 2017, désinstallez les extensions que vous aviez installées dans TFS 2015. Réinstallez ensuite les extensions les plus récentes. Dans TFS 2017, nous avons ajouté une fonctionnalité permettant de rechercher automatiquement les extensions externes mises à jour une fois par jour et de les mettre à niveau.

La tâche de file d’attente Jenkins ne peut pas être exécutée dans des définitions de version

• Problème :

  Pendant l’exécution de la tâche de file d’attente Jenkins dans une définition de version, les clients obtiennent une erreur serveur 500.

• Solution de contournement :

  Pour le moment, la tâche de file d’attente Jenkins peut être exécutée dans le cadre des définitions de build TFS, mais pas des définitions de version. Cette fonctionnalité sera ajoutée dans une version ultérieure.

Les plug-ins personnalisés du serveur TFS doivent être régénérés sur les DLL de TFS 2017

• Problème :

  Les plug-ins personnalisés du serveur TFS ne fonctionnent pas après la mise à niveau vers TFS 2017.

• Solution de contournement :

  Régénérez vos plug-ins de serveur personnalisés sur les assemblys de TFS 2017.

Le modèle d’objet serveur des plug-ins personnalisés du serveur TFS a été modifié depuis TFS 2015 RTM

• Problème :

  Les plug-ins personnalisés du serveur TFS ne se compilent pas.

• Solution de contournement :

  Corrigez le code source comme décrit dans ce billet de blog.

Quand vous utilisez des actions de l’administrateur, une exception est levée

• Problème :

  Dans la page Administration des alertes, quand les administrateurs d’équipe utilisent la recherche Rechercher les alertes d’un utilisateur pour rechercher les abonnements d’une équipe, ils peuvent obtenir une exception.

• Solution de contournement :

  • Option 1 : cliquez sur le nœud Toutes les alertes et définissez le filtre Toutes les alertes de mes équipes pour afficher les alertes. Ce filtre affiche toutes les alertes de tous les groupes auxquels l’utilisateur a accès.

  • Option 2 : si le groupe est une équipe, au lieu de rechercher par nom d’équipe, accédez à la page Administration des alertes de cette équipe pour gérer les abonnements.

Problème lors de l’utilisation de tâches pour l’exécution de tests fonctionnels dans Team Build / Release Management

• Problème :

  L’exécution de tests fonctionnels dans Team Build/Release Management à l’aide des tâches « Déploiement de l’agent de test Visual Studio » et « Exécuter les tests fonctionnels » du catalogue de tâches utilise les Agents pour Visual Studio 2015 Update 3. Ces tâches ne peuvent être utilisées que pour exécuter des tests générés à l’aide de Visual Studio 2013 et Visual Studio 2015. Ces tâches ne peuvent pas être utilisées pour exécuter les tests créés à l’aide de Visual Studio 2017 RC. Pour plus d’informations, consultez ce billet de blog.

• Solution de contournement :

  Il n’existe aucune solution de contournement. La prise en charge de l’utilisation de Test Agent 2017 et l’exécution des tests créés à l’aide de Visual Studio 2017 sera ajoutée avec TFS 2017 Update 1.

Les extensions ne sont pas mises à jour automatiquement

• Problème :

  Si vous mettez à niveau une version antérieure de TFS vers TFS 2017 et que vous exécutez TFS 2017 en mode connecté, vos extensions ne seront pas mises à jour automatiquement comme elles devraient l’être.

• Solution de contournement :

  Il n’existe aucune solution de contournement pour l’instant. Nous avons résolu le problème et le comportement de mise à jour automatique sera correct dans TFS 2017 Update 2. Si pour une raison quelconque vous ne pouvez pas attendre la publication d’Update 2, contactez-nous via le canal de support technique et nous partagerons le correctif plus rapidement.

Si vous rencontrez des problèmes qui vous empêchent de déployer dans un environnement de production (Direct), contactez le Support technique Microsoft. (En anglais uniquement) Heures de bureau aux États-Unis seulement (du lundi au vendredi de 6h00 à 18h00, heure normale du Pacifique), réponse sous 1 jour ouvrable.

Consultez les problèmes signalés par les clients pour Team Foundation Server 2017.

---

Suggestions et commentaires

Nous aimerions connaître votre opinion ! Vous pouvez suggérer une fonctionnalité, signaler et suivre un problème sur Developer Community et obtenir des conseils sur Stack Overflow.

---

Haut de la page