TFS 11 (vNext) – Local Workspaces

J’ai déjà twitté (@emargraff) à propos de ça, mais je pense qu’il s’agit d’un sujet tellement attendu et une modification tellement importante dans la manière d’appréhender la gestion du contrôle de code source avec TFS que je me suis dit qu’une explication plus longue valait le coup :)

Team Foundation Server existe depuis 2005 et 3 versions ont déjà vu le jour. L’objectif de TFS est bien plus large que la gestion des sources de l’application, tout son intérêt réside dans le fait que l’intégralité du processus de création de logiciels est prise en compte. La définition des spécifications, le découpage en tâches, le suivi d’anomalies, la création de campagnes de tests, l’automatisation des builds ou encore le reporting sont autant d’aspects gérés par la plateforme. L’intégration qui existe entre ces différentes fonctionnalités est certainement la raison principale du nombre important et toujours croissant d’équipes qui choisissent cette plateforme comme outil de collaboration.

Si je parle de tout cela, c’est qu’il est important de prendre ces aspects en considération lorsque l’on évalue TFS. Très souvent, les développeurs m’expliquant les raisons pour lesquels ils ne sont pas toujours complètement satisfaits par TFS ne connaissent et n’utilisent que la partie de gestion du code source. Aie ! ;) Ceci est une erreur à mon avis. TFS est bien plus que cela et si cela vous intéresse je pourrais vous expliquer en détails pourquoi je suis convaincu que c’est la solution la plus complète et le choix le plus judicieux en termes d’outils ALM à l’heure actuelle.

Les reproches faits au contrôle de code source actuel le sont généralement par d’anciens utilisateurs de Subversion. Pour comprendre ce qui les dérange, rappelons le fonctionnement de TFS sur cet aspect.

Les sources d’un projet sont stockées dans le serveur TFS. Pour pouvoir travailler sur les fichiers de ce projet, il est nécessaire de définir un workspace (espace de travail). Un workspace est un objet géré par le serveur, qui contient un certain nombre d’informations :

  • L’ensemble des mappings (liaisons) entre un ou plusieurs répertoires sur le serveur, et le ou les répertoires sur mon poste, là ou je veux les stocker pour pouvoir les modifier
  • La liste des modifications en cours dans l’espace de travail
  • La version de chacun des fichiers que j’ai localement

C’est l’espace de travail qui contrôle ce qui se passe en local, sur mon poste. Quand je veux travailler sur un fichier, il faut que je notifie au préalable le serveur de mon intention. Cette opération peut être réalisée explicitement ou implicitement lorsque je modifie le fichier dans Visual Studio, mais elle est obligatoire dans tous les cas. Pour savoir si un fichier est en cours de modification et pour m’éviter d’effectuer des changements sans notification (appelée “Extraction” ou “Check Out” en anglais), TFS utilise l’attribut de lecture seule des fichiers. Cela ne concerne pas que la modification, mais également l’ajout d’un fichier. L’ajouter dans le répertoire local de mon workspace ne suffit pas, il est nécessaire de prévenir le serveur avec une opération d’ajout indiquant que je veux que celui-ci soit ajouté au contrôle de code source.

Ce comportement a également un impact sur la gestion du mode offline de TFS. Lorsque mon poste n’a pas accès au serveur pour une raison X ou Y, je dois passer en hors ligne (ce qui nécessite un redémarrage de Visual Studio, sauf si vous utilisez le plugin “Go Offline”, qui ajoute un bouton magique !). Du fait que toutes les informations sont stockées dans le workspace, sur le serveur TFS mes possibilités d’actions sont très limitées lorsque je travaille hors ligne. Je ne peux pas comparer mes modifications avec la version de laquelle je suis parti, je ne peux pas effectuer des opérations d’ajout de fichiers, supprimer un fichier, ou annuler mes modifications.

Tous ces comportements critiqués par les adeptes de Subversion (et par d’autres) peuvent effectivement avoir un impact sur le travail de certains profils de développeurs itinérants qui se retrouvent souvent face à ce type de situations. Les raisons énoncées par l’équipe de développement du produit sont principalement liées aux performances et à la scalabilité apporté par ce système.

C’est là qu’arrive TFS 11 (nb : il s’agit du numéro de version. “11” n’a pas de rapport avec l’année de sortie.). TFS 11 apportera un ensemble de nouveautés non négligeables dont vous pouvez déjà avoir un aperçu depuis quelques semaines, dans le livre blanc téléchargeable ici: http://www.microsoft.com/visualstudio/en-us/roadmap.

Brian Harry à récemment fait une annonce sur son blog concernant un nouveau type de workspace qui apparaitra dans la prochaine version : les “Local workspaces”. Grâce à cela, TFS n’est plus le maitre de toutes les décisions, et laisse la liberté à l’utilisateur d’effectuer des modifications localement, sans que celui-ci n’ai besoin de le prévenir. Autrement dit, je pourrais effectuer les modifications qui me plaisent et TFS réagira à ces opérations. Dans le cas où il ne saura pas quoi faire, il me posera la question.

Principalement, ce qu’il faut noter :

  • Plus de readonly en local. Je fais mes modifications, TFS comprendra que je modifie le fichier sans que je le prévienne
  • Si j’ajoute un fichier en local, TFS le détectera et me proposera de l’ajouter
  • Indirectement : si j’utilise un autre outil que Visual Studio pour modifier un fichier, plus besoin de plugin pour interagir avec mon workspace!

Cela aura également un impact important (et positif) sur le mode hors ligne:

  • Plus jamais ces popups insupportables me demandant si je veux enlever le readonly sur le fichier quand je commence à la modifier
  • Je pourrais faire un diff avec la version à partir de laquelle je suis parti dans mon workspace
  • Je pourrais annuler mes modifications sans être connecté au serveur (il reviendra alors dans la dernière version que j’avais récupéré du serveur)
  • Je pourrais voir mes modifications en cours même en mode offline
  • Les opérations de suppression, renommage et d’ajout seront également possibles

Je peux vous citer une liste interminable de personnes qui seront ravis d’apprendre ça ! :-) C’est à mon sens une liste de modifications qui amène la brique de gestion de code source de TFS à une maturité encore plus grande.

Derniers résistants, toujours utilisateurs de Subversion, plus aucune excuse pour passer à TFS! ;-)

Dans son billet, Brian fait une parenthèse sur le fait que non, ceci ne fait pas de TFS un DVCS. Les DVCS (Distributed Version Control System) sont une autre manière d’appréhender la problématique de contrôle de code source, en intégrant la notion d’historique local. Le plus connu est Git. Il précise par contre que cela n’est pas complètement écarté de la réflexion autour de TFS. Simplement, ça ne sera pas pour TFS 11!

Dernier point, important : les workspaces tels que nous les connaissons actuellement ne disparaitront pas. Les workspaces locaux seront le mode de fonctionnement par défaut, mais le mode actuel restera une solution possible pour les cas lors desquels ils seront utiles.

.Dispose();

Publié vendredi 5 août 2011 23:47 par Etienne Margraff
Classé sous , , ,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

# re: TFS 11 (vNext) – Local Workspaces @ samedi 6 août 2011 00:50

Techniquement, sais tu comment cela fonctionne ? on a un service Windows qui va scanner l'ensemble des fichiers du workspace local ?

Si c'est le cas, j'ai bien peur que cela rajoute un peu de lourdeur à Visual Studio <=> TFS :(

cyril

# re: TFS 11 (vNext) – Local Workspaces @ dimanche 7 août 2011 12:59

"Je peux vous citer une liste interminable de personnes qui seront ravis d’apprendre ça ! :-)" Moi par exemple :)

Matthieu MEZIL

# re: TFS 11 (vNext) – Local Workspaces @ lundi 8 août 2011 09:35

@cyril : non, pas d'informations sur comment cela va fonctionner. ça paraît assez logique effectivement que ça soit un service qui tourne sur le poste.

On verra ce que ça donne :)

@Matthieu, je le savais ! :p

Etienne Margraff

# re: TFS 11 (vNext) – Local Workspaces @ lundi 8 août 2011 10:15

même si tfs est très tordu, je ne vois pas techniquement pourquoi il y aurait besoin d'un service qui tourne en tache de fond. Mercurial et git fonctionnent très bien sans, je ne vois pas pourquoi tfs en aurait besoin lui, non? il faudra qu'il intègre un équivalent du push pour faire la distinction entre commit local et distant mais c'est tout dans l'absolu ;-)

Rui

# re: TFS 11 (vNext) – Local Workspaces @ lundi 8 août 2011 12:16

@Rui en effet, Mercurial (dont je suis très fan) et Git marchent bien mais parce qu'on commit en local et qu'ils n'implémentent pas vraiment la notion de workspace.

La team TFS insiste bien sur le fait que TFS vNext ne sera pas du DVCS, même si on commence à tendre de plus en plus vers ce modèle.

Pierrick CATRO-BROUILLET

# re: TFS 11 (vNext) – Local Workspaces @ lundi 8 août 2011 15:11

Pour rappel, la notion de Workspaces dans TFS a été créé pour optimiser au maximum les échanges clients / serveurs et permettre un bon control central (a tout moment, le serveur sait ce que chaque developpeur à sur sa machine et ne renvoie donc que ce qui est nécessaire sans faire de check local).

Ce mode ne plait pas a certains utilisateurs, surtout ceux qui font des modifs en local sans prévenir le serveur et créént donc des désynchros de sources avec des risques de pertes.

Le local workspace est pour moi juste une alternative pour cibler ces utilisateurs, les autres continuant à utiliser les workspaces serveurs.

azra

# re: TFS 11 (vNext) – Local Workspaces @ mardi 9 août 2011 14:46

A mon avis non, ça sera un mode largement utilisé.

En plus il sera choisit par défaut.

Etienne Margraff


Les 10 derniers blogs postés

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01

- SharePoint Online: Script PowerShell pour supprimer une colonne dans tous les sites d’une collection par Blog Technique de Romelard Fabrice le 11-27-2018, 18:01