Notes de publication de Team Foundation Server 2018 RC1

Last Update: 25/09/2017

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

Téléchargez la dernière version de Team Foundation Server

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


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 : 30 août 2017

Récapitulatif : Mises à jour de Team Server Foundation dans TFS 2018 RC1

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

Résumé : Nouveautés de cette version release

Fonctionnalités supprimées dans cette version :


En détail : Nouveautés de cette version release

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. Il inclut désormais la plupart des fonctionnalités qui sont 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.

Formulaire d’élément de travail mobile

Nous avons une expérience de bout en bout complète qui inclut une apparence optimisée des éléments de travail (Figure 1) et qui fournit un moyen facile d’interagir 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.

Requête d’élément de travail mobile

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

Formulaire d’élément de travail mobile

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

Navigation mobile

(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 mobiles (requêtes, backlogs, tableaux kanban, sprints, backlogs 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é entre 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’obtenir rapidement ceux que vous recherchez.

Filtrage sur une requête

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

Champ masqué

(Figure 5) Champ masqué sur une 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).

Mettre à jour un champ masqué

(Figure 6) Mettre à jour un champ masqué sur une 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.

Gestion de versions

Duplications (forks)

TFS 2018 ajoute la prise en charge des duplications (forks) Git (Figure 7). 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 (Figure 7). 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.

Duplications (forks) Git

(Figure 7) Duplications (forks) Git

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

Désactiver l’édition web

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

Édition web non autorisée

(Figure 9) 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 voir vos branches périmées, accédez à l’onglet Périmé dans la page Branches (Figure 10).

Branches périmées

(Figure 10) 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 les branches supprimées (Figure 11).

Rechercher des branches supprimées

(Figure 11) Rechercher des branches supprimées

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

Restaurer des branches supprimées

(Figure 12) Restaurer des 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 préfixés par « dev », tapez simplement « dev » dans la zone de recherche et sélectionnez Rechercher dans les branches commençant par « dev » (Figure 13).

Rechercher une validation

(Figure 13) 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 (pull requests) dans la page des détails de validation affiche des informations plus pertinentes pour vous aider à poser un meilleur diagnostic (Figure 14). 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.

Légende des demandes de tirage (pull requests)

(Figure 14) Légende des demandes de tirage (pull requests)

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 avancé 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 sur l’arborescence des validations (Figure 15) et (Figure 16) :

Rechercher un fichier ou un dossier

(Figure 15) Rechercher un fichier ou un dossier

Vue filtrée

(Figure 16) Vue filtrée sur 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 sera désormais visible sous la forme d’un hub appelé Push (Figure 17) sous Code, au même titre que Validations, Branches, Étiquettes et Demandes de tirage. La nouvelle URL de la page Push est : <URL_serveur_tfs>/<nom_projet>/_git/<nom_dépôt>/pushes. Les anciennes URL continueront de fonctionner.

Page Envois (push)

(Figure 17) Page Envois (push)

Dans le même temps, le hub Historique a été renommé Validations (Figure 18), car il montre seulement 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 présentant 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 de la page des validations est : <URL_serveur_tfs>/<nom_projet>/_git/<nom_dépôt>/commits. Les anciennes URL continueront de fonctionner.

Page Validations

(Figure 18) 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 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. Ceci les obligeait à charger plus de fichiers et à filtrer le contenu pour rechercher le fichier, ce qui avait un impact sur 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 19). 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.

Afficher les étiquettes Git

(Figure 19) Afficher les étiquettes Git

Vous pouvez facilement distinguer entre une étiquette légère et une étiquette annotée, dans la mesure où les étiquettes annotées montrent le nom de la personne qui a affecté l’étiquette et la date de création, 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. La raison peut en être une faute de frappe dans le nom de l’étiquette, ou que 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 dans la page Étiquettes et en sélectionnant Supprimer l’étiquette (Figure 20).

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

Supprimer des étiquettes Git

(Figure 20) Supprimer des é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 parvenez pas à trouver l’étiquette que vous recherchez dans la page des étiquettes, vous pouvez simplement rechercher le nom de l’étiquette en utilisant le filtre en haut de la page Étiquettes (Figure 21).

Filtrer les étiquettes Git

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

Sécurité des étiquettes Git

(Figure 22) 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 correctement(Figure 23). 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. Ceci est fait automatiquement pour vous.

Terminer les éléments de travail liés

(Figure 23) Terminer 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 (pull requests) peuvent désormais choisir de réinitialiser les votes quand de nouvelles modifications sont envoyées (push)(Figure 24). Le nouveau paramètre est une option sous la stratégie consistant à Demander un nombre minimal de réviseurs.

Paramètre de réinitialisation des votes

(Figure 24) 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 en conséquence de cette option(Figure 25).

Réinitialiser les votes dans la chronologie

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

Rechercher un fichier ou un dossier dans une demande de tirage (pull request)

(Figure 26) Rechercher un fichier ou un dossier dans une demande de tirage (pull request)

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

Résultats de la recherche

(Figure 27) 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 (pull request) et ceux de la vue Fichiers ont désormais les mêmes options (Figure 28). Vous pouvez également filtrer pour afficher seulement les discussions auxquelles vous avez participé.

Filtrage des commentaires d’une demande de tirage (pull request)

(Figure 28) Filtrage des commentaires d’une demande de tirage (pull request)

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 (pull request) 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 29).

Afficher les différences avec l’original

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

Badge de mise à jour

(Figure 30) 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 révision d’un code nouveau (Figure 31).

Masquer les commentaires

(Figure 31) Masquer les commentaires

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

Commentaires réduits

(Figure 32) 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. Des info-bulles (Figure 33) facilitent la lecture d’un commentaire spécifique sans devoir afficher le thread tout entier.

Info-bulle d’un commentaire réduit

(Figure 33) Info-bulle d’un 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 34).

Barre d’outils de la liste des tâches

(Figure 34) Barre d’outils de la liste des tâches

Une fois que vous avez ajouté une liste de tâches (Figure 35), 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.

Liste de tâches

(Figure 35) Liste de tâches

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

Montrez votre soutien à un commentaire de demande de tirage en un seul clic sur le bouton J’aime (Figure 36). Vous pouvez consulter la liste de toutes les personnes qui ont aimé le commentaire en pointant sur le bouton.

Marque J’aime pour des commentaires de demande de tirage

(Figure 36) Marque J’aime pour 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 37) 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.

Boîte de dialogue Annuler l’achèvement automatique

(Figure 37) Boîte de dialogue Annuler l’achèvement 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 de notification 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 38).

Filtrage de chemin pour les notifications

(Figure 38) Filtrage de chemin pour les notifications

Modèles d’e-mail améliorés 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 39). 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, de façon à simplifier l’application de règles et de filtres en fonction de la personne qui a créé la demande de tirage.

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.

Modèle d’e-mail amélioré

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

Pour la plupart des alertes, l’appel à l’action (Figure 40) sera d’afficher la demande de tirage dans 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.

Envoyer un appel à l’action par e-mail

(Figure 40) Envoyer un appel à l’action par e-mail

Extensibilité de l’état des demandes de tirage (pull requests)

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

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

Section État des demandes de tirage

(Figure 41) Section État des demandes de tirage

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

Ajouter une nouvelle stratégie

(Figure 42) Ajouter une nouvelle stratégie

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

Définir la stratégie pour les états

(Figure 43) Définir la stratégie pour les états des demandes de tirage

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

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

Wiki

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

Page Wiki

(Figure 44) 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 45) Wiki du titre

    (Figure 45) Wiki du titre d’une demande de tirage

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

Balises HTML du Wiki

(Figure 46) Balises HTML du Wiki d’une demande de tirage

  • Redimensionnement pratique des images dans le dossier Markdown (Figure 47).

Redimensionnement d’une image

(Figure 47) Redimensionnement d’une image d’une demande de tirage

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

Menu Wiki

(Figure 48) Menu 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 cliquant sur les détails de la révision puis sur le bouton Rétablir (Figure 49).

Bouton Rétablir du Wiki

(Figure 49) Bouton Rétablir du Wiki d’une demande de tirage

Créer une page Wiki à partir d’un lien rompu Lors de la création d’un Wiki, nous avons observé des cas où des personnes créent une table des matières sur une page Wiki qui inclut des liens inexistants (Figure 50). Ces personnes cliquent ensuite sur ces liens pour créer des pages réelles. Dans notre expérience antérieure, nous gérions ce scénario en affichant un avertissement indiquant que le lien était rompu ou que la page n’existait pas. Désormais, au lieu de cela, nous gérons cela comme un scénario normal pour Wiki, en vous permettant de créer des pages.

Créer une page Wiki

(Figure 50) Créer une page Wiki d’une demande de tirage

L’extension Wiki sur la Place de marché est désormais dépréciée. Si vous êtes utilisateur d’une extension Wiki existante, vous pouvez migrer vos pages Wiki sur le nouveau Wiki à l’aide de cet outil de migration. Découvrez comment migrer vos pages Wiki existantes sur 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. Ceci facilite la création manuelle des URL de package (Figure 50). Le format est : <URL_serveur_tfs>/<project|team>/_packaging?feed=<flux>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package.

URL d’un package

(Figure 51) URL d’un package de demande de tirage

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

Masquer les packages supprimés

(Figure 52) 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 53) avec des dates lisibles, ce qui vous permet de trouver facilement les packages récemment mis à jour.

Colonne Dernier envoi (push)

(Figure 53) Colonne Dernier envoi (push)

Packages Maven

Nous avons lancé la prise en charge de l’hébergement des artefacts Maven dans TFS 2018 (Figure 54) ! 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.

Packages Maven

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

Tâche NuGet

(Figure 55) Tâche NuGet

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

Que la génération de votre projet npm soit faite sur Windows, Linux ou Mac, la nouvelle tâche de génération NPM fonctionnera sans problème. Nous avons également réorganisé la tâche pour rendre npm install et npm publish plus faciles. Pour install et publish, nous avons simplifié l’acquisition des informations d’identification pour que les informations d’identification pour les 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. D’autre part, si vous utilisez un flux VSTS/TFS, nous avons un sélecteur qui vous permet de sélectionner un flux puis 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 de travailler facilement avec les flux VSTS/TFS (Figure 56).

Tâche dotnet

(Figure 56) 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 en dehors de votre serveur TFS ou de votre compte VSTS, que ce soient des flux Gestionnaire de package dans un autre compte VSTS ou un autre serveur TFS, ou des flux autres que Gestionnaire de package, comme NuGet.org/npmjs.com, Artifactory ou MyGet (Figure 57). 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.

Flux à utiliser

(Figure 57) 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. 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 sera utilisé pour cette étape de génération (Figure 58).

Sélecteur de flux

(Figure 58) 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 explication de notre plan de dépréciation des builds XAML, consultez ce billet de blog.

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 sommes heureux d’annoncer que vous pouvez désormais le faire (Figure 59) et (Figure 60) !

Exporter une définition de build

(Figure 59) Exporter une définition de build

Importer une définition de build

(Figure 60) 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 61), nous envoyons (push) ces tâches à la fin et nous 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.

Badge de tâche dépréciée

(Figure 61) 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 62). 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/version existantes.

Description d’une tâche dépréciée

(Figure 62) Description d’une tâche dépréciée

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

Auparavant, si vous utilisiez une extension qui avait des tâches de génération et des sections de résumé de la build, la section de résumé de la build vous était montrée, même si vous n’utilisiez pas la tâche de génération 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 une utilisation dans les définitions de version ; 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 63).

Bibliothèque de fichiers sécurisés

(Figure 63) 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 d’approvisionnement Apple, les fichiers de magasin de clés Android et les clés SSH sur le serveur, sans devoir 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é :

Nouvelle éditeur de définition de version

Adhésion par défaut : le nouvel éditeur de définition de version a été configuré avec adhésion par défaut pour tout le monde. Vous-même ou vos administrateurs TFS aurez néanmoins toujours la possibilité de la désactiver en accédant à l’option Fonctionnalités en préversion sous le menu de votre profil. Pour plus d’informations, consultez Fonctionnalités en préversion.

Dans la même optique d’actualisation des expériences de génération et de publication, après le nouvel éditeur de définition de build, nous avons repensé notre éditeur de définition de version pour en permettre une expérience plus claire et plus intuitive, nous avons corrigé certains éléments laborieux et nous avons ajouté de nouvelles fonctionnalités. Une des fonctionnalités les plus puissantes du nouvel éditeur est sa capacité à vous aider à créer une représentation mentale ou à visualiser comment les déploiements sur vos environnements vont progresser . En outre, les paramètres des approbations, des environnements et des déploiements sont désormais contextuels et facile à configurer (Figure 65).

Visualisation du pipeline

Le pipeline (Figure 64) de l’éditeur fournit une vue graphique de la façon dont les déploiements progresseront pour une version. Les artefacts seront 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.

Pipeline

(Figure 64) Pipeline de version

Interface utilisateur de configuration en contexte

Les artefacts, les déclencheurs de version, les approbations de pré-déploiement et de post-déploiement, les propriétés des environnements et les paramètres de déploiement sont désormais contextuels et faciles à configurer (Figure 65).

Configuration d’une version

(Figure 65) Configuration d’une version

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

Une liste des modèles (prédéfinis et personnalisés) est affichée lors de la création d’un nouvel environnement, ce qui vous permet de démarrer facilement (Figure 66).

Modèles de déploiement

(Figure 66) Modèles de déploiement

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

Toutes les améliorations apportées au nouvel éditeur de définition de build sont désormais disponibles aussi dans l’éditeur de définition de version (Figure 67). 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.

Éditeur de tâche

(Figure 67) Éditeur de tâche

Onglets Groupes de variables, Conservation et Options

Vous pouvez maintenant lier/dissocier des groupes de variables (Figure 68), définir la stratégie de conservation pour des environnements individuels et modifier les paramètres de version au niveau de la définition, comme 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.

Groupes de variables

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

Menu Environnement

(Figure 69) Menu Environnement

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. Cependant, 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 le déploiement propagé sur ces serveurs. Vous pouvez utiliser le catalogue complet des tâches sur vos machines cibles.

Un groupe de déploiement (Figure 70) 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.

Groupes de déploiement

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

Configurer des groupes de déploiement

(Figure 71) Configurer des groupes de déploiement

Quand le déploiement est exécuté, les journaux indiquent la progression sur l’ensemble du groupe de machines que vous ciblez (Figure 72).

Progression du groupe de déploiement

(Figure 72) Progression du groupe de déploiement

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

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. Ceci est pratique si vous devez utiliser le même regroupement de tâches dans plusieurs builds ou versions. Pour vous aider à identifier les 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 73).

Références de groupe de tâches

(Figure 73) 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 également la publier directement en tant que version stable mise à jour (Figure 74).

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

Enregistrer en tant que brouillon

*(Figure 74) Enregistrer un groupe de tâches en tant que brouillon *

Enregistrer en tant que brouillon

*(Figure 75) Enregistrer un groupe de tâches en tant que brouillon *

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 76), comme nous l’avons fait pour les définitions de version, 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.

Exporter un groupe de tâches

(Figure 76) 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 77), vous pouvez maintenant exécuter le même ensemble de tâches dans une phase sur plusieurs configurations, qui s’exécutent en parallèle.

Configurations multiples de tâches sans agent

(Figure 77) Configurations multiples de tâches sans agent

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

La tâche Intervention manuelle (Figure 78) 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 79).

Tâche Intervention manuelle

(Figure 78) Tâche Intervention manuelle

Boîte de dialogue Intervention manuelle en attente

(Figure 79) Boîte de dialogue Intervention manuelle en attente

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 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 version) sont remplies. Dans la section Déclencheur de la boîte de dialogue Conditions de déploiement de l’environnement (Figure 80), 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.

Boîte de dialogue Conditions de déploiement

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

En outre, la page Résumé de la mise en production (Figure 81) contient maintenant 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.

Info-bulle du résumé de la mise en production

(Figure 81) Info-bulle du 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 82) pour les dépôts Git, lié à une définition de version 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.

Déclencheurs de version

(Figure 82) Déclencheurs de version

Déclencheurs de version : 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.

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

Tâche d’API REST

(Figure 83) Tâche d’API REST

Nous avons également ajouté une section Options de contrôle (Figure 84) à 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.

Options de contrôle des tâches

(Figure 84) 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 version (avec plusieurs environnements), chaque définition a une entrée dans le badge, avec l’état indiqué pour chaque environnement (Figure 85). Ceci améliore la traçabilité de la validation du code pour les déploiements.

Badge d’état des versions

(Figure 85) Badge d’état des versions

Par défaut, quand vous créez une définition de version, l’état du déploiement est publié pour tous les environnements. Cependant, 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 86).

Boîte de dialogue Options de déploiement

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

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

Lors de l’ajout d’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 87). Ceci facilite la différenciation des noms identiques de définition de build, mais dans des dossiers différents.

Ajouter un artefact

(Figure 87) 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 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 88), 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.

Rétablir une définition de version

(Figure 88) Rétablir une définition de version

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.

Si vous mettez à niveau vers TFS 2018, l’impact est le suivant :

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

Filtres de cas de test

(Figure 89) 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 90), 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 pour une série de tests spécifique dans un environnement avec le filtre Série de tests.

Graphique de tendance des tests

(Figure 90) Graphique de tendance 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éé.

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.

À l’avenir, nous ne prendrons pas en charge l’intégration de serveur à serveur, et l’intégration se fera à l’aide des API publiques et des frameworks d’extensibilité.

Si vous mettez à niveau un serveur où l’intégration TFS/SharePoint est configurée, nous avons fourni une solution qui vous permet de « mettre à niveau avec abandon » de l’intégration de serveur à serveur. Vos sites SharePoint TFS continueront de s’afficher après la mise à niveau, mais les fonctionnalités d’intégration seront désactivées. Pour plus d’informations et des instructions, consultez l’article accessible ici.

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.


Problèmes connus

Le service d’importation de base de données TFS ne prend pas en charge les versions RC

Le service d’importation de base de données TFS pour Visual Studio Team Services ne prend pas en charge les importations à partir des versions RC de TFS. Si vous prévoyez d’importer votre base de données de collection dans Team Services en utilisant ce service, il est important de ne pas mettre à niveau votre base de données de production vers cette version RC. Si vous mettez à niveau, vous devrez attendre et mettre à niveau vers la version RTW de cette édition, ou restaurer une copie de sauvegarde de votre base de données d’une version précédente de TFS pour l’importer.

La tâche de test Visual Studio v1 dans Build/Mise en production ne peut pas exécuter des tests avec Visual Studio 2017 Update 3

La tâche de test Visual Studio v1 dans Build/Mise en production ne peut pas exécuter des tests avec Visual Studio 2017 Update 3. La tâche échoue avec « Impossible de déterminer l’emplacement de vstest.console.exe ». La solution de contournement consiste à utiliser la version 2 de la tâche de test Visual Studio.