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.

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.

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.

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

Types d'éléments de travail CMMI

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 :

• Modèle de processus Agile pour Visual Studio ALM (v6.0)

• Modèle de processus CMMI pour Visual Studio ALM (v6.0)

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.

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
Afficher les séries de tests	permet d'afficher les plans de test de ce nœud.	Au niveau du projet
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
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
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
Supprimer des séries de tests	permet de supprimer un test planifié pour le projet d'équipe.	Au niveau du projet
Afficher ce nœud	permet d'afficher les paramètres de sécurité d'un nœud de zone.	Nœud de zone
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
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

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 :

• Concepts clés Team Foundation Server 2010 (publication de blog)

• Mise à jour d'un projet d'équipe mis à niveau pour accéder à de nouvelles fonctionnalités (article VS ALM 2010)

• Localisation des rapports après la mise à niveau vers Team Foundation Server 2010 (article VS ALM 2010)

• Modifications et ajouts apportés au schéma pour le cube Analysis Services (article VS ALM 2010)

• Modifications effectuées dans les projets d'équipe et les modèles de processus par défaut lors de la mise à niveau de Team Foundation Server (Article VS ALM 2012)

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