Étapes de modification du modèle de processus pour un projet existant dans TFS 2010

Question

J'ai un serveur TFS de l'installation à travers le temps est allé par le biais de mises à niveau à partir de TFS 2005 à TFS 2008 puis à TFS 2010. Au cours de la durée de vie de l'installation d'un grand nombre de projets ont été créés et les différents modèles de projet ont été utilisés. MSF Agile 4.0, 4.1, 4.2 et 5.0. et un peu de MSF CMMI ceux.

Ce que je voudrais faire est de "remplacer" le projet a servi de modèle pour l'ensemble de ces projets pour utiliser une nouvelle commune: Microsoft Visual Studio Scrum 1.0.

Je suis conscient que TFS modèles de projet sont utilisés comme modèles pour la création de nouveaux projets et ne peut pas modifier la tsf projets de définitions après la création.

Uptil maintenant, seul le contrôle de version et de build de la partie serveur de TSF ont été utilisés et il n'existe pas de types d'élément de travail.

En outre, tous les projets et mettre en place les scripts sont en fonction sur le code source des chemins de rester le même.

Comme je le vois, j'ai les options suivantes:

Créer de nouveaux TFS projets en utilisant le bon modèle de projet puis de déplacer/branche le code source pour le nouveau projet.

1. Tout le code est déplacé vers un temporaire de l'équipe de projet.
2. L'ancien est supprimé
3. Nouveau projet avec le nom d'origine et de corriger le modèle de processus est créé
4. Code est déplacé à la nouvelle équipe de projet

5. Temporaire de l'équipe de projet est supprimé

   • Toutes les définitions de build doit être recréé ce qui n'est pas une option.

   • Le code source déplacer/direction des "gâcher" la gestion des versions de l'histoire

Par gâcher la gestion des versions de l'histoire, je veux dire que lorsque vous vous déplacez code source, il sera derrière les coulisses de faire un delete + source renommer dans l'emplacement d'origine et de l'histoire sera toujours situé dans l'ancien projet. Cela va rendre la recherche dans l'histoire difficile et si j'ai effectivement supprimer l'ancien projet, je vais perdre toute l'histoire avant de le code source de bouger.

Ce n'est vraiment pas une option pour moi, car il y a des années de changement de code histoire qui est nécessaire pour soutenir les différentes applications en cours de construction.

Utiliser le TSF des outils de migration pour migrer vers un autre serveur TFS projet

• Cela a les mêmes inconvénients que la première solution

Remplacer/importer des types d'élément de travail, d'installer de nouveaux rapports, de créer de nouveaux sites SharePoint

Pour chaque projet tfs

• Pour supprimer l'élément de travail définitions à l'aide de "witadmin deletewitd"

• Importer chaque élément de travail la définition du nouveau modèle de processus à l'aide de "witadmin importwitd"

• L'importation de l'élément de travail des catégories à l'aide de "witadmin importcategories"

• Supprimer les anciens rapports dans le dossier du projet dans le serveur de rapports

• Télécharger le rapport de définitions à partir du nouveau modèle de processus

• Modifier les sources de données utilisées pour les rapports à l'aide du gestionnaire de rapports pour pointer vers le bon de sources de données partagées (TfsReportDS et TfsOlapReportsDS)

• Modifier le paramètre de rapport ExplicitProject valeur par défaut à "" (chaîne vide) et demander à l'utilisateur de désactiver l'option.

• Exporter les documents dans l'ancien site SharePoint à l'aide de la commande stsadm

• Supprimer l'ancien site SharePoint

• Recréer le site sharepoint à l'aide de la TFS2010 Agile tableau de bord modèle de site

• Activer la fonctionnalité du site "Team Foundation Server Mêlée tableau de bord"

• Dans TFS Paramètres du Projet -> Projet de Portail Paramètres: Permettre "de l'équipe de projet du portail" et assurez-vous que l'url est correcte. Activer "les rapports et les tableaux de bord se référer à des données pour ce projet d'équipe"

Et enfin..

• Processus de l'Entrepôt

• Le processus de l'Analyse de la Base de données

Même si cela implique beaucoup de petites étapes, cela ressemble plus attrayante que cette option ne va pas me forcer à déplacer le code source et que mon définitions de build sera intact.

Ma question:

Il existe d'autres moyens de réaliser le remplacement de types d'élément de travail que je n'ai pas mentionné?

Et/ou alors j'ai loupé toutes les étapes de dernière solution?

Answer 1

Étant donné que vous n'utilisez aucun type d'élément de travail existant, votre proposition finale semble être la meilleure option.

Après avoir supprimé les anciens rapports et exporté les documents SharePoint (vous pouvez également utiliser l'Explorateur Windows au lieu de stsadm), il existe en fait deux commandes dans « tfpt » qui vous aideront. Cela le ramènera de 14 étapes à 5 ou 6 étapes.

 tfpt addprojectreports  Add or overwrite reports for an existing team project
tfpt addprojectportal   Add or move portal for an existing team project

tfpt addprojectreports /collection:http://yourtfs:8080/tfs/YourCollection /teamproject:"Your Team Project" /processtemplate:"Microsoft Visual Studio Scrum 1.0" /verbose
tfpt addprojectreports /collection:http://yourtfs:8080/tfs/YourCollection /teamproject:"Your Team Project" /processtemplate:"Microsoft Visual Studio Scrum 1.0" /verbose 
 

Answer 2

Votre première option est à mon humble avis votre meilleur coup. Vous pouvez brancher les sources de l'ancien projet d'équipe vers le nouveau projet d'équipe. Avec TFS 2010, vous pouvez également voir l'historique à partir de l'emplacement ramifié. Vous ne perdez donc pas de fonctionnalité ici.

Le Build est juste un fichier msbuild qui est stocké dans le contrôle de code source. La seule chose que vous avez à faire est de copier les définitions de build. Vous pouvez le faire manuellement ou créer une petite application qui le fait pour vous.