Notes de publication de Team Foundation Server 2018

Last Update: 22/11/2017

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

Download the latest version of Team Foundation Server

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


Vidéo Nouveautés de TFS 2018


Commentaires

Nous aimerions connaître votre opinion ! Vous pouvez signaler et suivre un problème sur Developer Community et obtenir des conseils sur Stack Overflow. Comme toujours, si vous avez des idées sur des améliorations à faire en priorité, rendez-vous sur UserVoice pour ajouter votre idée ou voter pour une idée existante.


Date de publication : 15 novembre 2017

Résumé : Mises à jour de Team Foundation Server 2018

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

Fonctionnalités supprimées de cette version


En détail : Nouveautés de cette version

Suivi des éléments de travail

Assistant Création de projet sur le web

Nous avons amélioré l’expérience de création d’un projet d’équipe à partir de l’accès web. Elle inclut désormais la plupart des fonctionnalités disponibles quand vous créez un projet d’équipe dans le client Visual Studio. L’avantage de l’utilisation de l’interface web est que vous n’avez pas besoin d’une version correspondante de Visual Studio. La différence entre Visual Studio et la version web est que la version web n’approvisionne pas vos rapports dans SSRS. Si vous avez utilisé la version web de la création de projet d’équipe, vous pouvez exécuter la commande tfsconfig sur la couche application pour approvisionner ou mettre à jour les rapports SSRS. Vous trouverez les détails dans AddProjectReports.

Gestionnaire de modèles de processus sur le web

Avec TFS 2018, vous pouvez utiliser l’accès web pour charger vos modèles de processus. L’interface web est une expérience beaucoup plus facile, car vous n’êtes pas obligé d’installer la version exactement correspondante de Visual Studio pour interagir avec vos modèles de processus. Visual Studio 2017 Update 4 et antérieur affiche toujours la boîte de dialogue Gestionnaire de modèles de processus, mais nous vous recommandons d’utiliser l’interface web. Visual Studio 2017 Update 5 et ultérieur vous redirige automatiquement vers le site web.

Personnaliser l’en-tête de formulaire d’élément de travail

Vous pouvez désormais personnaliser la zone d’en-tête d’un formulaire d’élément de travail en remplaçant les contrôles existants ou en masquant ceux qui ne présentent pas d’intérêt pour votre processus. Cela vous permet de remplacer le champ Chemin de la zone par un champ Équipe personnalisé, de masquer le champ Itération si vos équipes sont plus axées sur le Kanban et de remplacer le champ Raison par un champ personnalisé. Le champ État ne peut être ni masqué ni remplacé.

Pour plus d’informations, consultez la documentation sur les éléments WebLayout et Control.

Formulaire d’élément de travail mobile

Nous proposons une expérience complète de bout en bout qui inclut une optimisation de l’aspect des éléments de travail (Figure 1). Elle offre un moyen facile d’interagir avec les éléments qui vous sont assignés, que vous suivez ou que vous avez visités ou modifiés récemment, à partir de votre téléphone.

Mobile work item query

(Figure 1) Requête d’élément de travail mobile

En plus d’une apparence agréable, cette expérience prend en charge les contrôles optimisés pour tous les types de champs (Figure 2).

Mobile work item form

(Figure 2) Formulaire d’élément de travail mobile

Avec la nouvelle navigation mobile (Figure 3), les utilisateurs peuvent atteindre tous les autres composants de TFS prêts pour le mobile, et revenir ensuite au site complet pour poste de travail au cas où ils auraient besoin d’interagir avec d’autres hubs.

Mobile navigation

(Figure 3) Navigation mobile

Filtrage sur les backlogs, les tableaux kanban, les sprints et les requêtes

Toutes nos expériences de grille de suivi des éléments de travail (requêtes, backlogs, tableaux kanban, backlogs de sprints et gestion de cas de test) utilisent désormais notre composant de filtrage commun et cohérent (Figure 4). En plus d’appliquer un filtre de mots clés sur les colonnes affichées et de sélectionner des étiquettes, vous pouvez aussi filtrer sur les types, les états et les affectations des éléments de travail, ce qui vous permet d’accéder rapidement à ceux que vous cherchez.

Filtering on query

(Figure 4) Filtrage sur les requêtes

Développer pour afficher les champs vides sur une carte kanban

Aujourd’hui, vous avez la possibilité d’ajouter des champs supplémentaires à une carte, puis de masquer les champs vides (Figure 5) dans les paramètres de la carte pour en éliminer les éléments en désordre qui ne sont pas nécessaires. L’inconvénient de cette fonctionnalité était qu’une fois qu’un champ vide était masqué, la seule façon de le mettre à jour était d’ouvrir le formulaire d’élément de travail. Avec la nouvelle option de développement disponible sur les cartes kanban, vous pouvez désormais bénéficier du masquage des champs vides dans le tableau, tout en pouvant accéder en un seul clic à la mise à jour d’un champ particulier sur une carte. Pointez simplement sur la carte et recherchez le chevron orienté vers le bas dans la partie inférieure de la carte pour mettre à jour le champ masqué.

Hidden field

(Figure 5) Champ masqué sur la carte kanban

Cliquez sur le chevron orienté vers le bas dans la partie inférieure de la carte pour mettre à jour le champ (Figure 6).

Update hidden field

(Figure 6) Mettre à jour le champ masqué sur la carte kanban

Blocage de l’enregistrement des éléments de travail par les extensions

Les contrôles personnalisés, les groupes et les pages des formulaires d’élément de travail peuvent désormais bloquer l’enregistrement des éléments de travail pour valider les données et vérifier que l’utilisateur renseigne les informations obligatoires avant d’enregistrer le formulaire d’élément de travail.

Ajout inclus dans les plans de livraison

Comme les idées de nouvelles fonctionnalités peuvent arriver à tout moment, nous avons facilité l’ajout de nouvelles fonctionnalités directement dans vos Plans de livraison (Figure 7). Il vous suffit de cliquer sur le bouton Nouvel élément disponible en pointant avec la souris, d’entrer un nom, puis d’appuyer sur Entrée. Une nouvelle fonctionnalité est alors créée avec le chemin de zone et le chemin d’itération attendus.

Inline add on delivery plans

(Figure 7) Ajout inclus dans les plans de livraison

Gestion de versions

Duplications (forks)

TFS 2018 ajoute la prise en charge des duplications Git (Figure 8). Une duplication est une copie côté serveur d’un dépôt. En utilisant des duplications, vous pouvez permettre à un large éventail de personnes de contribuer à votre dépôt sans leur octroyer un accès direct à la validation. Au lieu de cela, ils valident leur travail sur leur propre duplication du dépôt. Ceci vous donne la possibilité d’examiner leurs modifications dans une demande de tirage (pull request) avant de les accepter dans le dépôt central.

Git forks

(Figure 8) Duplications (fork) GIT

GVFS

Le système GVFS (Git Virtual File System) est désormais pris en charge. Avec GVFS, les dépôts Git peuvent accueillir plusieurs millions de fichiers en virtualisant et en optimisant le fonctionnement de Git sur le système de fichiers.

Créer un dossier dans un dépôt via le web

Vous pouvez désormais créer des dossiers via le web dans vos dépôts Git et TFVC (Figure 9). Ce système remplace l’extension Folder Management, qui va être soumise à un processus de dépréciation.

Pour créer un dossier, cliquez sur Nouveau > Dossier dans la barre de commandes ou dans le menu contextuel :

New folder option

(Figure 9) Option Nouveau dossier

Pour TFVC, vous devez spécifier un nom de dossier, puis l’archiver. Dans le cas de Git, sachant que les dossiers vides ne sont pas autorisés, vous devez là aussi spécifier un nom de fichier, modifier éventuellement le fichier, puis le valider.

Par ailleurs, pour Git, la boîte de dialogue Nouveau fichier (Figure 10) a été améliorée pour accepter des barres obliques et créer des sous-dossiers.

New file dialog

(Figure 10) Boîte de dialogue Nouveau fichier

Miniplan de fichier

Vous pouvez désormais afficher le miniplan d’un fichier que vous consultez ou modifiez pour obtenir un bref aperçu du code (Figure 11). Pour activer le miniplan, ouvrez la Palette de commandes (F1 ou clic droit), puis sélectionnez Activer/désactiver le miniplan.

File minimap

(Figure 11) Miniplan de fichier

Appariement des accolades

Quand vous modifiez ou consultez un fichier, des indications s’affichent désormais à gauche pour faciliter la mise en correspondance des accolades (Figure 12).

Bracket matching

(Figure 12) Appariement des accolades

Activation/désactivation des espaces blancs

Vous pouvez désormais activer/désactiver les espaces blancs pendant que vous consultez ou modifiez un fichier. Nous développons actuellement une fonctionnalité qui vous permettra d’activer/désactiver les espaces blancs pendant que vous comparez des versions. Pour afficher les espaces blancs (Figure 13), ouvrez la Palette de commandes (F1 ou clic droit), puis sélectionnez Activer/désactiver les espaces blancs, qui vous permet de faire la distinction entre les espaces et les tabulations.

Toggle white space

(Figure 13) Activation/désactivation des espaces blancs

Paramètre pour désactiver l’édition web pour les dépôts TFVC

Les équipes qui utilisent souvent des TFVC utilisent des stratégies d’archivage dans Visual Studio pour garantir la qualité du code. Toutefois, étant donné que les stratégies d’archivage sont appliquées sur le client, le code qui est modifié sur le web n’est pas soumis aux mêmes stratégies.

Plusieurs personnes ont demandé un moyen de désactiver l’édition web pour protéger contre les modifications qui contournent les stratégies d’archivage. Nous avons mis en place un moyen de désactiver l’édition web (ajout, suppression, renommage et modification) pour TFVC au niveau des projets/dépôts.

Pour interdire l’édition web à partir de la page Fichiers, accédez à Paramètres, puis Gestion de version (Figure 14). Cliquez sur le dépôt TFVC dans l’arborescence, accédez au nœud Options et décochez la case Activer l’édition web pour ce dépôt TFVC. Par défaut, l’édition web est activée.

Remarque

L’édition du fichier README à partir de la page Vue d’ensemble du projet n’est pas affectée.

Turn off web editing

(Figure 14) Désactiver l’édition web

Si vous essayez d’éditer via le web un projet pour lequel l’édition web est désactivée, vous êtes informé que l’édition web n’est pas autorisée(Figure 15).

Web editing not allowed dialog

(Figure 15) Boîte de dialogue Édition web non autorisée

Ceci a été développé à partir d’une suggestion faite à ce sujet.

Identifier les branches périmées

Le fait de garder « propre » votre dépôt en supprimant les branches dont vous n’avez plus besoin permet aux équipes de trouver les branches qui les intéressent et de définir des favoris au bon niveau de granularité. Cependant, si vous avez un grand nombre de branches dans votre dépôt, il peut être difficile de savoir lesquelles sont inactives et peuvent être supprimées. Nous avons maintenant rendu plus facile l’identification des branches « périmées » (les branches qui pointent vers des validations antérieures à 3 mois). Pour afficher vos branches périmées, accédez à l’onglet Périmées dans la page Branches (Figure 16).

Stale branches

(Figure 16) Branches périmées

Rechercher une branche supprimée et la recréer

Quand une branche est accidentellement supprimée du serveur, il peut être difficile de déterminer ce qui lui est arrivé. Vous pouvez désormais rechercher une branche supprimée, voir qui l’a supprimée et quand, et la recréer si vous le souhaitez.

Pour rechercher une branche supprimée, entrez le nom complet de la branche dans la zone de recherche de branches. La recherche retourne toutes les branches existantes qui correspondent à ce texte. Vous voyez également une option pour rechercher une correspondance exacte dans la liste des branches supprimées. Cliquez sur le lien pour rechercher des branches supprimées (Figure 17).

Search for deleted branches

(Figure 17) Rechercher les branches supprimées

Si une correspondance est trouvée, vous voyez qui l’a supprimée et quand. Vous pouvez aussi restaurer la branche (Figure 18).

Restore deleted branches

(Figure 18) Restaurer les branches supprimées

La restauration de la branche la recrée au niveau de validation vers lequel elle pointait en dernier. Elle ne restaure cependant pas les stratégies et les autorisations.

Rechercher une validation dans des branches commençant par un préfixe

Si vous avez une structure de branches dans un format hiérarchique où toutes les branches sont préfixées par un certain texte, cette fonctionnalité vous aide à trouver une validation dans toutes les branches commençant par ce texte de préfixe. Par exemple, pour voir si une validation a bien été effectuée pour toutes les branches ayant le préfixe « dev », tapez simplement « dev » dans la zone de recherche et sélectionnez Rechercher dans les branches commençant par « dev » (Figure 19).

Search for a commit

(Figure 19) Rechercher une validation

Légende des demandes de tirage (pull requests) plus détaillée dans la page des détails de validation

La légende des demandes de tirage dans la page des détails de validation affiche des informations plus pertinentes pour vous aider à établir un meilleur diagnostic (Figure 20). Nous montrons désormais aussi dans la légende la première demande de tirage qui a introduit la validation des branches, et la demande de tirage associée à la branche par défaut.

Pull request callout

(Figure 20) Légende de demande de tirage

Filtrer l’arborescence dans le code

Désormais, vous ne devez plus faire défiler tous les fichiers qui peuvent avoir été modifiés par une validation pour simplement accéder à vos fichiers. L’arborescence sur la page des détails de validation, des demandes de tirage, des détails du jeu de réservations et des détails de l’ensemble de modifications prend désormais en charge le filtrage des fichiers et des dossiers. Il s’agit d’un filtre intelligent qui montre les fichiers enfants d’un dossier quand vous filtrez par nom de dossier, et qui affiche une arborescence réduite d’un fichier pour montrer la hiérarchie des fichiers quand vous filtrez par nom de fichier.

Filtre Rechercher un fichier ou un dossier dans l’arborescence des validations (Figure 21) et (Figure 22) :

Find a file or folder

(Figure 21) Rechercher un fichier ou un dossier

Filtered view

(Figure 22) Vue filtrée dans l’arborescence des validations

La page des mises à jour de branche est désormais Envois (Pushes)

La page Mises à jour de branche est très importante. Pourtant, elle était masquée sous la forme d’un onglet sous le hub Historique. La page des mises à jour de branche est désormais visible sous la forme d’un hub appelé Push (Figure 23) sous Code, au même titre que Validations, Branches, Étiquettes et Demandes de tirage (pull requests). La nouvelle URL de la page d’envois (push) est : \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. Les anciennes URL continueront de fonctionner.

Pushes page

(Figure 23) Page Envois (push)

Dans le même temps, le hub Historique a été renommé Validations (Figure 24), car il affiche uniquement les validations. Nous avons reçu des commentaires selon lesquels des utilisateurs éprouvaient des difficultés à résoudre les problèmes liés aux validations, car il était nécessaire de pointer avec la souris sur une validation dans la vue présentant la liste des validations pour obtenir les détails de date/heure. La vue de la liste des validations pour votre instance montre désormais la date et l’heure au format jj/mm/aa hh:mm. La nouvelle URL pour la page de validations est : \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. Les anciennes URL continueront de fonctionner.

Commits page

(Figure 24) Page Validations

Conservation du nom de fichier lors du passage de Fichiers à Validations

Nous avons reçu des commentaires de personnes indiquant que, quand elles filtrent le répertoire sur un fichier particulier dans l’onglet Fichiers du hub Code et repassent après cela à l’onglet Historique, le nom du fichier n’est pas conservé si la validation a modifié plus de 1 000 fichiers. Ceci les obligeait à charger plus de fichiers et à filtrer le contenu pour rechercher le fichier, ce qui impactait la productivité. Les développeurs travaillent normalement dans le même répertoire et veulent rester dans les répertoires où ils travaillent quand ils suivent les modifications. Nous conservons désormais le nom de fichier quand vous passez entre les onglets du hub Code, quel que soit le nombre de fichiers modifiés dans une validation. Cela signifie que vous n’avez pas à cliquer sur Charger plus pour rechercher le fichier souhaité.

Afficher les étiquettes Git

Vous pouvez afficher toutes les étiquettes de votre dépôt dans la page Étiquettes (Figure 25). Si vous gérez toutes vos étiquettes en tant que versions, un utilisateur peut visiter la page des étiquettes pour obtenir une vue d’ensemble de toutes les versions d’un produit.

View Git tags

(Figure 25) Afficher les étiquettes Git

Vous pouvez facilement distinguer une étiquette légère d’une étiquette annotée. Les étiquettes annotées montrent le nom de la personne qui a affecté l’étiquette et la date de création avec la validation associée, alors que les étiquettes légères montrent seulement les informations de validation.

Supprimer des étiquettes Git

Il peut arriver que vous souhaitiez supprimer une étiquette de votre dépôt distant. Il peut s’agir d’une faute de frappe dans le nom de l’étiquette, ou vous avez placé une étiquette avec une validation incorrecte. Vous pouvez facilement supprimer des étiquettes à partir de l’interface utilisateur web en cliquant sur le menu contextuel d’une étiquette de la page Étiquettes et en sélectionnant Supprimer l’étiquette (Figure 26).

Avertissement

La suppression d’étiquettes sur des dépôts distants doit être effectuée avec précaution.

Delete git tags

(Figure 26) Supprimer les étiquettes Git

Filtrage des étiquettes Git

Pour les dépôts anciens, le nombre d’étiquettes peut considérablement augmenter avec le temps. Il peut aussi exister des dépôts qui ont des étiquettes créées dans les hiérarchies, ce qui peut compliquer la recherche des étiquettes.

Si vous ne trouvez pas l’étiquette que vous cherchez dans la page Étiquettes, vous pouvez simplement rechercher le nom de l’étiquette à l’aide du filtre en haut de la page Étiquettes (Figure 27).

Filter Git tags

(Figure 27) Filtrer les étiquettes Git

Sécurité des étiquettes Git

Vous pouvez désormais accorder des autorisations granulaires aux utilisateurs du dépôt pour gérer les étiquettes. Vous pouvez accorder aux utilisateurs l’autorisation de supprimer ou de gérer les étiquettes à partir de cette interface (Figure 28).

Git tag security

(Figure 28) Sécurité des étiquettes Git

Pour plus d’informations sur les étiquettes Git, consultez le blog Microsoft DevOps.

Compléter automatiquement les éléments de travail à la fin des demandes de tirage (pull requests)

Si vous liez des éléments de travail à vos demandes de tirage, conserver tout à jour est devenu plus simple. Désormais, quand vous effectuez une demande de tirage, vous pouvez choisir de terminer automatiquement les éléments de travail liés une fois que la demande de tirage a été fusionnée (Figure 29). Si vous utilisez des stratégies et que vous configurez les demandes de tirage pour qu’elles soient achevées automatiquement, vous voyez la même option. Vous n’avez plus besoin de vous rappeler de revisiter les éléments de travail pour mettre à jour l’état une fois la demande de tirage terminée. Cette action est effectuée automatiquement pour vous.

Complete linked work items

(Figure 29) Compléter automatiquement les éléments de travail liés

Réinitialiser les votes après envoi (push)/nouvelle itération

Les équipes qui optent pour un workflow d’approbation plus strict dans les demandes de tirage peuvent désormais choisir de réinitialiser les votes quand de nouvelles modifications sont envoyées (push)(Figure 30). Le nouveau paramètre est une option sous la stratégie consistant à Demander un nombre minimal de réviseurs.

Reset votes setting

(Figure 30) Paramètre de réinitialisation des votes

Quand elle est appliquée, cette option fait que tous les votes de tous les réviseurs sont réinitialisés dès que la branche source de la demande de tirage est mise à jour. La chronologie de la demande de tirage enregistre une entrée chaque fois que les votes sont réinitialisés à la suite de cette option(Figure 31).

Reset votes in timeline

(Figure 31) Réinitialiser les votes dans la chronologie

Filtrer l’arborescence des demandes de tirage (pull requests) par nom de fichier

La recherche d’un fichier spécifique dans une demande de tirage n’a jamais été aussi facile. La nouvelle zone de filtre de la vue Fichiers permet aux utilisateurs de filtrer la liste des fichiers de l’arborescence (Figure 32).

Find file or folder in pull request

(Figure 32) Rechercher un fichier ou un dossier dans une demande de tirage

Le filtre recherche une correspondance avec n’importe quelle partie du chemin des fichiers dans la demande de tirage : vous pouvez donc faire des recherches par noms de dossiers, par chemins partiels, par noms de fichiers ou par extensions (Figure 33).

Find results

(Figure 33) Résultats de la recherche

Plus d’options de filtrage des commentaires des demandes de tirage (pull requests)

Les commentaires dans la vue d’ensemble de la demande de tirage et ceux de la vue Fichiers ont désormais les mêmes options (Figure 34). Vous pouvez également filtrer pour afficher seulement les discussions auxquelles vous avez participé.

PR comment filtering

(Figure 34) Filtrage des commentaires d’une demande de tirage

Afficher les différences avec l’original pour les commentaires du code dans les détails de la demande de tirage

Il est parfois difficile de comprendre le sens d’un commentaire d’une demande de tirage une fois que le code auquel il fait référence a changé (dans de nombreux cas, quand un changement demandé a été effectué) (Figure 35).

View original diff

(Figure 35) Afficher les différences avec l’original

Quand cela se produit, vous voyez désormais un badge avec un numéro de mise à jour, sur lequel vous pouvez cliquer pour voir comment le code se présentait au moment où le commentaire a été créé initialement (Figure 36).

Update badge

(Figure 36) Badge de mise à jour

Commentaires réductibles pour les demandes de tirage (pull requests)

La révision du code étant une partie critique de l’expérience des demandes de tirage, nous avons ajouté de nouvelles fonctionnalités pour permettre aux réviseurs de se concentrer plus facilement sur le code. Les réviseurs de code peuvent facilement masquer les commentaires pour les faire disparaître lors d’une première revue de nouveau code (Figure 37).

Hide comments

(Figure 37) Masquer les commentaires

Le masquage des commentaires (Figure 38) les masque dans l’arborescence et réduit les threads de commentaires dans la vue Fichiers :

Collapsed comments

(Figure 38) Commentaires réduits

Quand les commentaires sont réduits, ils peuvent être développés facilement via un clic sur l’icône dans la marge, puis à nouveau réduits via un autre clic. Les info-bulles (Figure 39) facilitent la lecture d’un commentaire spécifique sans avoir à afficher le thread tout entier.

Collapsed comment tooltip

(Figure 39) Info-bulle de commentaire réduit

Listes de tâches dans les descriptions et les commentaires des demandes de tirage (pull requests)

Lors de la préparation d’une demande de tirage ou quand vous ajoutez des commentaires, vous voulez a priori faire le suivi d’un petit nombre de choses, mais en réalité, vous finissez par modifier le texte ou par ajouter plusieurs commentaires. Les listes de tâches légères sont un excellent moyen de suivre la progression d’une liste de choses à faire en tant que créateur ou réviseur d’une demande de tirage dans la description, ou sous la forme d’un commentaire unique regroupé. Cliquez sur la barre d’outils Markdown pour commencer ou pour appliquer le format au texte sélectionné (Figure 40).

Task list toolbar

(Figure 40) Barre d’outils de liste de tâches

Une fois que vous avez ajouté une liste de tâches (Figure 41), vous pouvez simplement cocher les cases pour marquer les éléments comme étant terminés. Ceux-ci sont exprimés et stockés dans le commentaire sous la forme [ ] et [x] dans Markdown. Pour plus d’informations, consultez Aide sur Markdown.

Task list

(Figure 41) Liste de tâches

Possibilité de faire des « Like » (J’aime) sur des commentaires dans les demandes de tirage (pull requests)

Exprimez votre adhésion à un commentaire de demande de tirage en cliquant sur le bouton J’aime (Figure 42). Vous pouvez consulter la liste de toutes les personnes qui ont aimé le commentaire en pointant sur le bouton.

Like pull request comments

(Figure 42) Faire des « Like » (J’aime) sur des commentaires de demande de tirage

Workflow amélioré lors de l’approbation avec des suggestions

L’utilisation de l’option Achèvement automatique avec les demandes de tirage (Figure 43) est un excellent moyen d’améliorer votre productivité, mais il ne doit pas mettre fin aux discussions actives avec les réviseurs de code. Pour faciliter ces discussions, le vote Approuver avec des suggestions va maintenant apparaître quand une demande de tirage est achevée automatiquement. L’utilisateur a la possibilité d’annuler l’achèvement automatique pour que ses commentaires puissent être lus, ou de conserver et d’autoriser l’achèvement automatique de la demande de tirage quand toutes les stratégies sont satisfaites.

Cancel auto-complete dialog

(Figure 43) Boîte de dialogue Annuler la complétion automatique

Prise en charge du filtrage des chemins pour les notifications Git

Au lieu de recevoir des notifications pour tous les dossiers d’un dépôt, vous pouvez désormais choisir de recevoir une notification quand des membres de l’équipe créent des demandes de tirage ou envoient (push) du code seulement dans les dossiers qui vous intéressent. Lors de la création d’abonnements aux notifications par e-mail d’envois Git ou de demandes de tirage Git personnalisés, vous voyez une nouvelle option pour filtrer ces notifications par chemins de dossiers (Figure 44).

Path filtering for notifications

(Figure 44) Filtrage des chemins pour les notifications

Mise à jour des modèles d’e-mail pour les workflows des demandes de tirage (pull requests)

Les alertes par e-mail des demandes de tirage ont été actualisées et rendues claires, concises et exploitables (Figure 45). La ligne Objet commence par le titre de la demande de tirage ; les informations secondaires, comme le nom et l’ID du dépôt, sont reportées à la fin. Le nom de l’auteur a été ajouté à l’objet pour simplifier l’application de règles et de filtres en fonction de la personne qui a créé la demande Pull.

Le corps des e-mails d’alerte a un modèle actualisé qui récapitule d’abord la raison pour laquelle l’alerte a été envoyée, suivie des métadonnées critiques (titre, noms des branches et description) et un bouton d’appel à l’action principal. Des détails supplémentaires, comme les réviseurs, les fichiers, et les validations, apparaissent plus bas dans l’e-mail.

Improved email template

(Figure 45) Modèle d’e-mail amélioré

Pour la plupart des alertes, l’appel à l’action (Figure 46) est d’afficher la demande de tirage sur le web. Toutefois, quand vous recevez une notification à propos d’un commentaire spécifique, l’appel à l’action sera directement lié à ce commentaire, pour vous permettre de trouver facilement le code et la conversation préalable pour le contexte.

Email call-to-action

(Figure 46) Appel à l’action par e-mail

Mise à jour des modèles d’e-mail pour les notifications Push

Les notifications Push ont été mises à jour à l’image des nouveaux modèles d’e-mail, qui sont optimisés pour être clairs, concis et exploitables (Figure 47). La ligne d’objet vous permet de distinguer clairement les e-mails Push et d’identifier la branche, le dépôt et l’auteur. Par ailleurs, elle récapitule le nombre de validations incluses dans l’envoi (push). Ces évolutions permettent aussi de créer plus facilement des règles et des filtres pour mieux gérer ces notifications par e-mail.

Le corps de l’e-mail est semblable aux autres e-mails, indiquant le motif de l’envoi, la personne à l’origine de l’action et ce qui s’est passé exactement. Spécificité des alertes Push, tous les détails concernant le dépôt, la branche, les fichiers et les validations sont fournis pour renseigner les destinataires à sujet de l’étendue des modifications. Le principal appel à l’action pour les alertes d’envoi (push) est Afficher l’envoi (push), qui ouvre la vue des envois pour l’envoi qui a généré l’alerte.

Push template

(Figure 47) Modèle d’envoi (push)

Wiki

Chaque projet prend désormais en charge son propre Wiki (Figure 48). Vous pouvez maintenant facilement écrire des pages qui aident les membres de votre équipe à comprendre, utiliser et contribuer à votre projet.

Wiki page

(Figure 48) Page Wiki d’une demande de tirage

Voici quelques-unes des principales fonctionnalités du nouveau Wiki :

  • Expérience d’édition simplifiée en utilisant la syntaxe Markdown.
  • La nouvelle page vous permet de spécifier un titre et d’ajouter du contenu. (Figure 49)

Title wiki

(Figure 49) Wiki Titre de la demande Pull

  • Prise en charge des balises HTML dans Markdown (Figure 50).

Wiki HTML tags

(Figure 50) Balises HTML du Wiki de demande de tirage

  • Redimensionnez de façon pratique les images dans le dossier Markdown (Figure 51).

Image resize

(Figure 51) Redimensionnement d’image de demande de tirage

  • Volet de gestion avancée des pages qui vous permet de réorganiser, de changer la page parent et de gérer des pages.
  • Possibilité de filtrer les pages par titre pour les grands Wikis (Figure 52).

Wiki menu

(Figure 52) Menu du Wiki d’une demande de tirage

Pour plus d’informations, consultez Bien démarrer avec Wiki.

  • Plus vous utilisez Wiki, plus vous risquez d’enregistrer des modifications non souhaitées. Vous pouvez désormais rétablir une révision d’une page Wiki en affichant les détails de la révision et en cliquant sur le bouton Rétablir (Figure 53).

Wiki revert button

(Figure 53) Bouton Rétablir du Wiki de demande de tirage

Nous avons observé un modèle lors de la création d’un Wiki, où une table des matières sur une page Wiki incluait des liens inexistants (Figure 54). Les utilisateurs cliquaient sur ces liens pour créer une vraie page. Avant, nous gérions ce scénario en affichant un avertissement indiquant que le lien était rompu ou que la page n’existait pas. Maintenant, nous le gérons plutôt comme un scénario normal pour Wiki, en vous permettant de créer des pages.

Create wiki page

(Figure 54) Créer une page Wiki PR

Lien profond de page Wiki

Le Wiki prend désormais en charge les sections de lien profond au sein d’une page ou plusieurs pages, ce qui s’avère très utile pour créer une table des matières. Vous pouvez référencer un titre dans la même page ou dans une autre page en utilisant la syntaxe suivante :

  • Même page :[text to display](#section-name)
  • Autre page :[text to display](/page-name#section-name)

L’extension Wiki sur la Place de marché est désormais dépréciée. Si vous utilisez une extension Wiki existante, vous pouvez migrer vos pages Wiki vers le nouveau Wiki à l’aide de cet outil de migration. Découvrez comment migrer vos pages Wiki existantes vers le nouveau Wiki.

Gestion des packages

Mise à jour de l’expérience de gestion des packages

Les URL des packages fonctionnent désormais avec le nom et la version du package, à la place des GUID. Cela facilite la création manuelle des URL de package (Figure 55). Le format est : \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package.

Package URL

(Figure 55) URL de package de demande de tirage

Vous pouvez désormais masquer les versions de packages supprimées (Figure 56) pour tous les utilisateurs d’un flux (plus de packages barrés !), en réponse à cette suggestion UserVoice.

Hide deleted packages

(Figure 56) Masquer les packages supprimés

Toutes les actions que vous pouviez effectuer sur la page des détails d’un package peuvent désormais être effectuées à partir du menu contextuel dans la liste des packages.

La liste des packages contient une nouvelle colonne Dernier envoi (push) ((Figure 57) avec des dates lisibles, ce qui vous permet de trouver facilement les packages récemment mis à jour.

Last pushed column

(Figure 57) Colonne Dernier envoi (push)

Packages Maven

Nous avons lancé la prise en charge de l’hébergement des artefacts Maven dans TFS 2018 (Figure 58). Les artefacts Maven permettent aux développeurs Java de partager facilement du code et des composants. Consultez notre guide de démarrage pour savoir comment partager des artefacts Maven en utilisant la gestion des packages.

Maven packages

(Figure 58) Packages Maven

Nouvelle tâche NuGet unifiée

Nous avons regroupé les tâches Restauration NuGet, NuGet Packager et NuGet Publisher en une tâche de génération NuGet unifiée, de façon à mieux s’aligner avec le reste de la bibliothèque des tâches de génération. La nouvelle tâche utilise NuGet 4.0.0 par défaut. En conséquence, nous avons déprécié les anciennes tâches et nous vous recommandons de passer à la nouvelle tâche NuGet quand vous en avez le temps. Cette modification coïncide avec une vague d’améliorations décrites ci-dessous, auxquelles vous pouvez accéder seulement en utilisant la tâche combinée.

Dans le cadre de ce travail, nous avons également publié une nouvelle tâche Programme d’installation de l’outil NuGet, qui contrôle la version de NuGet disponible sur le CHEMIN et utilisée par la nouvelle tâche NuGet. Par conséquent, pour utiliser une version plus récente de NuGet, ajoutez simplement une tâche Programme d’installation de l’outil NuGet au début de votre génération (Figure 59).

Nuget task

(Figure 59) Tâche NuGet

Lisez-en davantage sur l’utilisation de la dernière version de NuGet dans votre build sur le Blog Microsoft DevOps.

Option « Permettre d’ignorer les doublons » de NuGet

De nombreux clients NuGet nous ont indiqué qu’ils génèrent un ensemble de packages, dont seuls quelques-uns peuvent avoir des mises à jour (et donc des numéros de version mis à jour). La tâche de génération NuGet a une nouvelle option, Permettre d’ignorer les doublons, qui permet à la tâche de continuer si elle tente d’envoyer (push) des packages à un flux VSTS/TFS où la version est déjà en utilisée.

mises à jour des tâches de génération npm

Quelle que soit la plateforme sur laquelle vous générez votre projet npm (Windows, Linux ou Mac), la nouvelle tâche de génération NPM fonctionne sans problème. Nous avons également réorganisé la tâche pour rendre npm install et npm publish plus faciles. Pour les commandes install et publish, nous avons simplifié l’acquisition des informations d’identification pour que les informations d’identification des Registres répertoriés dans le fichier .npmrc du projet puissent être stockées de façon sécurisée dans un point de terminaison de service. Sinon, si vous utilisez un flux VSTS/TFS, nous proposons un sélecteur qui vous permet de choisir un flux. Ensuite nous générons un fichier .npmrc avec les informations d’identification nécessaires utilisées par l’agent de build.

Maven prend désormais en charge les flux authentifiés

Contrairement à NuGet et npm, la tâche de génération Maven ne fonctionnait pas avec les flux authentifiés. Nous avons mis à jour la tâche Maven pour vous permettre d’utiliser facilement les flux VSTS/TFS (Figure 60).

dotnet task

(Figure 60) Tâche dotnet

La tâche dotnet prend en charge les flux authentifiés et les projets web

La prochaine version majeure de la tâche dotnet (2.x) apporte une réponse à un grand nombre des demandes de vos commentaires et résout un ensemble de bogues que nous avons suivis pendant un certain temps.

  1. Tout d’abord, dotnet prend désormais en charge les sources de packages authentifiées, comme le Gestionnaire de package : vous n’avez donc plus besoin d’utiliser la tâche NuGet pour restaurer les packages à partir de sources de packages privées.
  2. Le comportement du champ Chemin des projets a changé dans la version 2.0 de la tâche. Dans les versions précédentes de la tâche, si le ou les fichiers projet correspondant au modèle spécifié étaient introuvables, la tâche consignait un avertissement dans le journal puis se terminait correctement. Dans de tels scénarios, il pouvait parfois être difficile de comprendre pourquoi la génération avait réussi alors que les dépendances n’étaient pas restaurées. Désormais, la tâche échoue si le ou les fichiers projet correspondant au modèle spécifié sont introuvables. Ceci est aligné sur le comportement d’autres tâches, et est facile à comprendre et à utiliser.
  3. Dans les versions précédentes de la commande publish de la tâche, la tâche modifiait le chemin de sortie en plaçant tous les fichiers dans un dossier qui était nommé d’après le nom du fichier projet, même quand vous passiez un chemin de sortie explicite. Ceci rendait difficile le chaînage des commandes. Vous contrôlez désormais le fichier du chemin de sortie.

Nous avons également publié une nouvelle tâche Programme d’installation de l’outil dotnet, qui contrôle la version de dotnet disponible sur le CHEMIN et utilisée par la nouvelle tâche dotnet. Ainsi, pour utiliser une version plus récente de dotnet, ajoutez simplement une tâche Programme d’installation de l’outil dotnet au début de votre génération.

Travailler en dehors de votre compte/collection

Il est désormais plus facile de travailler avec des flux (Figure 61) en dehors de votre serveur TFS ou de votre compte VSTS, que ce soit des flux Gestion de packages dans un autre compte VSTS ou un autre serveur TFS, ou des flux autres que Gestion de packages, comme NuGet.org/npmjs.com, Artifactory ou MyGet (Figure 60). Des types de points de terminaison de service dédiés à NuGet et npm facilitent l’entrée des informations d’identification correctes, et permettent aux tâches de génération de fonctionner sans problème lors des opérations de chargement de package et d’envoi (push) de package.

Feeds to use

(Figure 61) Flux à utiliser

Sélecteur de flux pour les flux VSTS/TFS

Nous recommandons toujours d’archiver un fichier de configuration (par exemple NuGet.Config, .npmrc, etc.), afin que votre dépôt de fichiers sources ait toujours un enregistrement de la provenance de vos packages. Toutefois, vous nous avez indiqué que ce n’était pas idéal dans un certain nombre de scénarios : nous avons donc ajouté une nouvelle option Utiliser les packages de ce flux VSTS/TFS qui vous permet de sélectionner un flux et de générer automatiquement un fichier de configuration qui est utilisé pour cette étape de génération (Figure 62).

Feed picker

(Figure 62) Sélecteur de flux

Générer et publier

Suppression de la prise en charge des builds XAML

Dans TFS 2015, nous avons introduit un système de génération multiplateforme basé sur le web. Dans TFS 2018, il s’agit du seul modèle que nous prenons en charge. Les builds XAML ne sont pas prises en charge dans TFS 2018. Nous vous encourageons à migrer vos builds XAML. Si vous n’êtes pas encore prêt à migrer et que vous devez continuer à utiliser des builds XAML, n’effectuez pas la mise à niveau vers TFS 2018.

Quand vous effectuez la mise à niveau vers TFS 2018 :

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

  • Dans TFS 2018, vous pourrez voir les builds XAML terminées, mais vous ne pourrez pas en placer de nouvelles en file d’attente.

  • Il n’existe pas de nouvelle version du contrôleur ou de l’agent de build XAML dans TFS 2018, et vous ne pouvez pas en configurer une version antérieure pour la faire fonctionner avec TFS 2018.

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

Exporter et importer des définitions de build

Les définitions de build sont implémentées en interne en tant que fichiers .json : vous pouvez donc voir des informations détaillées sur les modifications dans l’historique du fichier. Vous pouvez déjà cloner et créer des modèles à partir de vos définitions de build, mais de nombreux utilisateurs ont souhaité prendre une copie de leur logique de génération CI et la réutiliser dans un autre projet d’équipe. Il s’agissait en fait d’une demande parmi les dix premières sur UserVoice.

Nous avons le plaisir de vous annoncer que vous pouvez désormais le faire (Figure 63) et (Figure 64) !

Export build definition

(Figure 63) Exporter une définition de build

Import build definition

(Figure 64) Importer une définition de build

Extensions avec les modèles de build

Les modèles de build vous permettent de créer une base de référence pour les utilisateurs qui peuvent ainsi commencer à définir leur processus de génération. Nous en livrons un certain nombre avec le produit aujourd’hui et, si vous pouviez en télécharger de nouvelles dans votre compte, il n’était jamais possible pour les auteurs d’extensions d’inclure de nouveaux modèles dans le cadre d’une extension. Vous pouvez désormais inclure des modèles de build dans vos extensions. Exemple :

{  "id": "Template1", 
   "type": "ms.vss-build.template", 
   "targets": [ "ms.vss-build.templates" ], 
   "properties": { "name": "Template1" } }

Pour l’exemple complet, consultez https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

Conseil

Vous pouvez utiliser cette fonctionnalité pour proposer et partager le même modèle personnalisé pour tous vos projets d’équipe.

Déprécier une tâche dans une extension

Vous pouvez désormais déprécier une tâche dans votre extension. Pour que cela fonctionne, vous devez ajouter la variable suivante à la version la plus récente de votre tâche :

"deprecated": true

Quand l’utilisateur recherche les tâches dépréciées (Figure 65), nous envoyons (push) ces tâches à la fin et nous les regroupons dans une section réduite par défaut. Si une définition utilise déjà une tâche dépréciée, nous affichons un badge de tâche dépréciée pour encourager les utilisateurs à passer à la tâche de remplacement.

Deprecated task badge

(Figure 65) Badge de tâche dépréciée

Vous pouvez aider vos utilisateurs à en savoir plus sur la tâche de remplacement en la mentionnant dans la description de la tâche (Figure 66). La description pointera alors vers les personnes utilisant la tâche dans le bon sens depuis le catalogue des tâches et les définitions de build/mise en production existantes.

Deprecated task description

(Figure 66) Description de la tâche dépréciée

Définir la visibilité de la section de contrôle

Avant, si vous utilisiez une extension qui avait des tâches de builds et des sections de résumé de la build, vous pouviez voir la section de résumé de la build, même si vous n’utilisiez pas la tâche de build dans cette build. Vous pouvez désormais choisir de masquer ou d’afficher cette section dans la page de résumé de la build en ajoutant la ligne suivante dans le code de votre extension, et en définissant la valeur sur true ou sur false :

VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);

Consultez l’exemple inclus dans le dépôt vsts-extension-samples de Microsoft.

Prise en charge des groupes de variables

Les groupes de variables étaient disponibles pour être utilisés dans les définitions de mise en production. Elles sont désormais prêtes à être utilisées aussi dans les définitions de build. Découvrez plus d’informations sur la création d’un groupe de variables. Ceci a été développé selon une priorité basée sur des suggestions relatives aux variables de build/mise en production de niveau projet et aux groupes de variables dans les définitions de build.

Travailler avec des fichiers sécurisés, comme des certificats Apple

Nous avons ajouté une bibliothèque de fichiers sécurisés à usage général (Figure 67).

Secure files library

(Figure 67) Bibliothèque de fichiers sécurisés

Utilisez la bibliothèque de fichiers sécurisés pour stocker des fichiers comme les certificats de signature, les profils de provisionnement Apple, les fichiers de magasin de clés Android et les clés SSH sur le serveur, sans avoir à les valider dans votre dépôt source.

Le contenu des fichiers sécurisés est chiffré, et peut être utilisé seulement lors des processus de génération ou de publication en les référençant depuis une tâche. Les fichiers sécurisés sont disponibles sur plusieurs définitions de build et de mise en production dans le projet d’équipe, en fonction des paramètres de sécurité. Les fichiers sécurisés suivent le modèle de sécurité de la bibliothèque.

Nous avons également ajouté certaines tâches Apple qui tirent parti de cette nouvelle fonctionnalité :

Mettre en pause les définitions de build

Vous pouvez désormais mettre en pause ou désactiver les définitions de build. Si vous envisagez de modifier votre définition de build et que vous voulez éviter de mettre en file d’attente les nouvelles builds en attendant que vous ayez fini, désactivez simplement la définition de build. De même, si vous envisagez de mettre à niveau des ordinateurs agent, vous pouvez choisir de mettre en pause une définition de build, ce qui permet à VSTS de toujours accepter les nouvelles demandes de build tout en les laissant en file d’attente sans les exécuter jusqu’à ce que vous repreniez la définition.

Prise en charge de la validation des entrées de tâches

La saisie des paramètres dans les tâches de définition de build peut parfois entraîner des erreurs. Avec la validation des entrées de tâches, les auteurs des tâches ont l’assurance que les valeurs spécifiées sont correctes. Les expressions de validation suivent la syntaxe d’expression habituellement utilisée pour les conditions des tâches et peuvent utiliser toutes les fonctions prises en charge, en plus des fonctions générales prises en charge par les conditions des tâches, notamment celles relatives aux URL, à IPV4, à sha1, à l’e-mail, à la plage de numéros, à la longueur ou à la correspondance.

Pour plus d’informations sur les objectifs et l’utilisation, consultez la page vsts-tasks du dépôt.

Nouvelle éditeur de définition de mise en production

Dans la même optique d’actualisation des expériences de build et de mise en production, nous avons repensé l’éditeur de définition de mise en production de façon à offrir une expérience plus intuitive, corriger certains points problématiques et ajouter de nouvelles fonctionnalités. Une des fonctionnalités les plus puissantes du nouvel éditeur est sa capacité à vous donner un aperçu de la progression des déploiements dans vos environnements. Par ailleurs, les approbations, les propriétés d’environnement et les paramètres de déploiement sont désormais contextuels et facile à configurer.

Visualisation du pipeline

Le pipeline (Figure 68) de l’éditeur fournit une vue graphique de la façon dont les déploiements progressent dans une mise en production. Les artefacts sont consommés par la mise en production et déployés sur les environnements. La disposition et la liaison des environnements reflètent les paramètres des déclencheurs définis pour chaque environnement.

Pipeline

(Figure 68) Pipeline de mise en production

Interface utilisateur de la configuration contextuelle

Les artefacts, les déclencheurs de mise en production, les approbations de prédéploiement et de postdéploiement, les propriétés d’environnement et les paramètres de déploiement sont désormais contextuels et faciles à configurer (Figure 69).

Release configuration

(Figure 69) Configuration de la mise en production

Bien démarrer avec les modèles de déploiement

Tous les modèles de déploiement intégrés sont dotés de paramètres de processus qui aident les utilisateurs à démarrer plus facilement en spécifiant les paramètres les plus importants sans avoir à s’attarder sur les tâches (Figure 70).

Deployment templates

(Figure 70) Modèles de déploiement

Gestion simplifiée des variables de mise en production et d’environnement

Utilisez la vue Liste pour ajouter rapidement des variables de mise en production ou d’environnement et la vue Grille pour comparer et modifier côte à côte des variables sur toutes les étendues (Figure 71). Par ailleurs, vous pouvez utiliser la recherche par mot clé ou par filtre pour gérer l’ensemble de variables à utiliser dans les deux vues.

Simplified management of variables

(Figure 71) Gestion simplifiée des variables

Éditeur de tâche et de phase amélioré

Toutes les améliorations du nouvel éditeur de définition de build sont maintenant aussi disponibles dans l’éditeur de définition de mise en production (Figure 72). Vous pouvez rechercher des tâches et les ajouter en utilisant le bouton Ajouter ou via un glisser-déplacer. Vous pouvez réorganiser ou cloner des tâches via un glisser-déplacer.

Task editor

(Figure 72) Éditeur de tâche

Onglets Groupes de variables, Rétention et Options

Vous pouvez désormais lier/dissocier des groupes de variables (Figure 73), définir la stratégie de conservation des différents environnements et modifier les paramètres au niveau de la définition de mise en production, comme le format du numéro de mise en production, à partir de l’onglet Options. Vous pouvez aussi enregistrer un environnement comme modèle de déploiement, définir des autorisations au niveau de l’environnement et réorganiser des phases dans l’onglet Tâches.

Variable groups

(Figure 73) Groupes de variables

Utilisez les opérations au niveau de l’environnement pour l’enregistrer comme modèle et définir la sécurité (Figure 74).

Environment menu

(Figure 74) Menu de l’environnement

Pour plus d'informations, consultez la documentation de l’éditeur de définition de mise en production.

Déploiement de machines virtuelles à l’aide de groupes de déploiement

Release Management prend désormais en charge des déploiements prédéfinis robustes sur plusieurs machines. Vous pouvez désormais orchestrer des déploiements sur plusieurs machines et effectuer des mises à jour propagées, tout en assurant la haute disponibilité de l’application tout au long du processus.

La fonctionnalité de déploiement basée sur un agent s’appuie sur les mêmes agents de build et de déploiement. Toutefois, contrairement à l’approche actuelle où vous installez les agents de build et de déploiement sur un ensemble de serveurs proxy dans un pool d’agents et où vous pilotez les déploiements sur des serveurs cibles distants, vous installez l’agent directement sur chacun de vos serveurs cibles et vous pilotez les déploiements propagés sur ces serveurs. Vous pouvez utiliser le catalogue complet des tâches sur vos machines cibles.

Un groupe de déploiement (Figure 75) est un groupe logique de (machines) cibles avec des agents installés sur chacune d’elles. Les groupes de déploiement représentent vos environnements physiques, comme un développement à option unique, une AQ sur plusieurs machines et une batterie de machines pour UAT/Production. Ils spécifient également le contexte de sécurité pour vos environnements physiques.

Deployment groups

(Figure 75) Groupes de déploiement

Vous pouvez utiliser ceci sur toutes les machines virtuelles que vous inscrivez auprès de notre agent. Nous avons également rendu très facile l’inscription auprès d’Azure via la prise en charge d’une extension de machine virtuelle Azure qui installe automatiquement l’agent quand la machine virtuelle démarre. Nous héritons automatiquement des étiquettes sur la machine virtuelle Azure quand elle est inscrite.

Une fois que vous avez un groupe de déploiement, vous configurez simplement ce que vous voulez que nous exécutions sur ce groupe de déploiement (Figure 76). Vous pouvez contrôler ce qui est exécuté sur quelles machines en utilisant des étiquettes, et contrôler la vitesse à laquelle le lancement est effectué.

Configure deployment groups

(Figure 76) Configurer des groupes de déploiement

Quand le déploiement est exécuté, les journaux indiquent la progression sur tout le groupe de machines que vous ciblez (Figure 77).

Deployment group progress

(Figure 77) Progression d’un groupe de déploiement

Cette fonctionnalité fait désormais partie intégrante de Release Management. Aucune licence supplémentaire n'est nécessaire.

Amélioration de l’interface utilisateur des groupes de déploiement

Toujours dans l’optique d’actualiser les expériences de Build et mise en production, nous avons repensé nos pages de groupes de déploiement pour une expérience plus claire et plus intuitive (Figure 78). À partir de la page d’accueil, vous pouvez consulter l’état d’intégrité des cibles du groupe de déploiement. Vous pouvez aussi gérer la sécurité d’un groupe de déploiement déterminé ou définir les autorisations par défaut de tous les groupes de déploiement.

Deployment groups UI

(Figure 78) Interface utilisateur des groupes de déploiement

Pour une cible au sein d’un groupe de déploiement, vous pouvez afficher un récapitulatif, les déploiements récents et les capacités de la cible. (Figure 79). Vous pouvez définir des étiquettes sur la cible et contrôler ce qui s’exécute sur chaque cible. Nous prévoyons pour les prochaines versions d’ajouter la prise en charge des filtres pour les groupes de déploiement.

Deployment groups UI tags

(Figure 79) Étiquettes de l’interface utilisateur des groupes de déploiement

Références de groupe de tâches

Les groupes de tâches vous permettent de définir un ensemble de tâches que vous pouvez ajouter à vos définitions de build ou de mise en production (Figure 80). C’est pratique si vous devez utiliser le même regroupement de tâches dans plusieurs builds ou mises en production. Pour vous aider à assurer le suivi des consommateurs d’un groupe de tâches, vous disposez désormais d’une vue sur les définitions de build, les définitions de mise en production et les groupes de tâches qui référencent votre groupe de tâches (Figure 79).

Task group references

(Figure 80) Références de groupe de tâches

Quand vous essayez de supprimer un groupe de tâches qui est toujours référencé, nous vous avertissons et nous vous fournissons un lien vers cette page.

Gestion des versions des groupes de tâches

La modification d’un groupe de tâches peut être risquée, car la modification est effective sur toutes les définitions qui utilisent le groupe de tâches. Avec la gestion des versions des groupes de tâches, vous pouvez désormais faire des brouillons et obtenir un aperçu des versions d’un groupe de tâches, tout en offrant néanmoins des versions stables de vos définitions les plus importantes jusqu’au moment où vous êtes prêt à en changer. Après avoir conçus les brouillons par itération, vous pouvez publier une version stable et, lors de la publication, si des modifications représentent une rupture importante, vous pouvez choisir de publier le groupe de tâches sous forme de préversion (une nouvelle version majeure). Vous pouvez aussi la publier directement en tant que version stable mise à jour (Figure 81).

Quand une nouvelle version majeure (ou une préversion) du groupe de tâches est disponible, l’éditeur de définition vous indique qu’il existe une nouvelle version. Si cette version majeure est une préversion, vous voyez même un message « Essayez-la ». Quand le groupe de tâches n’est plus une préversion, les définitions qui l’utilisent sont mises à jour automatiquement, en suivant ce cycle de versions majeures (Figure 82).

Save as draft

(Figure 81) Enregistrer le groupe de tâches comme brouillon

Publish task group as preview

(Figure 82) Publier un groupe de tâches comme aperçu

Importation et exportation de groupes de tâches

Bien que les groupes de tâches puissent être réutilisés au sein d’un projet, nous savons que la recréation d’un groupe de tâches dans des projets et des comptes peut être laborieuse. Avec l’importation/exportation des groupes de tâches (Figure 83), comme nous l’avons fait pour les définitions de mise en production, vous pouvez désormais les exporter sous forme de fichier JSON et les importer où vous voulez. Nous avons également activé les groupes de tâches imbriqués, qui se développent quand ils sont exportés.

Export task group

(Figure 83) Exporter un groupe de tâches

Prise en charge des configurations multiples dans les tâches côté serveur (sans agent)

En spécifiant des multiplicateurs de variables pour les tâches côté serveur (sans agent) (Figure 84), vous pouvez désormais exécuter le même ensemble de tâches dans une phase sur plusieurs configurations, qui s’exécutent en parallèle.

Multi configuration of agentless tasks

(Figure 84) Multiconfiguration de tâches sans agent

Prise en charge des variables dans la tâche Intervention manuelle

La tâche Intervention manuelle (Figure 85) prend désormais en charge l’utilisation de variables dans le texte d’instruction affiché aux utilisateurs lors de l’exécution de la tâche, au moment où l’utilisateur peut reprendre l’exécution du processus de génération de version ou le rejeter. Toutes les variables définies et disponibles dans la version peuvent être incluses. Les valeurs sont utilisées dans les notifications ainsi que dans l’e-mail envoyé aux utilisateurs (Figure 86).

Manual intervention task

(Figure 85) Tâche d’intervention manuelle

Manual intevention pending dialog

(Figure 86) Boîte de dialogue d’intervention manuelle en attente

Contrôle des versions dans un environnement basé sur la branche source

Une définition de mise en production peut être configurée pour déclencher un déploiement automatiquement quand une nouvelle version est créée, généralement après la réussite d’une build de la source. Cependant, vous pouvez déployer seulement des builds provenant de branches spécifiques de la source, au lieu de toutes les builds qui ont réussi.

Par exemple, vous voulez que toutes les builds soient déployées dans les environnements de développement et de test, mais que seules des builds spécifiques soient déployées en production. Auparavant, vous deviez pour cela gérer deux pipelines de versions distincts, un pour les environnements de développement et de test, et l’autre pour l’environnement de production.

Release Management prend désormais en charge l’utilisation de filtres d’artefacts pour chaque environnement. Cela signifie que vous pouvez spécifier les mises en production qui seront déployées sur chaque environnement quand les conditions du déclencheur de déploiement (comme la réussite d’une build et la création d’une nouvelle mise en production) sont remplies. Dans la section Déclencheur de la boîte de dialogue Conditions de déploiement de l’environnement (Figure 87), sélectionnez les conditions des artefacts, comme la branche source et les étiquettes, pour les builds qui déclencheront un nouveau déploiement sur cet environnement.

Deployment conditions dialog

(Figure 87) Boîte de dialogue Conditions de déploiement

Par ailleurs, la page Résumé de la mise en production (Figure 88) contient désormais une info-bulle contextuelle qui indique la raison pour laquelle tous les déploiements « non démarrés » sont dans cet état, et suggère comment ou quand le déploiement démarrera.

Release summary tip

(Figure 88) Info-bulle de résumé de la mise en production

Déclencheurs de version pour les dépôts Git comme source d’artefacts

Release Management prend désormais en charge la configuration d’un déclencheur de déploiement continu (Figure 89) pour les dépôts Git liés à une définition de mise en production dans les projets d’équipe du même compte. Ceci vous permet de déclencher automatiquement une version quand une nouvelle validation est effectuée dans le dépôt. Vous pouvez également spécifier une branche du dépôt Git pour laquelle les validations déclenchent une version.

Release triggers

(Figure 89) Déclencheurs de mise en production

Déclencheurs de mise en production : déploiement continu pour les modifications envoyées (push) dans un dépôt Git

Release Management a toujours fourni la possibilité de configurer un déploiement continu à la fin d’une build. Cependant, vous pouvez maintenant aussi configurer un déploiement continu sur un envoi (push) à Git. Cela signifie que vous pouvez lier des dépôts GitHub et Team Foundation Git en tant que sources d’artefacts à une définition de mise en production, puis déclencher des mises en production automatiquement pour des applications comme Node.JS et PHP, qui ne sont pas générées à partir d’une build : vous n’avez donc pas besoin d’une action de génération pour un déploiement continu.

Filtres de branche dans les déclencheurs d’environnement

Dans le nouvel éditeur de définition de mise en production, vous pouvez désormais spécifier les conditions des artefacts pour un environnement particulier. Avec ces conditions d’artefacts, vous aurez un contrôle plus précis sur les artefacts à déployer dans un environnement spécifique. Par exemple, pour un environnement de production, vous devez veiller à ce que seules soient déployées les builds générées à partir de la branche maître. Ce filtre doit être défini pour tous les artefacts qui, selon vous, doivent répondre à ces critères.

Vous pouvez aussi ajouter plusieurs filtres pour chaque artefact lié à la définition de mise en production (Figure 90). Le déploiement dans cet environnement ne sera déclenché que si toutes les conditions d’artefact sont réunies.

Branch filters

(Figure 90) Filtres de branche

Améliorations apportées aux tâches côté serveur

Nous avons apporté deux améliorations des tâches côté serveur (des tâches qui s’exécutent dans une phase serveur).

Nous avons ajouté une nouvelle tâche qui peut être utilisée pour appeler n’importe quelle API REST HTTP générique (Figure 91) dans le cadre du pipeline automatisé. Par exemple, elle peut être utilisée pour appeler un traitement spécifique avec une fonction Azure et attendre qu’elle se termine.

REST API task

(Figure 91) Tâches d’API REST

Nous avons aussi ajouté une section Options de contrôle (Figure 92) à toutes les tâches côté serveur. Le comportement des tâches comprend maintenant les options Activé, Continuer en cas d’erreur, Toujours exécuter et Délai d’attente.

Task control options

(Figure 92) Options de contrôle des tâches

Badge d’état de la version dans le hub Code

Aujourd’hui, si vous souhaitez savoir si une validation est déployée dans l’environnement de production de votre client, vous déterminez d’abord quelle build consomme la validation puis vous vérifiez ensuite tous les environnements de mise en production où cette build est déployée. Cette expérience est désormais beaucoup plus facile avec l’intégration de l’état du déploiement dans le badge d’état du hub Code pour afficher la liste des environnements sur lesquels votre code est déployé. Pour chaque déploiement, l’état est publié à la dernière validation qui faisait partie du déploiement. Si une validation est déployée sur plusieurs définitions de mise en production (avec plusieurs environnements), chaque définition a une entrée dans le badge, avec l’état indiqué pour chaque environnement (Figure 93). Ceci améliore la traçabilité de la validation du code pour les déploiements.

Release status badge

(Figure 93) Badge d’état de la mise en production

Par défaut, quand vous créez une définition de mise en production, l’état du déploiement est publié pour tous les environnements. Toutefois, vous pouvez choisir les environnements dont l’état du déploiement doit être affiché dans le badge d’état (par exemple, afficher seulement les environnements de production) (Figure 94).

Deployment options dialog

(Figure 94) Boîte de dialogue Options de déploiement

Améliorations apportées au menu Définition de build lors de l’ajout d’artefacts

Au moment d’ajouter des artefacts de build à une définition de mise en production, vous pouvez désormais afficher les définitions avec des informations sur l’organisation de leurs dossiers et simplifier le choix de la définition souhaitée (Figure 95). Ceci facilite la différenciation des noms identiques de définition de build, mais dans des dossiers différents.

Add artifact

(Figure 95) Ajouter un artefact

La liste des définitions est filtrée en fonction de celles qui contiennent le terme du filtre.

Rétablir votre définition de mise en production à une version antérieure

Aujourd’hui, si une définition de mise en production est mise à jour, vous ne pouvez pas la rétablir directement à une version antérieure. Le seul moyen de le faire est de rechercher les différences des modifications dans l’historique des définitions de mises en production, puis de modifier manuellement la définition de mise en production. Désormais, avec la fonctionnalité Restaurer la définition (Figure 96), vous pouvez choisir et revenir à n’importe quelle version antérieure d’une définition de mise en production, à partir de l’onglet Historique de la définition de mise en production.

Revert release definition

(Figure 96) Restaurer la définition de mise en production

Notifications personnalisées pour les mises en production

Les notifications de mise en production sont désormais intégrées à l’expérience des paramètres de notification de VSTS. Les personnes en charge de la gestion des mises en production sont désormais automatiquement notifiées des actions en attente (approbations ou interventions manuelles) et des échecs de déploiement importants. Vous pouvez désactiver ces notifications en accédant aux paramètres de Notification sous le menu de profil et en désactivant les Abonnements de mise en production. Vous pouvez aussi vous abonner à des notifications supplémentaires en créant des abonnements personnalisés. Les administrateurs peuvent contrôler les abonnements des équipes et des groupes à partir des paramètres de Notification sous les paramètres Équipe et Compte.

Les auteurs de définitions de mise en production n’ont plus besoin d’envoyer manuellement des e-mails pour les approbations et les exécutions de déploiements.

Cela est particulièrement utile pour les grands comptes qui ont plusieurs parties prenantes pour les mises en production, et pour les personnes autres que les approbateurs, les créateurs de mises en production et les propriétaires d’environnement qui veulent éventuellement être notifiés (Figure 97).

Release notifications

(Figure 97) Notifications pour les mises en production

Pour plus d’informations, consultez le billet relatif à la gestion des notifications de mise en production.

Tests

Suppression de la prise en charge du Centre lab et des flux de tests automatisés dans Microsoft Test Manager

Avec l’évolution de la gestion des builds et des mises en production, les builds XAML ne sont plus prises en charge dans TFS 2018 et par conséquent, nous mettons à jour la prise en charge de l’utilisation de Microsoft Test Manager (MTM) avec TFS. L’utilisation du Centre de test/Centre lab dans MTM pour les tests automatisés n’est plus prise en charge par TFS, à compter de TFS 2018. Si vous n’êtes pas prêt à migrer et à ne plus utiliser les builds XAML et le Centre lab, vous ne devez pas effectuer la mise à niveau vers TFS 2018.

Observez l’impact de la mise à niveau vers TFS 2018 ci-dessous :

Centre lab :
  • Plus pris en charge :
    • Les contrôleurs de test ne peuvent pas être inscrits auprès de TFS pour créer et gérer des environnements lab.
    • Les contrôleurs de test existants inscrits auprès de TFS passeront hors connexion et les environnements lab existants apparaîtront avec l’état « Pas prêt ».
  • Alternative recommandée :
Tests automatisés :
Tests manuels :
  • Tous les scénarios de tests manuels continuent d’être entièrement pris en charge. Alors que les tests manuels peuvent être exécutés en utilisant MTM avec TFS 2018, les environnements lab ne peuvent pas être utilisés pour exécuter des tests manuels.
  • Pour tous les scénarios de tests manuels, nous recommandons fortement d’utiliser le hub de test dans l’accès web TFS.

Améliorations de la traçabilité des tests exploratoires pour les liens, les itérations et les chemins de zone des éléments de travail

Sur la base des commentaires que nous avons reçu des équipes effectuant des tests exploratoires, nous améliorons les liens de traçabilité lors de l’archivage des bogues, des tâches ou des cas de test à partir de l’extension Test et commentaires. Les bogues et les tâches créés lors de l’exploration des spécifications le sont désormais avec le même chemin de zone et la même itération que celle de la spécification, au lieu des valeurs par défaut de l’équipe. Les cas de test créés lors de l’exploration des spécifications sont désormais liés avec un lien Tests <-> Testé par à la place du lien Parent <-> Enfant, pour que les cas de test que vous créez soient automatiquement ajoutés aux suites de tests basées sur une spécification. Enfin, les éléments de travail créés sans exploration spécifique des spécifications sont créés dans l’itération par défaut de l’équipe, au lieu de l’itération active : ainsi, aucun nouvel élément de travail ne vient dans l’itération active une fois que la planification du sprint est terminée.

Filtres pour les éléments de travail de cas de test dans les plans et les suites de test du hub Test

En plus des filtres sur les champs Test, comme Résultat, Configuration et Testeur, vous pouvez désormais filtrer sur les champs des éléments de travail du cas de test, comme Titre, État et Affecté à (Figure 98).

Test case filters

(Figure 98) Filtres de cas de test

Graphiques de tendance des tests pour les environnements de mise en production et les séries de tests

Nous avons ajouté la prise en charge des environnements de mise en production dans le widget Tendance des résultats de test (Figure 99), ce qui vous permet de suivre l’état des environnements de test sur les tableaux de bord VSTS. Comme vous le faites pour les résultats de test dans les environnements de génération, vous pouvez désormais créer des graphiques de tendances indiquant le taux de réussite des tests, le nombre total de tests, le nombre de tests ayant réussi ou échoué, et la durée des tests pour les environnements de mise en production. Vous pouvez également filtrer les graphiques sur une série de tests spécifique dans un environnement avec le filtre de titre Série de tests.

Test trend chart

(Figure 99) Graphique de tendances des tests

Prise en charge de la mise en forme Markdown pour les commentaires des séries de tests et des résultats de test

Nous avons ajouté la prise en charge de la mise en forme des commentaires des Séries de tests et des Résultats des tests avec la syntaxe Markdown. Vous pouvez utiliser cette fonctionnalité pour créer du texte mis en forme ou des liens rapides vers des URL dans vos commentaires. Vous pouvez mettre à jour les commentaires de Résultats de test dans la page Résumé des résultats avec les commentaires Mettre à jour l’analyse et Série de tests dans la page Résumé de l’exécution avec Mettre à jour les commentaires dans le hub Test.

Lors de l’analyse du résultat du test dans la page de résumé de Build ou de Version, ou dans le hub Test, vous pouvez désormais associer un bogue existant à un test qui a échoué. C’est pratique quand un test échoue pour une raison connue qui a un bogue déjà créé.

Chargement des pièces jointes aux séries de tests et aux résultats de test

Vous pouvez désormais joindre des fichiers, par exemple des captures d’écran et des fichiers journaux, aux séries de tests ou aux résultats de test pour fournir des informations complémentaires. Jusque là, cette fonctionnalité n’était disponible qu’à travers le client Microsoft Test Manager (MTM), ce qui vous obligeait à basculer entre le hub de Test de VSTS/TFS et le client MTM.

Traitement par lot des tests

Dans la tâche de test Visual Studio, dans la gestion de build et de mise en production, certaines options vous permettent de contrôler la façon dont les tests doivent être regroupés (en lots) pour optimiser l’exécution. Les tests peuvent être regroupés de deux manières :

  1. En fonction du nombre de tests et d’agents participant à l’exécution : les tests sont simplement regroupés dans un certain nombre de lots d’une taille spécifiée.
  2. En fonction du temps d’exécution passé des tests, c’est-à-dire du temps d’exécution passé pour créer des lots de tests de sorte que chaque lot ait un temps d’exécution à peu près égal (Figure 100). Les tests qui s’exécutent rapidement sont donc regroupés ensemble, alors que les tests qui prennent plus de temps à s’exécuter peuvent appartenir à un lot distinct. Cette option peut être combinée avec le paramètre de phase multi-agent de façon à réduire autant que possible la durée totale des tests.

Test batching

(Figure 100) Traitement par lot des tests

Exécution de tests web à l’aide de la tâche VSTest

En utilisant la tâche de test Visual Studio, les tests web, aussi appelés tests de performances web, peuvent désormais être exécutés dans le pipeline CI/CD. Les tests web peuvent être exécutés en spécifiant les tests à exécuter dans l’entrée d’assembly de tâche. Tout élément de travail de cas de test qui a une « automatisation associée » liée à un test web peut aussi être exécuté en sélectionnant le plan de test/la suite de tests dans la tâche (Figure 101).

Test selection

(Figure 101) Sélection des tests

Le résultat des tests web est disponible sous forme de pièce jointe au résultat de test (Figure 102). Elle peut être téléchargée pour être analysée en mode hors connexion dans Visual Studio.

Test summary

(Figure 102) Résumé des tests

Cette fonctionnalité dépend des modifications de la plateforme de test Visual Studio et nécessite l’installation de Visual Studio 2017 Update 4 sur l’agent de build et de mise en production. Les tests web ne peuvent pas s’exécuter avec une version antérieure de Visual Studio.

De même, les tests web peuvent être exécutés à l’aide de la tâche Exécuter les tests fonctionnels. Cette fonctionnalité est dépendante des modifications apportées à l’agent de test, qui sera fourni avec Visual Studio 2017 Update 5.

Pour savoir comment l’utiliser avec les tests de charge, consultez le guide démarrage rapide Test de charge sur une application dans le cloud en utilisant Visual Studio et VSTS en guise d’exemple.

Widget de graphique pour les plans de test et les suites de tests

Avant, vous pouviez créer des graphiques pour les plans de test et les suites de tests dans le hub Test et les épingler au tableau de bord. Nous avons depuis ajouté un widget qui permet de créer des graphiques pour les plans de test et les suites de tests à partir du catalogue de widgets du tableau de bord. Vous pouvez créer des graphiques pour l’état de création de tests ou l’état d’exécution de tests. Par ailleurs, l’ajout de graphiques à partir du widget vous permet de créer des graphiques plus grands si vous voulez afficher plus de données sur un graphique (Figure 103).

Chart widget

(Figure 103) Widget de graphique

Prise en charge des captures d’écran et des annotations pour les applications de bureau avec le navigateur Chrome pour les tests manuels

Nous avons répondu à l’une des principales suggestions concernant les tests manuels : la prise en charge des captures d’écran d’applications de bureau à partir de Web Test Runner dans le hub Test. Jusqu’à présent, vous deviez utiliser Test Runner dans Microsoft Test Manager pour effectuer des captures d’écran d’applications de bureau. Vous devez installer l’extension Test & Feedback pour utiliser cette fonctionnalité. Nous déployons actuellement la prise en charge du navigateur Chrome. Celle de Firefox suivra peu de temps après.

Abandon de l’extension TFS pour SharePoint

TFS 2018 et ultérieur ne prendra plus en charge l’extension TFS pour SharePoint. En outre, les écrans utilisés pour configurer l’intégration entre un serveur TFS et un serveur SharePoint ont été supprimés de la Console Administration Team Foundation.

Remarque

Si vous mettez à niveau une version précédente configurée vers TFS 2018 pour l’intégrer à SharePoint, vous devez désactiver l’intégration SharePoint après la mise à niveau, sinon le chargement de vos sites TFS/SharePoint échoue.

Nous avons créé une solution qui vous permet de désactiver l’intégration sur le serveur SharePoint. Pour plus d’informations, consultez le billet sur l’avenir de notre intégration TFS/SharePoint.

Abandon des salles d’équipe

Les équipes de développement d’aujourd’hui dépendent fortement de la collaboration. Les personnes veulent (et ont besoin de) un endroit pour surveiller l’activité (notifications) et pour en parler (conversation). Il y a quelques années, nous avons constaté cette tendance et nous avons créé la Salle d’équipe pour prendre en charge ces scénarios. Depuis lors, nous constaté l’émergence sur le marché d’autres solutions pour collaborer. Plus particulièrement, nous avons vu la montée de Slack. Et plus récemment, il y a eu l’annonce de Microsoft Teams.

Avec un si grand nombre de bonnes solutions qui s’intègrent parfaitement à TFS et Visual Studio Team Services, nous avons annoncé en janvier les plans de suppression de notre fonctionnalité Salle d’équipe dans TFS 2018 et dans Visual Studio Team Services.


Haut de page