Pourquoi et comment restaurer son serveur TFS

Il existe plusieurs scénarios où il s'avère utile de restaurer son Team Foundation Server.

Le scénario le plus courant est celui qui consiste à restaurer un serveur TFS à partir d'un backup suite à un désastre sur le serveur. Ce scénario est critique pour toute entreprise ayant décidé de migrer tous ses développements dans un référentiel TFS.

Un deuxième scénario consiste à déplacer les données d'un serveur TFS d'une machine à une autre, plus puissante par exemple, ou effectuer un passage d'un serveur virtuel à un serveur physique.

Dans ces scénario où un seul serveur (le nouveau) est actif à la fois, il suffit de suivre la procédure officielle Microsoft qui fonctionne très bien pour l'avoir déjà testée. Bien entendu, comme toute procédure de restauration, il est toujours préférable de l'avoir expérimenté au moins une fois, lorsque tout va bien, afin d'en tirer les meilleurs bénéfices le jour où vous en avez vraiment besoin, et qu'il vous faut restaurer votre environnement TFS en urgence.

Dans le cas où vous avez besoin de faire tourner côte à côte le serveur TFS l'original et le restauré, la procédure ci-dessus n'est pas suffisante.

Je pense notament à la restauration d'un serveur TFS de production vers un environnement de Test à des fins de validation de procédures ou d'application de services pack par exemple.

Je pense également au clonage dans le but de créer des master afin d'installer plus vite des serveurs TFS dans le cas où plusieurs serveurs TFS sont à installer dans l'entreprise.

Cas de la restauration d'un serveur TFS de Production sur l'environnement de Test

Si on se connecte successivement au serveur TFS de production et au serveur de Test contenant la copie des données de production, il faut impérativement supprimer le répertoire de cache de Team Explorer avant chaque passage s'un serveur à l'autre, sous peine de vous connecter sans le savoir au serveur d'origine, quelque soit votre choix dans Team Explorer, avec les risques que vous comprendrez.

Un serveur TFS dispose en interne d'un numéro unique, un GUID, appelé repositoryID. La connection à un serveur TFS est optimisée par le client Team Explorer qui met en cache les informations du serveur TFS dans un dossier dont le nom est le repositoryID.
Lorsqu'on restaure la base de donnée TFS du serveur de production vers le serveur de test, ce dernier hérite du même GUID, ce qui explique ce problème.
Il est donc necessaire de changer ce GUID sur le serveur de Test afin d'éviter tout problème.

Comment changer le GUID sur le serveur TFS de Test

Il existe un outil ligne de commande InstanceInfo.exe fourni avec TFS que l'on utilise en 2 phases :

La première étape consiste à réinitialiser à zero le GUID sur les bases de données TFSWorkItemTracking,TFSBuild,TFSVersionControl,TFSIntegration de TFS.
“%TFSInstallDir%\Tools\InstanceInfo.exe" stamp /setup /install /rollback /d TFSWorkItemTracking,TFSBuild,TFSVersionControl,TFSIntegration /s <<your new data tier>> 

La deuxième consiste à générer un nouveau GUID sur les bases de données TFSWorkItemTracking,TFSBuild,TFSVersionControl,TFSIntegration de TFS.
"% TFSInstallDir %\Tools\InstanceInfo.exe" stamp /d TFSWorkItemTracking,TFSBuild,TFSVersionControl,TFSIntegration /s <<your new data tier>>

Conclusion

On retiendra que le clonage d'un serveur TFS implique de changer un GUID à plusieurs endroits dans la base TFS pour une utilsiation côte à côte. Un utilitaire bien caché, InstanceInfo.exe permet heureusement de faire l'opération proprement. Vivement un update de la documentation d'administration de TFS.

En espérant que çà vous sera utile.