Notes de publication de Team Foundation Server 2018

---

| Developer Community Exigences du système ettermes | ducontrat de licencede compatibilité | TFS DevOps Blog | SHA-1 Hashes | Latest Visual Studio 2019 Releases Notes

---

---

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

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

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

---

Date de publication de de publication : 15 novembre 2017

Récapitulatif des nouveautés de TFS 2018

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

• Nous avons amélioré l’Assistant Création de projet et le Gestionnaire de modèles de processus sur le web.
• Vous pouvez désormais personnaliser l’en-tête de formulaire d’élément de travail.
• Nous avons optimisé le formulaire d’élément de travail mobile.
• Nous avons ajouté la prise en charge des duplications (forks) Git.
• Vous pouvez gérer les dépôts Git volumineux avec GVFS.
• Vous pouvez afficher, filtrer, supprimer et définir la sécurité des étiquettes Git.
• Nous avons ajouté un miniplan de fichier, l’appariement des accolades et l’activation/la désactivation des espaces blancs dans l’édition de code web.
• Nous avons apporté de nombreuses améliorations apportées aux demandes de tirage (pull requests).
• Vous avez une nouvelle expérience Wiki améliorée.
• Nous avons ajouté la prise en charge des packages Maven.
• Vous pouvez importer/exporter et suspendre des définitions de build.
• Le nouvel éditeur de définition de version a l’option d’adhésion par défaut.
• Vous pouvez déployer avec des déploiements de machines virtuelles.
• Nous avons amélioré la traçabilité des tests exploratoires.
• Nous avons ajouté le traitement par lot des tests.
• Vous pouvez désormais voir un widget de graphique pour les plans de test et les suites de tests.

Vidéo Nouveautés de TFS 2018

Build XAML

À la base, nous avions listé Build XAML comme supprimée de TFS 2018 RTW et d’Update 1. Toutefois, trop de clients se sont retrouvés dans l’impossibilité d’effectuer la mise à niveau ou obligés de contacter le support pour la réactiver une fois la mise à niveau terminée. Dans TFS 2018 Update 2, Build XAML est activée mais a été dépréciée. Cela signifie que nous n’investissons plus dans Build XAML et que Microsoft Test Manager (MTM) ne prend plus en charge l’utilisation de builds XAML. Nous vous recommandons vivement d’effectuer une conversion dans l’un des formats de définition de build plus récents. Vous pouvez continuer à connecter vos contrôleurs XAML et à exécuter des builds XAML avec TFS 2018 Update 2. Informations supplémentaires

Fonctionnalités supprimées dans TFS 2018 RTW

• La prise en charge du Centre lab et des flux de tests automatisés dans Microsoft Test Manager a été supprimée.
• Nous avons abandonné l’extension TFS pour SharePoint.
• Nous avons supprimé la fonctionnalité Salle de l’équipe.

---

Détails des nouveautés de TFS 2018

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. En utilisant l’interface web, vous n’avez pas besoin de la version correspondante de Visual Studio. La différence entre Visual Studio et la version web est que la version web ne provisionne 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.

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 offre une expérience utilisateur beaucoup plus simple, car vous n’êtes pas obligé d’installer la version appropriée 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é.

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 permet d’interagir facilement avec les éléments qui vous sont affectés, que vous suivez, ou que vous avez visités ou modifiés récemment, à partir de votre téléphone.

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

Avec la nouvelle navigation mobile (Figure 3), les utilisateurs peuvent accéder à toutes les autres parties mobiles de TFS et revenir au site de bureau complet au cas où ils doivent interagir avec d’autres hubs.

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.

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

Aujourd’hui, vous avez la possibilité d’ajouter des champs supplémentaires à un carte, puis de masquer les champs vides(Figure 5) dans les paramètres du tableau pour supprimer l’encombrement inutile du tableau. 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é.

Cliquez sur le chevron bas en bas du carte pour mettre à jour le champ (Figure 6).

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

De nouvelles idées de fonctionnalités peuvent arriver à tout moment. Nous avons donc facilité l’ajout de nouvelles fonctionnalités directement à 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.

Gestion de version

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.

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 le menu contextuel :

Pour TFVC, vous devez spécifier un nom de dossier, puis l’archiver. Dans le cas de Git, comme les dossiers vides ne sont pas autorisés, vous devez également 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.

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.

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

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

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. Cependant, é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 la modification web à partir de la page Fichiers, accédez à Paramètres, puis Contrôle 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.

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

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 rendu plus facile l’identification des branches « périmées » (branches qui pointent vers des validations datant de plus de 3 mois). Pour afficher vos branches périmées, accédez à l’onglet Périmées dans la page Branches(Figure 16) .

Rechercher une branche supprimée et la recréer

Quand vous supprimez accidentellement une branche du serveur, il peut être difficile de comprendre 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) .

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

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, si vous souhaitez voir si un commit a fait son chemin dans toutes les branches qui sont précédées de « dev », tapez simplement « dev » dans la zone de recherche et sélectionnez Rechercher dans les branches en commençant par « dev »(Figure 19).

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.

Filtrer l’arborescence dans le code

Désormais, vous n’avez plus besoin de faire défiler tous les fichiers qui ont pu être modifiés par une validation pour accéder simplement à 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) :

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. À présent, la page mises à jour de la branche est visible sous forme de hub appelé Pushes(Figure 23) sous Code, aux côtés des commits, des branches, des étiquettes et desdemandes de tirage. La nouvelle URL de la page d’envois (push) est : \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. Les anciennes URL continueront de fonctionner.

Dans le même temps, le hub d’historique est désormais renommé commits(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.

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 pour 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. Cela les obligeait à charger plus de fichiers et à filtrer le contenu pour trouver le fichier approprié, 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.

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 de l’interface utilisateur web en cliquant sur le menu contextuel d’une balise dans la page Balises et en sélectionnant Supprimer une balise(Figure 26).

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

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

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

Si vous liez des éléments de travail à vos demandes de tirage, il est devenu plus simple de tout conserver à jour. Désormais, quand vous exécutez une demande de tirage, vous pouvez choisir l’exécution automatique des éléments de travail liés, une fois la demande de tirage fusionnée avec succès (Figure 29) . Si vous utilisez des stratégies et si vous configurez les demandes de tirage pour qu’elles soient exécuté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. Ceci est effectué automatiquement pour vous.

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.

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

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

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

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

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 de demande de tirage une fois que le code qu’il référence a changé (bien souvent, quand un changement demandé a été effectué) (Figure 35) .

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

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

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

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 l’accès à un commentaire sans voir le thread entier.

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

Une fois que vous avez ajouté une liste des tâches (Figure 41) , vous pouvez simplement cocher les cases pour marquer les éléments exécuté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.

Possibilité d’indiquer « J’aime » pour des commentaires dans les demandes de tirage

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.

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.

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

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 d’objet commence désormais par le titre de la demande de tirage. Les informations secondaires, telles que le nom du dépôt et l’ID, 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.

Pour la plupart des alertes, l’appel à l’action (Figure 46) est d’afficher la demande de tirage sur le web. Cependant, 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.

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.

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.

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)

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

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

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

• Mises à jour hors connexion du Wiki pour les utilisateurs avec pouvoir.

Plus vous utilisez le Wiki, plus vous risquez d’enregistrer des changements non souhaités. 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) .

Créer une page Wiki à partir d’un lien rompu

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.

Lien profond de page Wiki

Le Wiki prend désormais en charge les sections de lien profond dans une 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.

Package Management

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.

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

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.

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 du code et des composants de manière fluide. Consultez notre guide de démarrage pour savoir comment partager des artefacts Maven en utilisant la gestion des packages.

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. Ce changement coïncide avec une vague d’améliorations décrites ci-dessous, auxquelles vous pouvez accéder uniquement 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) .

Option NuGet « Permettre d’ignorer les doublons »

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 build NuGet a une nouvelle option, Permettre d’ignorer les doublons, qui permet à la tâche de se poursuivre si elle tente d’envoyer (push) des packages à un flux VSTS/TFS où la version est déjà 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 build NPM fonctionne sans interruption. 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 listés dans le fichier .npmrc du projet puissent être stockées en toute sécurité dans un point de terminaison de service. Sinon, si vous utilisez un flux VSTS/TFS, nous proposons un sélecteur qui vous permet de sélectionner un flux, puis génère un fichier .npmrc avec les informations d’identification nécessaires à 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) .

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. Ce dernier est détaillé ci-après :

1. Tout d’abord, dotnet prend désormais en charge les sources de packages authentifiées, comme Package Management : vous n’avez donc plus besoin d’utiliser la tâche NuGet pour restaurer des 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, l’exécution de la tâche se solde par un échec 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.

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

Build et mise en production

Builds XAML

Dans TFS 2015, nous avons introduit un système de génération multiplateforme basé sur le web. Les builds XAML ne sont pas prises en charge dans TFS 2018 RTW ni dans Update 1, mais nous les avons réactivées dans TFS 2018 Update 2. Nous vous encourageons à migrer vos builds XAML. Si vous n’êtes pas encore prêt à effectuer la migration et si vous devez continuer à utiliser des builds XAML, effectuez une mise à niveau vers TFS 2018 Update 2.

Quand vous effectuez la mise à niveau vers TFS 2018 RTW ou Update 1 :

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

• Vous pouvez voir les builds XAML achevées, mais vous ne pouvez pas en placer de nouvelles en file d’attente.

• Il n’existe pas de nouvelle version d’agent ou de contrôleur de build XAML dans TFS 2018.

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

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

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

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

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’agit de l’une des dix premières demandes sur UserVoice.

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

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 voir l’exemple complet, consultez https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

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 des tâches dépréciées (Figure 65) , nous les envoyons (push) vers la fin et les regroupons dans une section réductible qui est 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.

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 oriente ensuite les personnes qui utilisent la tâche dans la bonne direction à partir du catalogue des tâches et des définitions de build/mise en production existantes.

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

Avant, si vous utilisiez une extension qui avait des tâches de build 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/version 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).

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 publication 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é :

• Utilitaire : Installer le certificat Apple

• Utilitaire : Installer le profil de provisionnement Apple

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.

Nouvel éditeur de définition de mise en production

Dans la même optique d’actualisation des expériences de Build et mise en production, nous avons repensé l’éditeur de définition de version 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 pour une version. Les artefacts sont consommés par la version 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.

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

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 simplifient le processus de démarrage pour les utilisateurs en spécifiant les paramètres les plus importants sans avoir à approfondir les tâches (Figure 70) .

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.

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

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 de version au niveau de la définition, comme le format du numéro de version, à 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.

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

Déploiement de machines virtuelles avec des 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.

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. Les étiquettes sont automatiquement héritées 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é.

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

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.

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 ajoutons la prise en charge des filtres pour les groupes de déploiement dans les prochaines versions.

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 version (Figure 80) . Ceci est pratique si vous devez utiliser le même regroupement de tâches dans plusieurs builds ou versions. 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 version et les groupes de tâches qui référencent votre groupe de tâches (Figure 79) .

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 principale est une préversion, vous voyez même un message vous invitant à l’« essayer ». 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) .

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. En ce qui concerne 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 le souhaitez. Nous avons également activé les groupes de tâches imbriqués, qui se développent quand ils sont exportés.

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.

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

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

Une définition de version 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 versions qui sont 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 version) 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.

De plus, 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 va démarrer.

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 version dans les projets d’équipe du même compte. Cela vous permet de déclencher automatiquement une mise en production quand vous effectuez une nouvelle validation 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.

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 version, puis déclencher des versions 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 version, 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 principale. 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 version (Figure 90) . Le déploiement dans cet environnement n’est déclenché que si toutes les conditions d’artefact sont réunies.

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 appelle une 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.

Nous avons également 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.

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.

Par défaut, quand vous créez une définition de version, 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) .

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 version, 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.

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

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

Aujourd’hui, si une définition 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 version, puis de modifier manuellement la définition de version. 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 version, à partir de l’onglet Historique de la définition de version.

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éploiement.

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

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 de Release Management, 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 :
  • Vous pouvez vous connecter à votre serveur SCVMM avec l’extension TFS SCVMM, créer et gérer des machines virtuelles, et exécuter votre workflow sur ce serveur. Pour plus d’informations, consultez How to perform Lab management operations in Build and Release.

Tests automatisés :

• Plus pris en charge :
  • Les workflows de tests automatisés qui s’appuient sur Test Controller et des environnements lab, comme un workflow Génération-Déploiement-Test XAML, ou l’exécution de tests automatisés à partir d’un plan de test en utilisant MTM, ne sont plus pris en charge.
• Alternatives recommandées :
  • Vous pouvez exécuter des tests automatisés dans Build et mise en production.
  • Vous pouvez exécuter des tests automatisés à partir d’un plan de test en utilisant le hub Test.

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 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 tâches créés durant l’exploration des exigences le sont désormais avec le même chemin de zone et la même itération que pour l’exigence, au lieu des valeurs par défaut de l’équipe. Les cas de test créés lors de l’exploration des exigences seront désormais liés à un lien Tests <-> Testé par au lieu du lien Parent <-> Enfant , afin que les cas de test que vous créez soient automatiquement ajoutés aux suites de tests basées sur les exigences. 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 de test comme Le résultat, la configuration et le testeur, vous pouvez désormais filtrer sur les champs d’élément de travail de cas de test, tels que Titre, État et Affecté à(Figure 98) .

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.

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.

Ajout d’un lien vers un bogue existant pour un test qui a échoué

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 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 regroupés, alors que les tests qui prennent plus de temps à s’exécuter peuvent faire partie d’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.

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

Les résultats des tests web sont disponibles sous forme de pièce jointe aux résultats des tests (Figure 102) . Elle peut être téléchargée pour être analysée en mode hors connexion dans Visual Studio.

Cette fonctionnalité dépend des changements apportés à la plateforme de test Visual Studio et nécessite l’installation de Visual Studio 2017 Update 4 sur l’agent de build/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.

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

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.

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.

---

Quel est votre avis ?

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

---

Haut de la page