MS Team Foundation Server dans les environnements distribués - astuces, astuces et astuces nécessaires

Question

Quelqu'un utilise-t-il Team Foundation Server au sein d'une équipe géographiquement répartie ?Nous sommes au Royaume-Uni, essayons de travailler avec une équipe en Australie et nous trouvons cela assez difficile.

Nos deux principaux enjeux sont :

1. Les choses nous sont vérifiées sans que nous demandions la dernière version.
2. Même lorsque vous utilisez un proxy, la plupart des choses mettent du temps à se produire.

Beaucoup de petites choses vraiment ennuyeuses comme celle-ci durcissent nos artères, nous empêchent de fournir du code et créent franchement une expérience utilisateur semblable à celle de pousser du sirop d'or sur une dune de sable.

Est n'importe qui utilise-t-il réellement TFS de cette manière, quotidiennement avec un succès (relatif) ?

Si oui, avez-vous des trucs, astuces, astuces ou pièges qui valent la peine d'être connus ?

P.S.La mise à niveau vers CruiseControl.NET n'est pas une option.

Answer 1

Mettez définitivement à niveau vers TFS 2008 et Visual Studio 2008, car il s'agit de la version "v2" de Team System à tous points de vue.Résout de nombreux problèmes de petite et moyenne taille.

Quant aux "choses vérifiées au hasard", c'est presque toujours car Visual Studio a décidé de modifier les fichiers en votre nom.Essayez d'obtenir les dernières versions de Team Explorer, sans rien ouvert dans Visual Studio, et voyez si ce comportement persiste.Je parie que non !

Plusieurs serveurs TFS sont une mauvaise idée.Assurez-vous que votre proxy est correctement configuré, car il met en cache les GET répétés.Cela dit, TFS est un modèle connecté au serveur, il sera donc toujours un peu plus lent que les véritables systèmes de contrôle de source « hors ligne ».

De plus, si vous pouviez modifier votre question pour contenir des plaintes ou des détails plus spécifiques, cela aiderait - pour le moment, elle est terriblement vague, donc je ne peux pas très bien répondre.

Answer 2

Nous utilisons TFS avec une équipe quelque peu distribuée – ils ne sont pas trop loin mais se connectent via un VPN lent et peu fiable.

Pour votre premier problème, obtenir la dernière version à la caisse n'est pas le comportement par défaut.(Voici un explication) Il y a un ajouter à mais cela le fera pour vous.

Voici le flux de travail qui fonctionne pour nous :

1. Obtenez la dernière
2. Construisez et vérifiez que rien n'est cassé
3. Travail (modifications en attente)
4. Obtenez à nouveau les dernières nouveautés
5. Gérer les conflits de fusion
6. Construisez et vérifiez que rien n'est cassé
7. Enregistrement

[modifier] OK, on ​​dirait que vous avez reformulé cette partie de la question.Oui, Jeff a raison, VS décide d'extraire certains fichiers "pour vous", comme les fichiers sln et proj.Il extrait également automatiquement tout fichier source que vous modifiez (c'est ce que vous voulez, n'est-ce pas ?bien que vous puissiez modifier ce paramètre dans outils > options > contrôle de source)

Le proxy met apparemment un certain temps à démarrer (nous ne l'utilisons pas), mais une fois qu'il a mis en cache la majeure partie de l'arborescence, il est censé être assez rapide.Pouvez-vous effectuer un peu de surveillance et trouver le(s) goulot(s) d'étranglement ?

Y a-t-il autre chose qui vous pose problème, à part l'obtention du dernier paiement et la rapidité ?

Answer 3

D'après ma compréhension, vous pouvez avoir plusieurs serveurs d'applications TFS à différents endroits.Soit ils peuvent tous deux communiquer avec le même serveur SQL, soit vous pouvez utiliser la mise en miroir de SQL Server.Avoir votre propre serveur TFS local accélérerait probablement vos temps de développement.