ATTENTION aux changements de domaine quand vous utilisez TFS!

J’en ai eu la douloureuse expérience aujourd’hui et j’ai pu trouver quelques alternatives un peu couteuses, avec un “minimum de risques”. Nous avions certes été prévenus la veille, mais n’avions pas anticipé les impacts.

Le problème

Dans une infrastructure dans laquelle vous êtes employé, il peut y avoir des changements de domaines (pour X raison). Là ou j’effectue ma mission, il y a eu un changement de domaine ET un changement de nom d’utilisateur : je suis passé de DOMAINE1\poulinda à DOMAINE2\dpoulin.

Aucun problème de connexion à mon poste, mais quand j’ai ouvert ma solution Visual Studio (2010), j’ai eu un message d’erreur m’informant qu’il était impossible de se connecter au serveur TFS et 2 choix s’offraient à moi : Travailler en mode déconnecté, ou déconnecter de façon permanente le projet du gestionnaire de source.

Les résolutions du problème

Il faut utiliser pour cela un outil propre à TFS qui s’appelle tf (Disponible via le Visual Studio Command Prompt). Les commandes possibles à l’aide de cet outil : https://msdn.microsoft.com/en-us/library/54dkh0y3.aspx

Changement d’utilisateur

S’il s’agit d’un changement de nom d’utilisateur, alors, la résolution est simple. Il faut utiliser cette commande :

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>tf workspaces /server:https://*tfsServer*:8080 /computer:*computerName* /updateUserName:DOMAINE1\poulinda

Cette commande va mettre à jour l’utilisateur DOMAINE1\poulinda à partir des informations du contexte d’identité Windows courant, c’est à dire DOMAINE2\dpoulin.

On a tout de suite après l’exécution de cette commande, l’output suivante :

Collection:
<br /> Workspace Owner Computer Comment<br /> --------- ------- -------- ----------------------------------------------------<br /> dpoulin<br />

Ce n’était malheureusement pas mon cas. Cette commande ne marchera d’ailleurs que s’il y a eu un changement d’utilisateur, et pas un changement de domaine.

Changement de domaine

Il s’agit donc d’un changement de nom de domaine et de nom d’utilisateur. Si vous utilisez la commande précédente, vous aurez ce message d’erreur :

No workspace matching *;dpoulin on computer found in Team Foundation Server https://tfsServer:8080.

L’outil n’arrive pas en effet à faire d’association entre mon ancien nom d’utilisateur et le nouveau.

Après avoir recherché plusieurs solutions, je n’en ai trouvé aucune vraiment convenable, mais, elle m’a permis tout de même de savoir quels étaient les fichiers que j’avais modifié, les sauvegarder, puis, tout remettre en état.

Étape 1

Il faut d’abord afficher les informations disponibles concernant votre serveur TFS afin de récupérer les bonnes informations dont vous aurez besoin.

<br /> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>tf workspaces /server:https://*tfsServer*:8080 /computer:*computerName* /owner:* /format:detailed<br /> ===============================================================================<br /> Workspace : *computerName*<br /> Owner : DOMAINE1\poulinda<br /> Computer : *computerName*<br /> Comment :<br /> Collection :<br /> Permissions: Private

Working folders:
$/: D:\localWorkspaceFolder

Étape 2

Il faut supprimer le workspace courant :

<br /> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>tf workspace /delete /server:https://tfsServer:8080 ;DOMAINE1\poulinda<br /> A deleted workspace cannot be recovered.<br /> Workspace ';DOMAINE1\poulinda' on server 'https://tfsServer:8080' has 2 pending change(s).<br /> Are you sure you want to delete the workspace? (Yes/No) Yes<br />

Étape 3

Une fois après avoir supprimé votre Workspace, il faut le remapper (au travers Visual Studio).

Étape 4

Quand vous ouvrirez votre solution, il faut ensuite récupérer la dernière version de votre projet.

Une fois que c’est fait, vous devriez avoir un ensemble de conflits probables. Tous les fichiers que vous y retrouver dans la fenêtre “Pending Changes” sont ceux que vous aviez édité (et donc, pas “committés”).
Il ne vous est malheureusement possible que de remplacer la version locale. Donc, faites des sauvegardes de ces versions, puis écrasez les.

Étape 5

Les fichiers sauvegardés, appliquez y de nouveau vos modifications, puis, Validez vos changements (commit).

Voilà, vous aurez restauré votre solution au même état que vous l’aviez laissé…

Autre Solution ?

Une autre solution que j’ai lu ici : https://social.msdn.microsoft.com/Forums/en-US/tfssetup/thread/64359a2f-c3a6-4d00-bd7c-6fc0e1cfe41a
Elle suggère que nous modifions les informations de l’utilisateur directement dans la base de données TFS. Non pas que ça n’était pas possible, mais nous n’avons pas non plus voulu aller jusque là.

Impacts probables ?

Si vous êtes de nombreux développeurs, il faudra être patient et réaliser les “merges” et changements adéquats. Pour ma part, j’ai eu de la “chance”, car, je n’avais que 2 fichiers modifiés, et je travaille dans une petite équipe. Si vous en aviez plus, ce serait beaucoup plus délicat.

Conseils Pratiques

Les solutions de sauvegarde sont nombreuses il faut avouer, et je ne pourrai pas vous en proposer une en particulier, car, cela dépend de vos méthodes de travail, du client également, et de bien d’autres critères. On peut cependant penser au Commit, au Commit to Shelve (mais, ces deux dernières options risquent d’être inutiles si on rencontre un problème comme celui décrit dans ce billet) mais il existe aussi des outils de génération et sauvegarde automatique de sources qui peuvent s’intégrer à TFS (on connait par exemple msbuild …).
Concernant les problèmes de changement de domaine / utilisateur, il est recommandé de fermer sa session pour éviter des effets de bord, mais là encore, ce n’est pas quelque chose qu’il est systématiquement possible de faire (surtout si on n’est pas prévenu).

Bonne journée !