Quels sont les avantages de Team Foundation Server par rapport à Visual SourceSafe?

Transcription

1 Migration de Visual SourceSafe vers Team Foundation Server Les avantages de la migration vers une plateforme moderne Par le créateur de Visual SourceSafe et de Team Foundation Server Brian Harry 1

2 Pourquoi changer de solution? Lors de sa mise sur le marché, Visual SourceSafe (VSS) représentait le dernier cri en matière de contrôle de versions et répondait aux besoins des développeurs. À l'époque, Internet n'en était qu'à ses balbutiements, les réseaux étaient rares et les applications ne partageaient pas de données. Les équipes de développement, souvent restreintes, étaient regroupées sur un seul site. En d'autres termes, tout était plus simple. Ces quinze dernières années, le développement logiciel, les solutions distribuées et Internet ont connu une croissance phénoménale et tout est devenu plus complexe. La plupart des équipes de développement logiciel ont désormais besoin de consulter le code à distance, de suivre et de vérifier plus facilement les modifications qui lui ont été apportées, et d'accéder à un référentiel de code source très fiable et très performant. VSS ne satisfait aucune de ces attentes. La solution est clairement parvenue au terme de son évolution. Microsoft ne prévoit aucune nouvelle version ni mise à jour de la version actuelle de VSS. VSS laisse la place à Team Foundation Server (TFS), une solution bien plus intéressante en l'état actuel de la technique. Alors n'hésitez pas : optez dès maintenant pour Team Foundation Server! Rédigé par Microsoft pour la migration de Visual SourceSafe vers Team Foundation Server 2010 Microsoft Corporation. Tous droits réservés. 2 1

3 Quels sont les avantages de Team Foundation Server par rapport à Visual SourceSafe? Performances, fiabilité et évolutivité Avec SQL Server 2008, Team Foundation Server bénéficie des performances et de l'évolutivité d'un serveur de base de données d'entreprise parmi les meilleurs du marché. Les petites équipes qui n'ont pas besoin d'une installation SQL Server complète peuvent ainsi installer et utiliser SQL Server Express sur un système client de type Windows 7 pour obtenir la même puissance dans un package plus compact. C'est l'un de ses avantages clés par rapport à VSS : Team Foundation Server s'adapte à l'évolution de votre infrastructure au fil du temps. La mise à niveau de SQL Server Express vers la version complète de SQL Server est aussi simple qu'une sauvegarde/restauration. En outre, SQL Server permet d'étendre la capacité de stockage de manière dynamique selon les besoins, améliore les performances de lecture/ écriture et propose une fonction de clustering s'intégrant à une solution à tolérance de panne. Figure 1 : Fonctionnalité Annotate (Annoter) de Team Foundation Server La figure 1 illustre une annotation de fichier : chaque ligne est accompagnée de sa date de création et du nom de son auteur. Cette vue permet également d'accéder aux détails sur la modification, représentés à la figure 2. Elle met aussi en évidence un autre avantage de Team Foundation Server : l'archivage atomique. Grâce à l'étroite intégration de Team Foundation Server et de Visual Studio, l'utilisateur bénéficie d'un environnement de développement familier et efficace, avec contrôle du code source. Sous Visual SourceSafe, les développeurs devaient ouvrir l'interface utilisateur de VSS en dehors de Visual Studio pour contrôler le code source. Avec Team Foundation Server, toutes les opérations sur le code source et les éléments de travail peuvent être effectuées directement dans Visual Studio (certaines fonctionnalités administratives impliquent néanmoins de passer par la ligne de commande complète). Un autre défaut des installations VSS réside dans la limite recommandée de 4 Go. Les équipes qui approchent de cette limite ou la dépassent sont souvent confrontées à des problèmes de corruption du code source qu'elles doivent alors corriger. Or, restaurer ces données à partir d'une sauvegarde n'est pas toujours une mince affaire : cela implique que l'administrateur système restaure tout le partage de fichiers. Ici aussi, Team Foundation Server tire avantage des fonctionnalités de SQL Server qui comporte une protection intégrée contre la corruption des données mais permet aussi de restaurer des données endommagées via une simple sauvegarde SQL Server. SQL Server propose un grand nombre de plans de protection des données depuis la sauvegarde incrémentielle jusqu'à la mise en miroir en passant par la sauvegarde complète et la copie de journaux. Tous comportent des mécanismes fiables pour protéger vos données. Sécurité Dans VSS, la sécurité se limite à trois paramètres : Admin, Lecture/écriture et Lecture. Appliquer des paramètres de sécurité au niveau des fichiers est possible mais malaisé. L'inconvénient majeur de ce système réside dans son manque de souplesse : si vous avez l'autorisation d'écrire sur un fichier, vous pouvez en faire ce que vous voulez. Tout étant conservé dans un partage de fichiers, tout utilisateur doté de droits d'accès au partage peut supprimer la totalité des données. Même si la sécurité granulaire de votre code source ne vous semble pas cruciale, Team Foundation Server vous la propose. Il permet non seulement de contrôler la sécurité au niveau des fichiers, mais encore de gérer des scénarii particuliers (par exemple, autoriser un développeur à extraire un fichier, mais pas à l'archiver) caractéristique appréciable dans de nombreuses circonstances, comme un audit collégial ou un développement externalisé. De plus, les données étant stockées dans SQL Server, vous ne perdrez plus jamais votre code source en cas de suppression. Fonctionnalités avancées Il arrive qu'un développeur veuille savoir qui a modifié une ligne de code, quand, et surtout, pourquoi. Grâce à la fonctionnalité Annotate (Annoter) de Team Foundation Server, c'est désormais possible. Figure 2 : Boîte de dialogue de détails sur l'ensemble de modifications Autre inconvénient de VSS, l'archivage atomique n'est pas pris en charge. Supposons que vous ayez fait une modification qui concerne trois fichiers différents (a.cs, b.cs, c.cs) et que vous les archiviez dans VSS mais que pour l'un d'eux l'archivage échoue. La version obtenue à la prochaine opération Get (Récupérer) sera probablement incomplète et obsolète à cause du problème d'archivage. Avec l'archivage atomique, cela n'arrive pas : soit tous les fichiers sont archivés, soit aucun d'eux ne l'est. Ainsi, l'état du code archivé est toujours cohérent. De plus, dans VSS, il est presque impossible d'identifier les fichiers archivés ensemble sans examiner chaque horodatage sur chaque fichier. Les ensembles de modifications atomiques occupent une place centrale dans Team Foundation Server. La boîte de dialogue de détails sur l'ensemble de modifications, représentée sur la figure 2, montre tous les fichiers archivés, avec la date et l'heure de l'opération. Il est ainsi possible de rétablir en une seule opération tous les fichiers archivés ensemble. Enfin, les modifications apportées aux fichiers durant l'archivage, les commentaires ajoutés et les éléments de travail associés sont clairement visibles. 2 3

4 Dans VSS, la création de branches est problématique à plusieurs titres. Premièrement, il n'existe aucun moyen de visualiser la structure de création de branche ou le déplacement de code entre les branches. Deuxièmement, comme VSS utilise la fonction de partage et non la création de branches, des conflits sont possibles selon l'emplacement de partage du code et la date des modifications. En effet, le partage ne fournissait pas de copie des fichiers, mais seulement une référence à ces derniers. Un projet entraînant la modification d'un fichier pouvait donc corrompre d'autres projets. Dans les versions plus évoluées de VSS, la création de branches a été ajoutée au partage : il était possible de créer une branche pour le code juste après une opération de partage. Ainsi, la référence était supprimée et le fichier était copié. La fusion pouvait alors être réalisée comme prévu. Team Foundation Server repose sur un modèle de création de branches pur. Il n'intègre pas de partage. Cette logique favorise de meilleures pratiques de développement logiciel et empêche la corruption du code d un projet par une modification d un autre projet. Team Foundation Server 2010 propose même une fonction de visualisation des branches qui permet de savoir où va le code et de voir la structure de base des branches. De plus, les vues de branche sont interactives : les utilisateurs peuvent y réaliser directement les fusions (figure 3). Suivi des bogues et des tâches avec les éléments de travail de Team Foundation Server Les éléments de travail constituent un autre grand avantage de Team Foundation Server. Ils ne sont pas indispensables mais permettent d'associer les modifications à des exigences de conception ou d'attribuer des tâches aux développeurs et de rendre compte de l'avancement aux chefs de projet. L'efficacité des développeurs en est renforcée, tandis que le suivi des bogues est assuré à l'aide d'un outil intégré. Les équipes intéressées deviendront rapidement expertes dans l'utilisation de cette fonctionnalité. Alertes Team Foundation Server propose un système d'alertes concernant les modifications de fichiers ou de dossiers importants ; pour s'y abonner, il suffit de faire un clic droit sur un fichier ou un dossier et de sélectionner Alert on Change (M'avertir des changements). Les développeurs n'ont donc plus besoin de consulter l'historique pour savoir si les fichiers cruciaux pour leur projet ont été modifiés : ils en sont directement informés. Jeux de réservations Comme leur nom l'indique, les «jeux de réservations» permettent de «réserver» un ensemble de modifications, c'est-à-dire de le placer dans un emplacement de stockage temporaire où il est sauvegardé avec le reste des fichiers soumis au contrôle de code source. Seule différence, les fichiers ne sont pas archivés dans le référentiel. Les développeurs peuvent ainsi enregistrer leur travail en cours sur le serveur à la fin de la journée ou partager du code à problème avec d'autres développeurs sans endommager le code des autres utilisateurs. Compilation automatique Beaucoup d'équipes utilisent des produits tiers pour extraire leur code source de VSS et le compiler régulièrement. Les équipes qui pratiquent le développement agile (comme beaucoup de petites équipes) peuvent utiliser des modules complémentaires pour compiler leur code tous les soirs. Le défaut de cette solution c'est qu'elle nécessite un autre ensemble d'outils et qu'elle pose des problèmes d'intégration (autrement dit, de compatibilité). Team Foundation Server comprend un moteur de compilation automatique évolutif qui prend en charge plusieurs configurations. Le système offre également des fonctionnalités avancées, telles que Windows WorkFlow 4.0 et s avère être facilement extensible. Figure 3 : Vue de branches Cette fonctionnalité résout un autre problème d'extensibilité : elle permet de remplacer l'outil DiffMerge intégré par un autre outil au choix et d'associer différents outils aux différentes extensions de fichiers (par exemple, vous pouvez utiliser Scooter Software Beyond Compare pour comparer des fichiers de code et Altova DiffDog pour comparer des fichiers XML). Team Foundation Server permet ainsi d'utiliser les tout derniers outils de fusion et de comparaison, au fur et à mesure de leur disponibilité. 4 5

5 Du point de vue utilisateur, Team Foundation Server ressemble-t-il à VSS? Nous avons vu certains avantages de Team Foundation Server par rapport à VSS ; mais quelles sont les différences en termes d'utilisation courante? La figure 4 représente l'interface de Visual SourceSafe et la figure 5, celle de Team Foundation Server. Figure 4 : Visual SourceSafe Comme vous pouvez le constater, les interfaces VSS et TFS sont très similaires. L'organisation et la structure de VSS ont été très bien pensées ce que reflète maintenant Team Foundation Server. Les utilisateurs de VSS retrouvent facilement leurs repères sur Team Foundation Server. Autre point clé illustré par les figures 4 et 5, Team Foundation Server est parfaitement intégré à Visual Studio. Team Foundation Server ne propose pas d'interface utilisateur distincte pour les opérations. Le développeur est ainsi plus efficace et la plupart des opérations de contrôle de code source sont effectuées dans un seul et même environnement. Le tableau 1 énumère un certain nombre d'opérations courantes dans VSS avec leur méthode de réalisation dans Team Foundation Server. Tableau 1 : Réalisation d'opérations courantes dans VSS et dans Team Foundation Server Extraction Archivage Opération VSS Team Foundation Server Affichage de l'historique Récupération de fichiers Création de branches Cliquer avec le bouton droit de la souris sur un fichier (dans VSS ou dans l'environnement de développement intégré) et sélectionner Check Out (Extraire). Il est également possible de commencer directement à saisir du code dans un fichier ; le système effectue automatiquement une opération Get Latest (Récupérer la dernière version) et extrait le fichier pour modification. Cliquer avec le bouton droit de la souris sur un fichier (dans VSS ou dans l'environnement de développement intégré) et sélectionner Check In (Archivage) ou cliquer dans la fenêtre Pending Checkins (Archivages en attente ; voir la figure 6). Cliquer avec le bouton droit de la souris sur un fichier (dans VSS ou dans l'environnement de développement intégré) et sélectionner View History (Afficher l'historique). Cliquer avec le bouton droit de la souris sur un fichier (dans VSS ou dans l'environnement de développement intégré) et sélectionner Get (Récupérer). Pour récupérer une version précise, consulter l'historique du fichier, sélectionner la version souhaitée et cliquer sur Get (Obtenir). Dans VSS, cliquer avec le bouton droit de la souris sur le dossier cible et sélectionner Share to (Partager). Sélectionner le dossier à partager et cliquer sur Share (Partager). Cliquer sur Recursive (Récursif), puis sur OK. Même procédure. Dans Team Foundation Server, l'opération Get Latest lors de l'extraction est facultative. Même procédure. Dans Team Foundation Server, la fenêtre Pending Checkins (Archivages en attente) est appelée Pending Changes (Modifications en attente ; voir la figure 7). Même procédure, à ceci près que Team Foundation Server n'affiche pas de boîte de dialogue modale. Cliquer avec le bouton droit de la souris sur un fichier et sélectionner Get Latest (Récupérer la dernière version). Pour récupérer une version précise, cliquer sur un fichier avec le bouton droit de la souris et sélectionner Get Specific Version (Récupérer une version précise). Choisir le filtre (tri par historique, par date, par étiquette, par version la plus récente ou par version de l'espace de travail), lancer la requête et cliquer sur Get (Récupérer). Dans l'explorateur du contrôle de code source, cliquer sur un dossier avec le bouton droit de la souris et sélectionner Branching (Création de branches). Ensuite, sélectionner Merging > Branch (Fusion > Branche). Cliquer sur OK. Figure 5 : Team Foundation Server Recherche avec caractères génériques Ouvrir VSS, choisir View > Search (Wildcard/ Status) (Affichage > Rechercher [avec caractères génériques/par statut]), puis sélectionner les options appropriées. Dans l'explorateur du contrôle de code source, cliquer avec le bouton droit de la souris sur une branche, un dossier ou un nœud, choisir Find in Source Control (Wildcard/Status) (Rechercher dans le contrôle de code source [avec caractères génériques/par statut]), puis sélectionner les options appropriées. Même procédure. Dans Team Foundation Server, on utilise l'élément de commande/ de menu Compare (Comparer). Comparaison Cliquer avec le bouton droit de la souris sur un fichier ou sur un dossier, puis sélectionner Show Differences (Afficher les différences). 6 7

6 Figure 6 : Fenêtre Pending Checkins (Archivages en attente) de Visual SourceSafe Figure 9 : Fenêtre d'historique dans Team Foundation Server Cette comparaison montre plusieurs différences, notamment la présence d'une colonne Version dans la boîte de dialogue VSS et d'une colonne Changeset (Ensemble de modifications) dans la boîte de dialogue Team Foundation Server (pour les raisons expliquées à la section Fonctionnalités avancées). Contrairement aux numéros de versions VSS, qui ne sont uniques que pour un même fichier, les numéros d'ensembles de modifications sont uniques au niveau du serveur : dans Team Foundation Server, il est donc possible de connaître l'ordre d'archivage des différents ensembles de modifications sans vérifier l'horodatage. Enfin, l'onglet Labels (Étiquettes) permet d'identifier directement les étiquettes auxquelles un fichier est associé. Figure 7 : Fenêtre Pending Changes (Modifications en attente) dans Team Foundation Server Comme le montrent les figures 6 et 7, Team Foundation Server propose plus d'options que VSS (le volet gauche donne accès à des panneaux supplémentaires). Cela mis à part, l'utilisation des deux solutions est quasiment identique. Les figures 8 et 9 représentent les fenêtres d'historique de VSS et de Team Foundation Server. Figure 8 : Fenêtre d'historique dans Visual SourceSafe 8 9

7 Que sont devenues mes fonctionnalités préférées? Certaines fonctions de VSS n'existent pas ou changent dans Team Foundation Server. Elles sont répertoriées dans le tableau 2. D'autres fonctions qui nécessitent une explication approfondie, comme le partage et la mise en attente, sont décrites plus en détail ci-dessous. Tableau 2 : Fonctions VSS modifiées ou supprimées dans Team Foundation Server Fonction VSS Description Et dans Team Foundation Server? Partage Le partage n'est pas pris en charge dans Team Foundation Server : TFS utilise la création de branches pour plusieurs raisons. La fonctionnalité de partage est très populaire dans VSS, car elle synchronise automatiquement les fichiers et ne nécessite pas de fusion. Mais contrairement à la création de branche, le partage crée une référence au fichier partagé : l'utilisateur peut croire à tort que le fichier partagé a été copié à un deuxième emplacement alors qu'il n'en existe qu'un exemplaire. Cela complique fortement la tâche des équipes de développement qui travaillent sur des fonctions différentes. En effet, si une équipe modifie le fichier, les modifications se répercutent sur le travail des autres équipes au risque de corrompre le code. Lors de la migration vers Team Foundation Server, les éventuels fichiers et dossiers partagés sont convertis en fichiers distincts : les fichiers sont copiés et aucune référence n'est utilisée. Extension de mot-clé Possibilité d'insérer dans l'en-tête des espaces réservés qui seront remplacés lors de l'archivage (par exemple, $Revision: $ peut être remplacé par $Revision: 23 $, pour indiquer qu il s agit de la 23ème version du fichier) Cette fonctionnalité n'est actuellement pas prise en charge dans Team Foundation Server. Mise en attente La mise en attente consiste à marquer la dernière bonne version connue d'un fichier comme version à récupérer de préférence. Elle permet à chacun de faire des essais tout en mettant une version de bonne qualité à la disposition des autres développeurs qui ne pâtiront donc pas des éventuelles erreurs. La mise en attente permet également de désigner les versions de fichiers à incorporer à la version finale du logiciel. Utilisation de la lecture seule Permet de laisser les fichiers au statut «lecture/écriture» ou «lecture seule» lors de leur récupération sur le disque dur local Cette fonctionnalité n'est actuellement pas prise en charge dans Team Foundation Server. L'équivalent Team Foundation Server de la mise en attente est l'utilisation de branches privées. Celles-ci autorisent plusieurs développeurs à travailler chacun sur sa propre version du fichier puis à fusionner les différentes versions une fois celles-ci finalisées. Restauration Possibilité de ramener la dernière version d'un fichier à une version précédente Team Foundation Server prend en charge cette fonctionnalité, mais uniquement en mode ligne de commande dans Team Foundation Server 2010 (TF Rollback). Dossiers cachés Possibilité de synchroniser le contenu de VSS avec un partage de fichiers pour que les utilisateurs qui n'ont pas accès à VSS obtiennent néanmoins les fichiers de code source Team Foundation Server ne comprend pas de fonctionnalité intégrée équivalente, mais avec une tâche planifiée et l'option Get (Récupérer) de TF, il est facile de copier les fichiers vers un partage. Mode Restauration Possibilité de régler l'horodatage local d'un fichier sur l'heure du dernier archivage, celle de la dernière extraction ou celle de la récupération du fichier depuis VSS Cette fonctionnalité n'est pas prise en charge dans Team Foundation Server. L'horodatage du fichier correspond toujours à la date et à l'heure de l'opération Get (Récupérer). Rechercher dans les fichiers Afficher l'historique Recherche de mots-clés dans des fichiers La recherche de fichiers n'est actuellement pas prise en charge dans Team Foundation Server pour des raisons de méthode de stockage des informations. Pour rechercher des fichiers, vous devez exécuter l'option Get (Récupérer) sur le disque dur local et rechercher les fichiers en local via la Recherche Windows ou tout autre utilitaire de votre choix

8 Comment migrer de VSS vers Team Foundation Server? Il existe deux méthodes de passage de VSS à Team Foundation Server : la migration ponctuelle et la migration complète. Quelle que soit la méthode choisie, il est recommandé de conserver une copie de sauvegarde de votre base de données Visual SourceSafe. C'est d'autant plus important pour une migration ponctuelle : vous conserverez ainsi tout l'historique de vos fichiers avec version. Migration ponctuelle La migration ponctuelle revient à récupérer la dernière version d'un projet, à annuler la liaison entre cette version et VSS et à l'ajouter à Team Foundation Server. C'est l'option la plus simple et la plus rapide mais elle comporte un inconvénient : elle ne transfère pas l'historique. Généralement, ce n'est pas grave car il vous suffit de prendre une copie de VSS et de l'archiver si vous avez besoin de récupérer l'historique. Pour effectuer une migration ponctuelle, procédez comme suit : 1. Ouvrez Visual Studio et vérifiez que le contrôle de versions est assuré par Visual SourceSafe (Outils > Options > Contrôle de code source). 2. Ouvrez le projet à convertir et lancez l'opération Get Latest (Récupérer la dernière version). 3. Sélectionnez Fichier > Contrôle de code source > Modifier le contrôle de code source. 4. Annulez la liaison entre la solution et tous les projets et cliquez sur OK. 5. Fermez la solution. Un message vous invite à enregistrer les modifications. Cliquez sur Oui. 6. Définissez Team Foundation Server comme solution de contrôle de version (Outils > Options > Contrôle de code source). 7. Ouvrez l'explorateur du contrôle de code source (Affichage > Autres fenêtres > Explorateur du contrôle de code source). 8. Assurez-vous d'avoir créé un projet d'équipe. Créez-en un, le cas échéant. 9. Sélectionnez le projet dans lequel vous souhaitez placer les fichiers et mappez cet emplacement sur le disque dur local. 10. Copiez la solution de son emplacement actuel vers l'emplacement mappé à l'étape Ouvrez la solution copiée dans Visual Studio. 12. Cliquez sur la solution avec le bouton droit de la souris et sélectionnez Ajouter la solution au contrôle de code source. 13. Archivez les modifications en attente. La solution dans son ensemble ainsi que l'intégralité des projets se trouvent maintenant dans Team Foundation Server. Migration complète Pour réaliser une migration complète, vous devez suivre plusieurs étapes dans l'ordre. La marche à suivre est détaillée ci-dessous ; vous trouverez également des liens supplémentaires dans la section de référence (à la fin du document). 1. Vérifiez que VSS est installé sur un ordinateur équipé de Team Explorer. 2. Vérifiez que la version de VSS est Copiez votre référentiel VSS sur cet ordinateur. Conservez la version de production en cas de problème (les problèmes sont rares, mais il vaut toujours mieux protéger son travail). Assurez-vous que tous les développeurs ont archivé leur code avant de procéder à la copie. 3. Installez le fichier KB ( : ce correctif résout un problème connu survenant lors du passage de VSS à Team Foundation Server avec VSSConverter. 4. Procurez-vous le mot de passe administrateur pour l'installation VSS. 5. Créez le fichier de paramètres d'analyse (voir l'exemple ci-dessous). Appelez-le analysissettings.xml pour les besoins de cette procédure. Enregistrez-le dans un emplacement compris dans le chemin d'accès ou dans %programfiles(x86)%\microsoft Visual Studio 10.0\Common7\IDE. <?xml version= 1.0 encoding= utf-8?> <SourceControlConverter> <ConverterSpecificSetting> <Source name= VSS > <VSSDatabase name= c:\vssdatabase 1 ></VSSDatabase> <UserMap name= c:\migrate\usermap.xml 2 ></UserMap> <SQL Server= SQL Server Name 3 ></SQL> </Source> <ProjectMap> <Project Source= $/FolderA 4 ></Project> <Project Source= $/FolderB ></Project> </ProjectMap> </ConverterSpecificSetting> <Settings> <Output file= Analysis.xml 5 ></Output> </Settings> </SourceControlConverter> 6. Ouvrez l'invite de commande Visual Studio 2010 et saisissez la commande suivante (vous pouvez utiliser une invite de commande standard, dès lors que vous disposez des droits administrateur. L'application VSSConverter.exe se trouve dans %programfiles(x86)%\microsoft Visual Studio 10.0\Common7\IDE. Si vous avez créé le fichier analysissettings.xml dans un autre emplacement, indiquez le chemin complet du fichier) : Vssconverter analyze analysissettings.xml 7. L'opération terminée, assurez-vous de l'absence d'erreurs et consultez les avertissements pour en déterminer la gravité. La plupart des avertissements sont de simples messages d'information. Corrigez les éventuelles erreurs et exécutez à nouveau la commande indiquée à l'étape 6 jusqu'à ce qu'il n'en reste plus aucune. 8. Configurez la structure de projet dans Team Foundation Server : créez les projets d'équipe dont vous souhaitez importer le code depuis VSS. 9. Créez le fichier de paramètres de migration (voir l'exemple ci-dessous). Appelez-le migrationsettings.xml pour les besoins de cette procédure. 6 1 Chemin d'accès de la base de données VSS. Il s'agit du dossier qui contient le fichier srcusers.ini. 2 Le système crée le fichier Usermap.xml, qui correspond au chemin du projet (nom de fichier compris). Si vous souhaitez copier les données dans c:\migration, assurez-vous que ce chemin d'accès existe bien : les répertoires ne seront pas créés. 3 Utilisez SQL Server si votre base de données VSS dépasse les 4 Go (par défaut, VSS Converter utilise SQL Express qui ne peut pas stocker plus de 4 Go de données). 4 Dossiers source dans VSS. $/ représente la racine de VSS. Cela permet d'analyser tout un référentiel VSS en une fois. 5 Fichier d'analyse créé après l'exécution de vssconverter. Par défaut, il est enregistré dans le dossier d'exécution de vssconverter. Vous pouvez toutefois lui associer un chemin d'accès complet si vous le souhaitez. 6 Si vous avez utilisé la balise SQL Server dans le fichier de paramètres d'analyse, utilisez-la également dans ce cas

9 <?xml version= 1.0 encoding= utf-8?> <SourceControlConverter> <ConverterSpecificSetting> <Source name= VSS > <VSSDatabase name= c:\vssdatabase ></VSSDatabase> <UserMap name= c:\migrate\usermap.xml 7 ></UserMap> </Source> <ProjectMap> <Project Source= $/FolderA Destination= $/TeamProjectA 8 /> <Project Source= $/FolderB Destination= $/TeamProjectB/ProjectB /> </ProjectMap> </ConverterSpecificSetting> <Settings> <TeamFoundationServer name= My_TFS_Server port= 8080 protocol= http collection= tfs/defaultcollection ></TeamFoundationServer> <Output file= Migration.xml 9 ></Output> </Settings> </SourceControlConverter> Comment obtenir Team Foundation Server? Avec le lancement de Visual Studio 2010, Team Foundation Server 2010 est intégré aux outils client suivants : Visual Studio 2010 Professional, Visual Studio 2010 Premium, Visual Studio 2010 Ultimate et Visual Studio Test Professional Chaque abonnement MSDN donne droit à un déploiement de production de Team Foundation Server et comprend une licence d'accès client Team Foundation Server. Ainsi, les développeurs n'ont rien à acheter ni à maintenir. Quelle que soit votre édition (Professional, Premium, Ultimate ou Test Professional), vous êtes couverts. 10. Mettez à jour le fichier Usermap.xml. Chacun des utilisateurs listés dans ce fichier doit être associé à un nom AD valide possédant au moins une autorisation de lecture dans Team Foundation Server. Il est primordial d'ajouter d'abord les utilisateurs à Team Foundation Server. En revanche, il n'est pas indispensable de créer un mappage un à un : si un nouveau collaborateur ne possède pas d'entrée AD, vous pouvez simplement le mapper à un ancien collaborateur. Ces informations permettent d'identifier la personne qui a archivé le fichier. Dans les commentaires sur l'archivage, c'est le nom d'utilisateur d'origine qui apparaît. Si vous n'avez pas d'abonnement MSDN, vous pouvez vous procurer Team Foundation Server auprès de votre revendeur ou par Internet, sur le site Microsoft Store. La licence autorise jusqu'à cinq (5) utilisateurs sans licence d'accès client (CAL). Vous pouvez ajouter des utilisateurs supplémentaires avec des licences CAL. 11. Dans l'invite de commande de Visual Studio 2010, exécutez : Vssconverter migrate migrationsettings.xml La conversion est effectuée ; elle devrait être correcte. N'oubliez pas de configurer Visual Studio pour que le contrôle de code source soit assuré par Team Foundation Server. Dans le menu principal de Visual Studio, choisissez : Outils > Options > Contrôle de code source. Ensuite, sélectionnez Visual Studio Team Foundation Server. 7 Dans ce cas, c'est le chemin d'accès au fichier usermap.xml, créé au cours de l'analyse. 8 Mappage qui indique à TFS l'emplacement du code. À l'étape 6, vous devez créer les projets d'équipe à mapper à ces données. Vous n'avez pas besoin de mapper les données à la racine. Par exemple, vous pouvez prendre un dossier VSS appelé «$/MyProject» et le déplacer vers «$/MyProject/Root/Dev» dans TFS. 9 Fichier créé pour vous. Vous pouvez spécifier son chemin d'accès complet si vous le souhaitez

10 Team Foundation Server, une longueur d'avance Comme vous l'avez compris, l'utilisation de Team Foundation Server n'est pas très différente de celle de VSS pour le contrôle de version. À quelques rares exceptions près, toutes les fonctionnalités de VSS sont disponibles dans Team Foundation Server qui est d'ailleurs plus complet. Aux premières étapes vous trouverez peut-être que Team Foundation Server ne ressemble pas exactement à VSS. Il est possible que vous deviez adapter certains éléments mais au final, Team Foundation Server fonctionnera comme vous le souhaitez. Ses nombreux avantages, tels que l'utilisation de SQL Server pour le stockage, assurent l'intégrité des données tout en lui apportant évolutivité, fiabilité, simplicité de maintenance et hautes performances. Les développeurs voient leur travail simplifié et accéléré. Ils peuvent ainsi se consacrer plus longuement au développement et passer moins de temps à la gestion du code source. Avec les fonctionnalités hautement extensibles propres à Team Foundation Server et le Suivi des éléments de travail, Team Foundation Server vous permet d'évoluer à votre rythme, sans contrainte. Utilisateurs de VSS, passez à Team Foundation Server! Si vous bénéficiez d'un abonnement MSDN, vous pouvez d'ores et déjà accéder à Team Foundation Server Sinon, téléchargez une version d'essai sur Références Vous trouverez ci-dessous quelques liens vers des pages d informations sur la migration : Utilitaire de la ligne de commande de VSSConverter pour la migration du contrôle de code source Procédure : migration de Visual SourceSafe vers Team Foundation Commande Analyze (VSSConverter) Commande Migrate (VSSConverter) Comment créer un fichier de paramètres pour l'analyse et la migration du contrôle de code source Exemple de fichier de paramètres VSSConverter Procédure : modifier le fichier de mappage de l'utilisateur de migration du contrôle de code source

11 2010 Microsoft Corporation. Tous droits réservés.