Visual Source Safe -> Migration TFS

Question

Ici, nous travaillons avec un certain nombre de référentiels Visual Source Safe depuis environ 10 ans.

Maintenant, je veux me débarrasser de sourcesafe et passer à Team Foundation Server.

Avez-vous des conseils ou astuces à me donner avant de me lancer dans cette migration ?Quelles sont les choses auxquelles je dois faire attention ?

Je suis sûr que cette migration signifiera que nos habitudes de travail devront être modifiées d'une manière ou d'une autre.Pensez-vous que ces changements pourraient être un problème pour l’organisation ?Pensez à un groupe d'environ 20 développeurs .NET sur un seul site.

Answer 1

Je viens de chercher sur Google, mais cette procédure pas à pas semble être une bonne référence et mentionne l'outil VSSConverter qui devrait vous aider à rendre la migration aussi simple que possible.

Je voudrais cependant recommander une chose :Sauvegarde.Sauvegardez tout avant de faire cela.Si quelque chose tourne mal, il vaut mieux prévenir que guérir.

Mes liens ne s'affichent pas.Voici l'adresse : http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx

Answer 2

Il existe différentes manières de migrer.L'outil extraira votre historique, etc.terminé, mais le moyen le plus pragmatique et le plus simple consiste à verrouiller VSS en tant qu'archive d'historique et à repartir à zéro :

1. Demandez à tout le monde de vérifier toutes les modifications dans VSS, assurez-vous que tout se construit, etc.
2. Définissez toutes les bases de données VSS sur "verrouillées" (droits en lecture seule pour tous les utilisateurs)
3. Obtenez les dernières informations sur l'ensemble de la base de données VSS dans un ensemble de dossiers « propres » sur un poste de travail
4. Vérifiez tous les fichiers dans TFS à partir du poste de travail

Pour tout historique antérieur à la conversion, les utilisateurs doivent se rendre sur VSS, mais après une semaine ou deux, il est peu probable que cela se produise aussi souvent.Et vous savez que l'historique dans VSS est précis et n'est pas corrompu par le processus de conversion.

Answer 3

Sachez que TFS ne prend pas en charge le partage de fichiers entre différents projets, comme le fait VSS.Si vous disposez de tels fichiers partagés, le lien entre eux sera rompu lors de la migration, ce qui entraînera des fichiers initialement identiques, mais désormais distincts dans chaque projet.Les mises à jour de l'un de ces fichiers dans TFS ne se propageront plus aux copies dans les autres projets.

Answer 4

Si vous choisissez d'utiliser l'outil VSSConverter.exe fourni avec Visual Studio Team Foundation Server, vous devez installer TFS2008 SP1 d'abord car il comprend un certain nombre d'améliorations détaillées sur ce blog par l'équipe des outils de migration.

Certaines des principales caractéristiques de la version incluent:

Élimination des conflits d'espace de noms.J'ai précédemment blogué à ce sujet en tant que "le problème de renommée" et nous avons corrigé le convertisseur pour migrer correctement les fichiers avec des espaces de noms qui se chevauchent.C'était le plus grand point de douleur pour la plupart des utilisateurs essayant d'utiliser les versions précédentes de l'outil.

Reliure automatique de la solution. Dans cette dernière version, les fichiers de solutions VS seront automatiquement mis à niveau vers la version 9.0 et redirigées dans le contrôle de la version.Auparavant, les utilisateurs devaient le faire manuellement.

Correction des incohérences d'horodatage.L'utilisation des horodatages du client par VSS peut entraîner des révisions enregistrées dans l'ordre opposé dans lequel ils se sont réellement produits.L'outil reconnaît désormais ce problème et continue de migrer les modifications où elle échouerait auparavant.

Journalisation améliorée.Bien que nous ayons résolu beaucoup de problèmes, offrant une journalisation meilleure et plus détaillée aidera les utilisateurs qui rencontrent des problèmes de diagnostiquer les problèmes.

Answer 5

Nous sommes actuellement en train de le faire dans mon travail quotidien.En fait, nous effectuerons la transition dans environ un mois.Je joue un rôle majeur dans la migration et explique en grande partie pourquoi nous abandonnons SourceSafe.Pour aider à la migration, j'ai utilisé le Image VPC de Visual Studio® Team System 2008 Team Foundation Server et Team Suite.C'était très utile.Dès le départ, l'image contient une installation TFS entièrement fonctionnelle avec laquelle vous pouvez jouer et faire une démonstration.Il comprend également des travaux pratiques et l'un des laboratoires exécute l'outil de migration VSS -> TFS.Si vous disposez d'un abonnement MSDN, une fois que vous avez joué avec l'image, l'étape suivante consistera à installer l'édition TFS Small Team fournie avec votre abonnement.

Une chose à noter est de vous assurer que les derniers Service Packs pour Visual Studio 2008 et .NET Framework sont installés sur l'image.Les service packs ont corrigé quelques bugs ennuyeux et ont définitivement augmenté la convivialité du système.Nous disposons d'une base de données SourceSafe assez volumineuse avec environ 90+ projets et l'outil de migration a pris environ 32 heures.J'ai d'abord fait une sauvegarde de notre base de données sourcesafe à des fins de test.Ensuite j'ai effectué la migration sur la base de données test sourcesafe.Ensuite, j'ai vérifié l'arborescence des sources dans TFS et tout s'est bien transféré.Nous avons conservé tout l'historique de nos fichiers sources à partir de VSS, ce qui était génial.Pas besoin de conserver cette puante base de données VSS après notre mise en ligne.

Nous procédons à la migration par étapes.Tout d'abord le contrôle des sources et laisser nos développeurs s'habituer à son utilisation.Ensuite, nous migrerons l'assurance qualité et les analystes commerciaux pour utiliser les fonctionnalités de suivi des éléments de travail.

Mon conseil est de procéder à la migration par étapes.N'en faites pas trop à la fois.Donnez du temps aux personnes qui utiliseront le système pour se former.

Answer 6

VSS Converter est une solution loin d'être parfaite.Et il existe des différences significatives entre les versions 2005 et 2008SP1 du convertisseur.

Par exemple, dans une base de données VSS utilisée depuis longtemps, un grand nombre d'utilisateurs auront contribué à VSS.Beaucoup de ces utilisateurs auront quitté l’organisation depuis longtemps et n’auront donc plus de compte de domaine.TFS nécessite de mapper les utilisateurs VSS sur des comptes de domaine. Vous devrez donc décider si vous mappez les anciens utilisateurs à un seul compte de domaine « factice » ou à un membre actuel de l'équipe.

De plus, VSS Converter 2008 exige que ces comptes de domaine soient des comptes TFS valides.Alors que le convertisseur 2005 n'applique pas cela.

Si votre historique VSS contient des déplacements de dossiers importants, il est probable que vous perdrez tout l'historique avant ce déplacement.Par exemple, si vous déplacez un dossier vers un nouvel emplacement, puis supprimez le parent précédent, vous perdrez tout l'historique.Voir cet article pour plus d'explications :http://msdn.microsoft.com/en-us/library/ms253166.aspx

Dans une migration à laquelle j'ai participé, nous avions une base de données VSS vieille de 10 ans qui avait perdu tout son historique il y a 6 mois.Cela est dû à un grand ménage effectué il y a 6 mois.

Answer 7

Outil de conversion TFS <-- Utilisez ceci

J'utilise déjà cet outil depuis quelques temps, les résultats sont assez satisfaisants car il est livré avec l'historique des modifications de SourceSafe si vous le souhaitez également.

Quoi qu'il en soit, en utilisant cet outil, vous devez toujours faire attention aux erreurs et aux avertissements dans le journal, et vérifier si tout s'est bien construit / s'est bien passé.

Il est recommandé d'exécuter également une analyse sur SS avant de l'exécuter.

J'espère que cela aide

Answer 8

Bons conseils de la part de mon ancien collègue Guy Starbuck.Une autre chose à ajouter avec cette approche : vous avez peut-être décidé au fil du temps de refactoriser la façon dont votre application est organisée (dossiers, etc.) et cela vous donnera l'opportunité de le faire.

J'ai été dans des situations où nous avons organisé une solution au hasard sans réfléchir (sans parler de changements majeurs dans l'application), ce qui a conduit à un désir d'organiser les choses différemment - et le passage de VSS à TFS est une excellente opportunité de le faire.

En ce qui concerne la question initiale :

Et:cette migration signifiera certainement que nos habitudes de travail devront être modifiées d'une manière ou d'une autre.Pensez-vous que ce changement pourrait être un problème pour l’organisation ?Pensez à un groupe d'environ 20 développeurs .net, sur un seul site

Je dirais : oui, vos habitudes de travail vont changer, mais bien plus pour le mieux.

1. Vous ne devez pas utiliser les verrous « Check-out » et « Get-Latest on Check-out ».
2. Vous pouvez désormais créer des branches et fusionner efficacement
3. Vous aurez maintenant des "Changesets", tous les fichiers archivés en même temps seront regroupés.Cela rend le suivi des modifications historiques beaucoup plus facile - mais plus important encore - les restaurations sont beaucoup plus faciles (c'est-à-dire trouver tous les fichiers archivés en même temps et les restaurer)
4. Association des enregistrements aux éléments de travail.Ne négligez pas les éléments de travail !La plus grosse erreur que vous puissiez commettre est de n’utiliser TFS qu’en remplacement de VSS.Les fonctionnalités de construction et de gestion de projet sont excellentes – vous les avez payées – UTILISEZ-LES !

En ce qui concerne les détails sur la façon dont votre expérience va changer, un autre de mes anciens collègues (et MVP de Team System) Steve St.Jean a écrit un article détaillé sur les différences : Du VSS au TFS