Team Foundation Server 2017

Last Update: 16/06/2017

Pour afficher les dernières mises à jour, consultez les Notes de mise à jour.

Date de publication : 16 novembre 2016

Pour afficher les dernières mises à jour, consultez les Notes de mise à jour.

Nous avons le plaisir d’annoncer la sortie de Team Foundation Server 2017. Cette nouvelle version inclut nos dernières fonctionnalités et améliorations. Notez que la configuration requise pour Team Foundation Server 2017 a été modifiée. Vous trouverez plus d’informations dans la page sur la configuration requise et compatibilité de Team Foundation Server. Il s’agit des notes de mises à jour de la version la plus récente, alors vous ne trouverez peut-être pas celles auxquelles vous vous attendez.

Téléchargement : Team Foundation Server 2017

Pour en savoir plus sur d’autres téléchargements associés, consultez la page Téléchargements.

Nouveautés

Problèmes connus


Nouveautés

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 peut 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

Code Search

(Figure 1) Code Search

Pour plus d’informations, consultez Effectuer une recherche dans tout votre code.

Gestion des packages

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 parfaitement avec votre infrastructure, vos équipes et vos autorisations TFS existantes, vous n’avez donc pas besoin de prendre en charge la synchronisation des identités, la gestion des groupes dans 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.

(Figure 2) 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.
Remarque

Le nouveau formulaire d’élément de travail est le paramètre par défaut pour les nouvelles collections uniquement. Si vous migrez une collection existante, vous devez activer le nouveau formulaire d’élément de travail à partir des paramètres d’administration. Pour plus d’informations, consultez Gérer le lancement du nouveau formulaire web.

(Figure 3) Nouveau formulaire de type d’élément de travail

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 êtes averti chaque fois que l’élément de travail change, y compris quand les modifications concernent les mises à jour, les liens, les pièces jointes et les commentaires.

(Figure 4) Suivre un élément de travail

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 de votre tableau Kanban ? Essayez l’icône représentée dans la capture d’écran ci-dessous (Figure 5).

(Figure 5) Mises à jour dynamiques du tableau Kanban

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. En outre, si l’administrateur effectue des mises à jour au niveau du tableau ou de l’équipe, comme l’ajout d’une nouvelle colonne ou l’activation des bogues dans le backlog, vous recevez une notification vous invitant à actualiser le tableau pour mettre à jour sa disposition. Désormais, 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.

(Figure 6) Liens hypertexte des listes de vérification

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

(Figure 7) Menu contextuel de liste de vérification

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 terminé et offre une vue globale pratique pour comparer le travail achevé au travail en attente.

(Figure 8) Exploration des épopées et des fonctionnalités

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.

(Figure 9) Activer/désactiver les annotations de cartes

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 sur les éléments de travail, à l’aide de laquelle vous pouvez effacer toute la mise en forme du texte sélectionné. Comme moi, il vous est peut-être arrivé de copier et de coller un texte mis en forme dans ce champ sans pouvoir annuler l’opération (ou effacer le texte). Maintenant, 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 afin que vous puissiez visualiser votre tableau personnalisé, même quand vous vous connectez à partir de plusieurs appareils.

(Figure 10) Filtrage dans le tableau Kanban

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 les bogues pourraient s’afficher immédiatement sur le tableau de 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 Area and iteration paths (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.

(Figure 11) Contrôle de case à cocher

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

(Figure 12) Boîte de dialogue de modification en bloc

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

(Figure 13) Points d’extension du backlog

Pour plus d’informations sur les extensions, consultez Extension Points (Points d’extension).

Améliorations apportées aux e-mails

Nous avons considérablement amélioré la mise en forme et l’utilisation des alertes d’élément de travail, des suivis et 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.

(Figure 14) Améliorations apportées aux e-mails

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.

(Figure 15) Modèles d’éléments de travail

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 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 de 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 afin de prendre en charge l’ensemble croissant de widgets et de procurer 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.

(Figure 16) Catalogue de 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). Vous pouvez ainsi utiliser ces vignettes en tant qu’indicateurs de performance clés pour identifier une mesure d’intégrité et/ou une action éventuellement nécessaire.

(Figure 17) Mises à jour du tableau de bord

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

Les widgets de graphique WIT sont à présent 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.

Le widget Membres d’équipe a été mis à jour pour faciliter l’ajout d’une personne à votre équipe (Figure 18).

(Figure 18) Mise à jour des widgets

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 de vue d’ensemble du sprint a été repensé pour permettre aux équipes de vérifier 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.

(Figure 19) Qui me 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 modifications, citons la redéfinition de la page Branches et une nouvelle option pour effectuer une « fusion avec 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.

(Figure 20) Nouvelle page Branches

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ésumer tous les états critiques et les actions, en les rendant accessibles à partir de toutes les vues de l’expérience.

(Figure 21) En-tête de demande Pull

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.

(Figure 22) Vue d’ensemble des demandes Pull

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 désormais voir exactement ce qui a été modifié chaque fois que du nouveau code est transmis à votre demande Pull. 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.

(Figure 23) Fichiers de demande Pull

Mises à jour

La nouvelle vue Mises à jour permet d’afficher les modifications de la demande Pull dans le 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.

(Figure 24) Mises à jour des demandes Pull

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.

(Figure 25) Commentaires de demande Pull

Ajouter et supprimer des réviseurs dans les demandes Pull

Il est désormais plus facile d’ajouter et de supprimer des réviseurs dans vos requêtes 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).

(Figure 26) Ajouter des réviseurs dans les demandes Pull

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 conformément aux attentes de l’utilisateur : si un commentaire a été ajouté à la ligne 10, puis que deux nouvelles lignes ont été ajoutées par la suite au début du fichier, le commentaire s’affiche désormais à la ligne 12.

Voici un exemple de modification avec un commentaire à la ligne 13 (Figure 27).

(Figure 27) Suivi des commentaires

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

(Figure 28) Suivi des commentaires avec modification

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

Les équipes qui utilisent des stratégies de branche (https://www.visualstudio.com/en-us/docs/git/branch-policies) pour protéger leurs branches vont être intéressées par l’action de saisie semi-automatique. Souvent, l’auteur d’une demande Pull est prêt à fusionner sa demande Pull, mais il attend la fin d’une génération pour pouvoir cliquer sur Terminer. Parfois, la build est validée, mais un réviseur n’a pas encore 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).

(Figure 29) Saisie semi-automatique

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

(Figure 30) Boîte de dialogue de saisie semi-automatique

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

(Figure 31) Confirmation de saisie semi-automatique

Quand toutes les stratégies ont été remplies (par exemple, la génération est terminée ou l’approbation finale est accordée), la demande Pull est fusionnée à l’aide des options et commentaires spécifiés. Comme prévu, si la génération échoue ou si le réviseur ne donne pas son approbation, la demande Pull 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 entraîne une validation unique qui contient les modifications de la branche de rubrique à appliquer à 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.

(Figure 32) Demande Pull avec action squash merge

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 à davantage de détails, et savez systématiquement si les modifications présentes dans la validation ont franchi avec succès la phase de la génération. 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 requêtes de tirage pour fusionner vos modifications, vous voyez le lien vers la requête de tirage à l’origine des modifications dans la branche maître (ou dans le cas d’une validation de fusion, la requête de tirage qui l’a créée). Une fois que vos modifications ont atteint la branche maître, le lien de la branche s’affiche pour confirmer que les modifications ont été incluses.

(Figure 33) Traçabilité des validations

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 Large File Storage (LFS) remplace ces fichiers par des pointeurs dans Git, tout en stockant leur contenu sur un serveur distant. Vous pouvez ainsi afficher tout le contenu 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).

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.

(Figure 34) Envoyer des liens vers du code

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 à d’autres détails et savez systématiquement si les modifications présentes 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.

(Figure 35) API d’état

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

(Figure 36) Exemples de types de fichiers

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.

(Figure 37) Ajouter un fichier Readme

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

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 en cours d’exécution (Figure 38).

(Figure 38) Onglet File d’attente de builds

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 dispose de deux colonnes, et toutes les extensions se trouvent par défaut dans la première colonne. Remarque : Toutes les extensions tierces apparaissent après les sections des résultats de build que nous incluons.

(Figure 39) Ordre de build et colonne

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) :

(Figure 40) De la build vers un numéro de ligne

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

Les développeurs Java peuvent désormais se familiariser beaucoup plus facilement avec la génération en ajoutant des modèles de build pour Ant, Maven et Gradle (Figure 41).

(Figure 41) Modèles de build Java

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 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 allons également déconseiller 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, les modèles de définition de build Xamarin ont été améliorés pour utiliser 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.

(Figure 42) Images 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).

(Figure 43) Demandes Pull SonarQube

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

(Figure 44) Déclencheurs Git CI

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

(Figure 45) Cloner et exporter des commandes dans la page de résumé de la mise en production

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

(Figure 46) Résultats des tests affichés dans le résumé de la mise en production

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

(Figure 47) Passer des jetons OAuth aux scripts

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) :

(Figure 48) Exemple de script utilisant un jeton oAuth transmis

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

(Figure 49) Affichage en orange des mises en production partiellement réussies dans le résumé

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

(Figure 50) Définition de l’option de déclenchement à partir d’une mise en production partiellement réussie

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

(Figure 51) Liaison du code dans un dépôt GitHub à une définition de mise en production

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 (Figure 52).

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

(Figure 52) Déploiement d’applications web à l’aide d’ARM

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.

(Figure 53) Liaison du code dans un dépôt GitHub à une définition 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.

Pour restaurer une de ces mises en production, ouvrez le menu contextuel et choisissez Annuler la suppression (Figure 54).

Undelete releases

(Figure 54) Annuler la suppression des mises en production

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 pendant laquelle la mise en production et la build liée sont conservées.

Par défaut, une mise en production est conservée pendant 60 jours. Celles qui n’ont pas été déployées ou modifiées pendant 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).

Retain releases

(Figure 55) Conserver les mises en production

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). Chacun des artefacts est téléchargé dans un dossier sur l’agent appelé 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.

Linked artifact improvements

(Figure 56) Améliorations apportées à l’artefact lié

For more details, see [Artifact source alias](https://www.visualstudio.com/en-us/docs/release/author-release-definition/understanding-artifacts#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 comme 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).

Manual intervention task

(Figure 57) Tâche d’intervention manuelle

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

Scripts des tâches de déploiement SQL Database

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

SQL database deployment task scripts

(Figure 58) Scripts des tâches de déploiement SQL Database

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

Schedule release to an environment

(Figure 59) Planifier une mise en production dans un environnement

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 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. Vous trouverez quelques exemples simples qui utilisent les API dans ce billet de blog, Using ReleaseManagement REST API’s (Utilisation des API REST ReleaseManagement).

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

(Figure 60) Déploiement sur des clouds Azure nationaux

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. Pour que la mise à niveau de TFS soit plus rapide, nous vous recommandons de configurer la stratégie de rétention de test et de lui laisser le soin de réduire l’espace de stockage utilisé par les résultats des tests. Après avoir installé TFS, mais avant la mise à niveau de l’instance TFS, vous pouvez utiliser l’outil TFSConfig.exe pour nettoyer les résultats de test. 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 de test avant la mise à niveau, planifiez la fenêtre de la mise à niveau en conséquence. Pour obtenir plus d’exemples sur la configuration de la stratégie de rétention de test, consultez Rétention de données de résultat de test avec Team Foundation Server 2015.

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 des tests à l’interface utilisateur web en ajoutant un nouvel onglet Configurations au hub 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.

Configurations hub

(Figure 61) Hub de configurations

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 encore plus facile : 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 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).

Assign Configurations

(Figure 62) Assigner des configurations

Configurations Filter

(Figure 63) Filtre de configurations

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é exécutés. Ces colonnes fournissent un contexte très utile pour explorer les résultats de vos tests (Figure 64).

Test Results Pane

(Figure 64) Volet Résultats des tests

Tri des tests dans le hub Test et dans les cartes

Vous pouvez désormais trier les tests manuels à partir du hub Test (Figure 65), quel que soit le type de suite dans lequel ils sont inclus : suites statiques, suites basées sur des spécifications ou suites basées sur une requête. 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). Cela répond à une des demandes utilisateur anciennes (495 votes) en matière de test manuel.

Order tests

(Figure 65) Trier les tests

Order tests on card

(Figure 66) Trier les tests dans la carte

Trier les suites de tests dans le hub Test

Les équipes de test peuvent maintenant classer dans l’ordre les suites de tests en fonction de leurs besoins. Avant cette fonctionnalité, les suites étaient uniquement classés dans l’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). Ainsi, l’élément voix utilisateur suivant est traité dans le cadre d’un test manuel/d’une gestion de cas de test.

(Figure 67) Classer les suites de tests dans l’ordre

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

(Figure 68) Rechercher des utilisateurs

Assign Users

(Figure 69) Assigner des utilisateurs

Sélectionner une build pour le test

Vous pouvez maintenant sélectionner la « build » avec laquelle effectuer le test, puis lancer l’exécuteur web à l’aide de l’option « Exécuter avec des options » dans le hub Test (Figure 70). Tout bogue archivé 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.

(Figure 70) Sélectionner une build

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 s’ouvre sans ouvrir tout l’interpréteur de commandes de Microsoft Test Manager et s’arrête à la fin de l’exécution du test.

Run with options

(Figure 71) Exécuter avec des options

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 est lancé de la même façon que Microsoft Test Runner, comme décrit ci-dessus.

Run with Options - XT

(Figure 72) Exécuter avec des options - Test exploratoire

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 résultats de test » pour un plan de test particulier dans le menu contextuel Plan de test du hub 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.

Configure test outcomes

(Figure 73) Configurer les résultats de test

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.

Verify bugs

(Figure 74) Vérifier les bogues

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

Inline tests

(Figure 75) Tests inline

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.

Traverse to plan/suite

(Figure 76) Accéder à un plan/une suite

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. Maintenant, vous pouvez remplacer ce comportement en configurant un plan de test existant de votre choix : tous les tests sont alors ajoutés au plan de test sélectionné à l’avenir. Notez que cette fonctionnalité est activée uniquement si l’annotation Test est activée.

Common settings

(Figure 77) Paramètres communs

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.

Test Step attachments

(Figure 78) Pièces jointes d’étapes de test

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.

Web runner using Chrome browser

(Figure 79) Exécuteur web avec le navigateur Chrome

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 test exploratoire, tous les nouveaux bogues que vous archivez sont créés en tant qu’enfant de ce récit utilisateur. Ce nouveau comportement simplifie la traçabilité entre les récits et les bogues. Cela s’applique uniquement si les paramètres « Gestion des bogues » dans la page Configuration des paramètres courants est définie sur « 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, comme 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.

Add to existing bug

(Figure 80) Ajouter à un 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 tests exploratoires 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, grilles et dans le hub Test.

• Dans l’extension (Figure 82) : Recherchez un élément de travail dans la session de tests exploratoires, puis associez-le à la session en cours.

XT from card

(Figure 81) Tests exploratoires à partir de l’élément de travail

Explore work item

(Figure 82) Tests exploratoires à partir de l’extension

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 « Include image action log » (Inclure le journal des actions en images) (Figure 83) pour capturer les actions liées à la souris, au clavier, ainsi que les actions tactiles, et ajouter le texte et les images correspondants directement au bogue ou à la tâche.

Enregistrement d’écran sous forme de vidéo : Vous pouvez également capturer des enregistrements d’é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 en cours d’archivage à 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, la capture de 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 terminer 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.

XT Image Action Log

(Figure 83) Test exploratoire : journal des actions en images

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.

XT Create Test Cases

(Figure 84) Test exploratoire : créer des cas de test

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’informations en cliquant sur le lien « Recent exploratory sessions » (Sessions exploratoire récentes) dans le hub Séries au sein du groupe Hub 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).
  • La vue avec regroupement, qui peut au besoin être réorganisée en tableau croisé dynamique 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.

XT Session insights

(Figure 85) Test exploratoire : informations sur les sessions

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

Sessions de tests exploratoires : afficher les éléments de travail non explorés

En plus de voir les détails de tous les éléments de travail explorés dans la vue des « sessions exploratoires récentes », filtrée à l’aide de Toutes les sessions/Mes sessions pendant une période donnée, nous avons maintenant ajouté la possibilité de voir aussi la liste de tous les éléments de travail qui n’ont PAS été explorés, dans la même vue (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.

View unexplored WIT

(Figure 86) Afficher les éléments de travail inexplorés

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 participants qui doivent laisser des commentaires et éventuellement fournir un jeu simple d’instructions invitant à choisir les zones du produit pour lesquelles vous aimeriez obtenir des commentaires. Cette opération envoie des messages individuels aux participants sélectionnés avec des instructions, le cas échéant.

XT Feedback Flow

(Figure 87) Flux de commentaires des tests exploratoires

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. Par ailleurs, les participants peuvent accéder à la page « Demandes de commentaires » pour consulter au même endroit toutes les demandes de commentaires qu’ils ont reçues. Dans la liste, ils peuvent sélectionner la demande de commentaires à laquelle ils veulent répondre, gérer leurs « Demandes de commentaires en attente » (Figure 88) en les marquant comme étant terminées ou en les refusant, et basculer entre les différents types de demandes de commentaires en cliquant sur la case d’option souhaitée (Figure 89).

Provide feedback link

(Figure 88) Lien Fournir un commentaire

XT Feedback Flow

(Figure 89) Flux de commentaires des tests exploratoires

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). Ils peuvent ouvrir l’extension, sélectionner le mode « Connecté » dans la page Paramètres de connexion et se connecter au compte et au projet/à l’équipe pour lesquels ils veulent 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.

Voluntary Feedback

(Figure 90) Commentaires volontaires

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 avez la possibilité d’en afficher un aperçu sous l’onglet Tests et vous n’avez plus besoin de télécharger le fichier trx pour afficher les journaux.

Console logs and duration

(Figure 91) Journaux de la console et durée

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.

'Test result trend' widget

(Figure 92) Widget « Test result trend » (Tendance des résultats des tests)

É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 y exécuter des tests. 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.

Test status with Release Environment summary

(Figure 93) État de test avec résumé de l’environnement de mise en production

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. Quand un tel test échoue, il est important de déterminer si l’échec se limite à des branches de développement comme la branche principale ou si les échecs ont également un impact sur les branches de mise en production qui se déploient dans des 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.

Test status with Release Environment summary

(Figure 94) État de test avec résumé de l’environnement de mise en production

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 sont capables de lier des tests automatisés directement aux spécifications, puis d’utiliser des widgets Tableau de bord pour suivre la qualité des spécifications qui vous intéressent, en extrayant des données de qualité de la build ou de la mise en production.

Requirement Quality Widget

(Figure 95) Widget de qualité des spécifications

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. Cette distribution peut être activée en cochant la case dans la tâche, comme indiqué ci-dessous.

Task Setting

(Figure 96) Paramètre de la tâche

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

Run SonarQube Analysis

(Figure 97) Exécuter une analyse SonarQube

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.

Run SonarQube Analysis

(Figure 98) Exécuter une analyse SonarQube

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 à Marketplace

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

Install Free Extension

(Figure 99) Installer l’extension gratuite

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.

Purchase Paid Extension

(Figure 100) Acheter une extension payante

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, qui assure une sécurité renforcée, est utilisée dès que possible. 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 voulez vous amuser avec, 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 alors 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.

Admin work hub

(Figure 101) Hub de travail d’administration

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 « Points de récit » 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).

My security

(Figure 102) Ma sécurité

My profile

(Figure 103) Mon profil

Assistant Configuration unifiée

Dans les mises en production précédentes, vous sélectionniez l’un des Assistants Configuration pour votre déploiement TFS selon ce que vous tentiez de faire : 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 ; enfin, 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 maintenant des actions qui s’effectuaient avant par le biais de tfsconfig.exe, notamment la modification des ID de serveur, le nouveau mappage des chaînes de connexion de base de données et la suppression des références à des dépendances externes (auparavant effectués 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.

Personal Access Tokens

(Figure 104) Jetons d’accès personnels

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. L’éditeur de modèles de processus est l’un de ceux qui n’ont pas été intégrés, mais nous allons publier rapidement après la mise à disposition de TFS 2017 un outil d’édition de modèles de processus pour TFS 2017 dans la galerie Visual Studio. Nous vous indiquerons le lien ici dès qu’il sera publié.

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 ayant installé une extension page d’élément de travail qui exportent la définition de type d’élément de travail, puis l’importent 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 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.


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/Gestion des packages, les tâches de génération 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 est exécuté 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 génération/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, que vous l’avez publiée sur votre installation TFS 2015 et que vous avez effectué la mise à niveau vers TFS 2017, l’extension n’est pas automatiquement mise à jour quand de nouvelles versions de l’extension sont publiées dans 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 des tâches utilise Agents pour Visual Studio 2015 Update 3 et ces tâches ne peuvent être utilisées que pour exécuter des tests créé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.