Partager via


Mettre à jour un projet d'équipe basé sur un modèle de processus MSF v4.2

Si vous avez effectué une mise à niveau de Visual Studio Team System 2008 Team Foundation Server vers Team Foundation Server 2013, vous pouvez mettre votre projet d'équipe à jour manuellement. Si votre projet d'équipe est basé sur un modèle de processus dans la version 4.2 de Microsoft Solutions Framework (MSF), suivez les procédures décrites dans cette rubrique. Après avoir appliqué ces mises à jour, vous pourrez accéder aux nouvelles fonctionnalités décrites dans Mettre à jour un projet d'équipe mis à niveau pour accéder à de nouvelles fonctionnalités ainsi qu'interagir avec Microsoft Test Manager.

Important

Vous devez uniquement suivre les procédures de cette rubrique si vous mettez à niveau un projet d'équipe que vous avez créé avec un modèle de processus fourni avec Visual Studio Team System 2008 Team Foundation Server, ou un modèle qui ne contient pas les types d'éléments de travail Cas de test et Étapes partagées.

Ces procédures prendront en charge uniquement l'accès aux nouvelles fonctionnalités disponibles avec Team Foundation Server 2012.Du travail supplémentaire est requis pour ajouter de nouvelles requêtes ou les derniers rapports, pour mettre à jour des rapports personnalisés, ou pour accéder aux tableaux de bord.Pour plus d'informations, consultez Informations supplémentaires sur les modifications apportées en mettant à niveau TFS.

Mettre à jour les tâches requises pour accéder à de nouvelles fonctionnalités :

  1. Renommez les champs système

  2. (Agile uniquement) renommez le Scénario en Récit Utilisateur

  3. Télécharger la version la plus récente du modèle de processus MSF

  4. Importez les types de liens

  5. (Facultatif) Appliquez les personnalisations nécessaires

  6. Importer les types d'éléments de travail

  7. Importer le fichier des catégories

  8. Importer les fichiers de configuration du processus

  9. Vérifier l'accès aux nouvelles fonctionnalités

Tâches supplémentaires requises pour interagir avec le Gestionnaire de tests Microsoft:

  1. Spécifier le type de bogue à créer dans Microsoft Test Manager

  2. Accorder les autorisations aux membres de l'équipe des tests

  3. Lancer Microsoft Test Manager

Configuration requise

  • Pour télécharger un modèle de processus, vous devez être membre du groupe Project Collection Administrators. Si les autorisations de sécurité requises sont définies explicitement, votre autorisation Gérer le modèle de processus sur la collection de projets d'équipe doit avoir la valeur Autoriser.

  • Pour exécuter les outils en ligne de commande witadmin et tcm, vous devez être membre du groupe Team Foundation Administrators, Project Collection Administrators ou Project Administrators pour le projet.

  • Pour accorder des autorisations, vous devez être membre du groupe administratif au niveau du groupe que vous souhaitez modifier. Par exemple, si vous souhaitez modifier des autorisations pour un groupe ou un utilisateur au niveau de la collection de projets d'équipe, vous devez être membre du groupe Project Collection Administrators pour cette collection, ou votre autorisation Modifier les informations au niveau de la collection doit avoir la valeur Autoriser.

    Pour plus d'informations, consultez Référence des autorisations pour Team Foundation Server.

1.Renommez les champs système

Les noms conviviaux de plusieurs champs système ayant été renommés dans Visual Studio Team Foundation Server 2010, vous devez renommer manuellement ces champs dans votre collection de projets d'équipe. Les champs système renommés suivants figurent parmi ceux qui ont été renommés : System.AreaID, System.IterationID, System.HyperLinkCount, System.ExternalLinkCount et System.AttachedFileCount.

Effectuez cette tâche pour chaque collection de projets d'équipe définie pour votre version de Team Foundation Server mise à jour.

  1. Ouvrez une fenêtre d'invite de commandes à l'emplacement où Visual Studio 2012 ou Team Explorer 2012 est installé, puis entrez :

    cd %programfiles%\Microsoft Visual Studio 12.0\Common7\IDE
    

    Sur une édition 64 bits de Windows, remplacez %programfiles% par %programfiles(x86)%.

  2. Tapez la commande suivante, en substituant les arguments indiqués par vos données et appuyez sur Entrée.

    witadmin changefield /collection:CollectionURL /n:System.AreaId /name:"Area Id"
    witadmin changefield /collection:CollectionURL /n:System.AttachedFileCount /name:"Attached File Count"
    witadmin changefield /collection:CollectionURL /n:System.ExternalLinkCount /name:"External Link Count"
    witadmin changefield /collection:CollectionURL /n:System.HyperLinkCount /name:"Hyperlink Count"
    witadmin changefield /collection:CollectionURL /n:System.RelatedLinkCount /name:"Related Link Count"
    

    Utilisez ce format pour CollectionURL : http://ServerName:Port/VirtualDirectoryName/CollectionName, par exemple : http://srvalm:8080/tfs/DefaultCollection.

    Retour au début

2. (Agile uniquement) Renommer le type d'élément de travail Scénario

Pour réduire le nombre de personnalisations que vous devez effectuer, et pour respecter les mises à jour ultérieures du modèle de processus Agile, vous devez renommer le type d'élément de travail Scénario en Récit utilisateur.

Notes

Naturellement, renommer le type d'élément de travail Scénario nécessitera de vous que vous mettiez à jour les rapports existants et les requêtes qui référencent le type d'élément de travail Scénario.Toutefois, en raison de modifications de schéma apportées à l'entrepôt de données avec la mise à niveau vers Team Foundation Server 2010, les rapports pré-existants ou de pré-mise à niveau doivent être récrits pour utiliser le nouveau schéma.Voir Localisation des rapports après la mise à niveau vers Team Foundation Server 2010.

Effectuez cette tâche pour chaque projet d'équipe à mettre à jour.

  • Tapez la commande suivante, en substituant les arguments indiqués par vos données et appuyez sur Entrée.

    witadmin renamewitd /collection:CollectionURL /p:projectName /n:Scenario /new:"User Story"
    

    Conseil

    Placez un paramètre entre guillemets lorsqu'il contient des espaces.Par exemple, spécifiez /p:"My Project X" lorsque votre nom de projet contient des espaces.

Retour au début

3.Télécharger la version la plus récente du modèle de processus MSF

Consultez Télécharger la dernière version des modèles de processus.

Conseil

Pour accéder aux versions les plus récentes des modèles de processus par défaut, installez la dernière mise à jour trimestrielle pour Team Foundation Server.Les mises à jour significatives ont été apportées au flux de travail pour plusieurs types d'éléments de travail dans la dernière mise à jour trimestrielle.Ces modifications prennent en charge les transitions en amont de telle sorte que, lorsque vous faites glisser par inadvertance un élément de travail du tableau kanban ou du tableau de tâches vers un état résolu ou fermé, vous pouvez le refaire glisser vers un état de flux de travail antérieur.

Vous pouvez obtenir la mise à niveau depuis le site de téléchargement Microsoft : Mise à jour trimestrielle pour Microsoft Visual Studio Team Foundation Server 2012.

Retour au début

4.Importez les types de liens

Importez les types de liens, SharedSteps et TestedBy, situé dans le dossier LinkTypes dans le modèle de processus que vous avez téléchargé dans la tâche 3.

Effectuez cette tâche pour chaque collection de projets d'équipe définie pour votre version de Team Foundation Server mise à jour.

  • Tapez les deux commandes suivantes, en substituant les arguments indiqués par vos données et appuyez sur Entrée.

    witadmin importlinktype /collection:CollectionURL /f:"DirectoryPath\TestedBy.xml"
    witadmin importlinktype /collection:CollectionURL /f:"DirectoryPath\SharedStep.xml"
    

    Pour DirectoryPath, spécifiez l'emplacement du dossier LinkTypes pour le modèle de processus que vous avez téléchargé. Le chemin d'accès du répertoire doit suivre cette structure : Drive:\MSFTemplateFolder\WorkItem Tracking\LinkTypes.

    Retour au début

5. (Facultatif) Appliquez ces personnalisations aux versions les plus récentes des types d'éléments de travail

Si vous avez personnalisé chacun des types d'éléments de travail suivants, vous devez mettre la version de ces types la plus récente à jour avec vos personnalisations. Les tableaux suivants répertorient les champs supprimés et ajoutés dans les versions les plus récentes de chaque modèle de processus.

Types d'éléments de travail Agile

un type d'élément de travail,

Champs supprimés

Champs ajoutés

Bogue

  • Problème (Microsoft.VSTS.Common.Issue)

  • Rang (Microsoft.VSTS.Common.Rank), remplacé par Rang dans la pile

  • Nom du test (Microsoft.VSTS.Test.TestName)

  • ID de test (Microsoft.VSTS.Test.TestId)

  • Chemin d'accès de test (Microsoft.VSTS.Test.TestPath)

  • Triage (Microsoft.VSTS.Common.Triage)

Tâche

  • Travail planifié (Microsoft.VSTS.Scheduling.BaselineWork), remplacé par l'estimation d'origine

  • Discipline (Microsoft.VSTS.Common.Discipline), remplacée par l'activité

  • Critères de sortie (Microsoft.VSTS.Common.ExitCriteria)

  • Problème (Microsoft.VSTS.Common.Issue)

  • Rang (Microsoft.VSTS.Common.Rank), remplacé par Rang dans la pile

  • Hiérarchie des tâches (Microsoft.VSTS.Scheduling.TaskHierarchy)

Récit utilisateur (précédemment nommé Scénario)

  • Critères de sortie (Microsoft.VSTS.Common.ExitCriteria)

  • Problème (Microsoft.VSTS.Common.Issue)

  • Ordre de grandeur (Microsoft.VSTS.Common.RoughOrderOfMagnitude), remplacé par des points de récit

Types d'éléments de travail CMMI

un type d'élément de travail,

Champs supprimés

Champs ajoutés

Bogue

  • Travail planifié (Microsoft.VSTS.Scheduling.BaselineWork), remplacé par l'estimation d'origine

  • Estimation (Microsoft.VSTS.CMMI.Estimate)

  • Problème (Microsoft.VSTS.Common.Issue)

  • Rang (Microsoft.VSTS.Common.Rank), remplacé par Rang dans la pile

  • Étapes à reproduire (Microsoft.VSTS.CMMI.StepsToReproduce), remplacées par des Étapes de reproduction

  • Nom du test (Microsoft.VSTS.Test.TestName)

  • ID de test (Microsoft.VSTS.Test.TestId)

  • Chemin d'accès de test (Microsoft.VSTS.Test.TestPath)

Tâche

  • Travail planifié (Microsoft.VSTS.Scheduling.BaselineWork), remplacé par l'estimation d'origine

  • Estimation (Microsoft.VSTS.CMMI.Estimate)

  • Critères de sortie (Microsoft.VSTS.Common.ExitCriteria)

  • Problème (Microsoft.VSTS.Common.Issue)

  • Rang (Microsoft.VSTS.Common.Rank), remplacé par Rang dans la pile

  • Hiérarchie des tâches (Microsoft.VSTS.Scheduling.TaskHierarchy)

  • Nom du test (Microsoft.VSTS.Test.TestName)

  • ID de test (Microsoft.VSTS.Test.TestId)

  • Chemin d'accès de test (Microsoft.VSTS.Test.TestPath)

Spécification

  • Travail planifié (Microsoft.VSTS.Scheduling.BaselineWork), remplacé par l'estimation d'origine

  • Travail effectué (Microsoft.VSTS.Scheduling.CompletedWork)

  • L'évaluation (Microsoft.VSTS.CMMI.Estimate), remplacée par la planification de la taille

  • Critères de sortie (Microsoft.VSTS.Common.ExitCriteria)

  • Problème (Microsoft.VSTS.Common.Issue)

  • Rang (Microsoft.VSTS.Common.Rank), remplacé par Rang dans la pile

  • Travail restant (Microsoft.VSTS.Scheduling.RemainingWork)

Les types de personnalisations que vous pouvez appliquer incluent les ajouts de champ, les ajouts ou modifications des listes de sélection ou les ajouts aux raisons de flux de travail. Ne modifiez pas les états du flux de travail comme ils sont utilisés dans la configuration du processus et les outils de planification Agile. Si vous devez modifier le flux de travail, modifiez-le après avoir terminé la mise à jour et suivez l'aide concernant les mappages de méta-état fournis ici : Configurer et personnaliser les outils de planification Agile pour un projet d'équipe.

Si vous utilisez d'autres types d'éléments de travail définis dans le modèle de processus et souhaitez les mettre à jour avec les versions les plus récentes, appliquez les personnalisations que vous avez effectuées pour elles également. En outre, si vous avez défini un type d'élément de travail personnalisé que vous utilisez pour suivre des cas de test, vous devez appliquer des personnalisations à partir de ce type au type d'élément de travail Cas de test fourni avec le dernier modèle de processus.

Pour en savoir plus sur l'utilisation des artefacts fournis par ces modèles de processus, consultez les rubriques suivantes :

Retour au début

6.Importer les types d'éléments de travail

Importez les types d'éléments de travail suivants selon le modèle de processus que vous utilisez.

  • Agile: Le bogue, la tâche, le récit utilisateur, le cas de test, les étapes partagées, la demande de révision du code, la réponse de révision du code, la Demande de commentaire, la réponse de commentaire

  • CMMI: Bogue, Tâche, Spécification, Cas de test, Étapes partagées, Demande de révision du code, Réponse de révision du code, Demande de commentaire, Réponse aux commentaires

Effectuez cette tâche pour chaque projet d'équipe à mettre à jour.

  • Tapez la commande suivante pour chaque type d'élément de travail que vous devez importer, en substituant les données des arguments indiqués, puis appuyez sur la touche ENTRÉE.

    witadmin importwitd /collection:CollectionURL /p:projectName /f:"DirectoryPath\WITName"
    

    Conseil

    Spécifiez le nom du fichier XML et pas le nom convivial du type d'élément de travail.Par exemple, spécifiez CodeReviewRequest.xml pour le type d'élément de travail Demande de révision du code.

    Pour DirectoryPath, spécifiez l'emplacement de répertoire du dossier TypeDefinitions pour le modèle de processus que vous avez téléchargé. Le chemin d'accès du répertoire doit respecter la structure suivante : Drive:\MSFTemplateFolder\ WorkItem Tracking\TypeDefinitions.

  • (Facultatif) Vérifiez que les types d'éléments de travail sont accessibles en ouvrant Team Explorer ou Team Web Access. Vous devrez peut-être actualiser le cache pour voir les modifications.

Retour au début

7.Importer le fichier des catégories

Importez le fichier de catégorie qui se trouve dans le dossier Suivi des éléments de travail du modèle de processus que vous avez téléchargé. Les catégories prennent en charge le regroupement intelligent des types d'éléments de travail. Pour en savoir plus, consultez Utiliser les catégories pour regrouper les types d'éléments de travail.

  • Dans la fenêtre d'invite de commandes, tapez la commande suivante, en substituant les arguments indiqués par vos données, et appuyez sur Entrée.

    witadmin importcategories /collection:CollectionURL /p:projectName /f:"DirectoryPath\categories.xml"
    

    Pour DirectoryPath, spécifiez le chemin d'accès du dossier WorkItem Tracking pour le modèle de processus que vous avez téléchargé. Le chemin d'accès du répertoire doit respecter la structure suivante : Drive:\MSFTemplateFolder\WorkItem Tracking.

Retour au début

8.Importer le fichier de configuration du processus

Le fichier de configuration de processus détermine la disposition et les fonctionnalités disponibles via les pages du journal des travaux en souffrance (backlog) et du tableau de Team Web Access. Pour utiliser ces pages, vous devez importer le fichier de configuration de processus.

  • Importez le fichier de définition de la configuration du processus.

    witadmin importprocessconfig /collection:CollectionURL /p:" ProjectName" /f:"DirectoryPath\ProcessConfiguration.xml"
    

    Pour DirectoryPath, spécifiez le chemin d'accès du dossier Process pour le modèle de processus que vous avez téléchargé. Le chemin d'accès du répertoire doit respecter la structure suivante : Drive:\TemplateFolder\WorkItem Tracking\Process.

Retour au début

9.Vérifier l'accès aux nouvelles fonctionnalités

Effectuez les tâches décrites dans Vérifier la disponibilité de nouvelles fonctionnalités.

Notes

Il n'est pas nécessaire d'exécuter les étapes supplémentaires pour mettre à jour le flux de travail pour les projets d'équipe Agile, comme décrit ici : Mettre à jour le flux de travail pour les projets d'équipe Agile.En suivant les procédures de cette rubrique, vous aurez déjà appliqué ces modifications.

Retour au début

Tâches supplémentaires requises pour interagir avec le Gestionnaire de tests Microsoft

Effectuez les tâches suivantes pour effectuer les mises à jour requises pour interagir avec le gestionnaire de tests.

1.Spécifier le type de bogue à créer dans Microsoft Test Manager

Pour permettre la création automatique d'un élément de travail afin d'assurer le suivi d'erreurs de code ou de bogues détectés lors de l'utilisation de Gestionnaire de tests par un membre de l'équipe des tests, vous devez spécifier le type de bogue à utiliser pour votre projet d'équipe existant. La commande tcm bugfieldmapping prend en charge l'importation et l'exportation d'un fichier de mappage vers le projet d'équipe. Le fichier de mappage définit le type d'élément de travail à créer et les trois champs de données qui doivent être remplis par Gestionnaire de tests. Les trois champs concernent des étapes à reproduire, des informations système et le nom de la build dans laquelle l'erreur a été trouvée. Lorsqu'un testeur exécute un test et trouve une erreur, il peut créer un bogue dans lequel les trois champs sont remplis automatiquement.

  1. Ouvrez le Bloc-notes ou un éditeur de texte, puis copiez le code suivant dans le fichier :

    <?xml version="1.0" encoding="utf-16"?
    <BugFilerMappings workitemtypetocreate="Bug">
       <ReproSteps>Microsoft.VSTS.TCM.ReproSteps</ReproSteps>
       <SystemInformation>Microsoft.VSTS.TCM.SystemInfo</SystemInformation>
       <BuildFoundIn>Microsoft.VSTS.Build.FoundIn</BuildFoundIn>
    </BugFilerMappings>
    

    Notes

    Si le type d'élément de travail que vous utilisez pour créer des erreurs de code porte un autre nom que « Bug », remplacez « Bug » dans l'exemple précédent par le nom de ce type d'élément de travail.

  2. Enregistrez le fichier sous le nom bugfieldmappings.xml.

  3. Dans la fenêtre d'invite de commandes, tapez la commande suivante, en substituant les arguments indiqués par vos données, et appuyez sur Entrée.

    tcm bugfieldmapping /import /mappingfile:"DirectoryPath\bugfieldmappings.xml" /collection:CollectionURL /teamproject:projectName
    

    Pour DirectoryPath, spécifiez le dossier dans lequel vous avez enregistré le fichier bugfieldmappings.xml.

    Pour plus d'informations, consultez Personnaliser et gérer l'expérience de test [tcm et Microsoft Test Manager].

Retour au début

2.Accorder les autorisations aux membres de l'équipe des tests

Vous devez accorder des autorisations aux membres de l'équipe qui seront chargés de gérer des environnements et des configurations de test, de créer et visualiser des séries de tests et d'effectuer d'autres tâches.

Le tableau suivant décrit les autorisations qui contrôlent l'accès aux fonctions de test et prennent en charge l'interface avec le projet d'équipe à des fins de test. Il indique également les affectations par défaut effectuées dans la version 5.0 des modèles de processus MSF, en plus des autorisations qu'il est recommandé d'accorder aux testeurs manuels et aux responsables des tests.

Autorisation

Description

Portée

Readers

Contributors

Builders

Recommandée pour les testeurs manuels

Recommandée pour les responsables des tests

Afficher les informations au niveau du projet

permet de visualiser l'appartenance de groupes au niveau des projets et les autorisations de ces membres.

Au niveau du projet

coche coche coche coche coche

Afficher les séries de tests

permet d'afficher les plans de test de ce nœud.

Au niveau du projet

coche coche coche coche coche

Créer des séries de tests

permet d'ajouter et de supprimer des résultats de tests et d'ajouter ou de modifier des séries de tests pour le projet d'équipe.

Au niveau du projet

coche coche coche coche

Gérer des configurations de test

permet de créer et supprimer des configurations de test pour le projet d'équipe.

Au niveau du projet

coche coche

coche

Gérer les environnements de test

permet de créer et supprimer des environnements de test pour le projet d'équipe.

Au niveau du projet

coche coche

coche

Supprimer des séries de tests

permet de supprimer un test planifié pour le projet d'équipe.

Au niveau du projet

coche coche

coche

Afficher ce nœud

permet d'afficher les paramètres de sécurité d'un nœud de zone.

Nœud de zone

coche coche coche

coche

Gérer des plans de test

permet de créer et modifier les plans de test assignés à un nœud de zone. Si les plans de test n'ont pas été exécutés, vous pouvez également les supprimer.

Nœud de zone

coche coche coche coche

Gérer les contrôleurs de test

permet d'enregistrer et d'annuler l'enregistrement des contrôleurs de test pour la collection de projets d'équipe.

Collection de projets

coche

Vous pouvez accorder des autorisations en suivant les procédures indiquées pour la zone de portée spécifique :

  • Vous pouvez définir des autorisations au niveau du projet ou des autorisations au niveau du nœud de zone à partir de la page d'administration de Team Web Access. Consultez Gestion des autorisations et Ajouter et modifier des chemins de zone et d'itération.

  • Vous pouvez définir des autorisations pour une collection de projets à partir de Team Explorer, en sélectionnant Équipe, Paramètres de collections de projet d'équipe, Sécurité, en ouvrant et en utilisant la console d'administration de Team Foundation ou en utilisant les outils en ligne de commande TFSSecurity et tf. Pour plus d'informations, consultez Collection-Level Groups.

Pour plus d'informations, consultez Modifier les autorisations pour un groupe ou utilisateur.

Retour au début

3.Lancer Microsoft Test Manager

Une fois que vous avez terminé les tâches de mise à niveau décrites précédemment dans cette rubrique, vous pouvez démarrer Microsoft Test Manager, vous connecter à votre projet et commencer à planifier vos efforts de test. Pour plus d'informations, consultez Test de l'application.

Retour au début

Informations supplémentaires sur les modifications apportées en mettant TFS à niveau

Lorsque vous effectuez une mise à niveau de Visual Studio Team System 2008 Team Foundation Server vers TFS 2012, vous recevez les mises à jour apportées à TFS 2010 et à TFS 2012. Plusieurs modifications architecturales ont été apportées à la version de TFS 2010. Pour en savoir plus sur les modifications apportées en effectuant une mise à niveau de Visual Studio Team System 2008 Team Foundation Server vers la version la plus récente de TFS, consultez les ressources suivantes :

Voir aussi

Concepts

Mettre à jour un projet d'équipe mis à niveau pour accéder à de nouvelles fonctionnalités

Autres ressources

witAdmin : personnaliser et gérer des objets pour le suivi des éléments de travail