Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Azra [Florent Santin]

.Net, X'Net, aucun lien de parenté V2.0

Actualités


  • MSN Alerts
    View Florent Santin's profile on LinkedIn
Hep, msieur, c’est quoi le serveur Proxy de Team Foundation Server?

Le serveur Proxy de Team Foundation sert à optimiser les temps d’accès aux sources gérées par le contrôleur de code source de Team Foundation Server.

Grosso modo, le proxy se comporte comme un système de cache qui va stocker les fichiers extraits du contrôleur de code source sur le système de fichiers du proxy afin de pouvoir les servir plus rapidement lors de la prochaine demande.

Le proxy n’agit qu’à l’extraction des sources (get last version) et jamais à l’archivage (checkin). Ce dernier s’effectue toujours en direct avec le serveur TFS.

image

    1. Le développeur 1 demande (get) des sources au serveur Proxy
    2. Le proxy n’a pas la version des sources souhaitées dans son cache de fichiers, il sert donc d’intermédiaire et interroge le serveur TFS pour les extraire
    3. Le développeurs 1 reçoit les sources demandées du serveur Proxy
    4. Le développeur 2 demande les même sources, le serveur Proxy les a déjà dans son cache et les renvoies donc directement
    5. Les archivages (checkin) se font directement vers le serveur TFS sans passer par le Proxy, le cache proxy des fichiers modifiés sera donc rafraichit lors de la prochaine demande des fichiers modifiés par un autre développeur.

Dans quels cas est ce que l’utilisation du proxy n’est pas vraiment pertinente:

  • Si le serveur est sur un site central et que un ou plusieurs développeurs travaillent à distance, mais chacun sur un projet d’équipe ou ensemble de sources différentes. En effet, le proxy est utile pour optimiser les temps d’extraction. Un développeur travaillant seul sur un projet à distance aura forcement toujours les dernières sources sur son poste de travail, vu qu’il travaille dessus. Le proxy n’a donc pas d’intérêt et n’optimise rien si les développeurs ne sont pas sur le même site et/ou ne travaillent jamais sur les même sources.

image

Dans quels cas est ce que l’utilisation du proxy est pertinente:

  • Si plusieurs développeurs distants travaillent sur un même projet ou ensembles de sources. Car dans ce cas, le premier développeur à demander les sources du serveur central disposera celle-ci sur le serveur proxy intermédiaire. Les autres développeurs, lors de la demande des même sources, viendront directement se servir dans le cache du proxy (voir premier schéma), ce qui sera toujours plus rapide que si ils avaient à se servir sur le serveur central.
  • Si un développeur ou un service doit effectuer des extractions similaires de manière fréquentes. C’est le cas par exemple du service de build qui à chaque compilation télécharge la dernière version des sources dans un nouveau répertoire pour les compiler. Il y’a souvent beaucoup de code commun entre deux builds (surtout lorsque l’on est en intégration continue), le temps d’accès aux sources peut donc être considérablement réduit et le temps du process de build complet optimisé en installation le service de proxy sur le même serveur que le service de build.

image

Physiquement, le proxy se présente sous la forme d’un ensemble de services Web (IIS) ayant la même signature que ceux de communication avec le contrôleur de code source proposés par Team Foundation Server ainsi que d’un espace de stockage de fichiers. Le service de Proxy s’installe directement depuis le DVD de Team Foundation Server.

Pour le configurer une fois installé, il faut modifier le contenu du fichier proxy.config situé dans son répertoire d’installation, sous répertoire: Web Services\VersionControlProxy. Il y est possible de spécifier la liste et les URL des serveurs Team Foundation Server ciblés ainsi que les comptes utilisateurs et droits nécessaires pour s’y authentifier, mais également les paramètres de gestion de cache tels que le chemin local de stockage des données ou la durée de conservation de celles-ci.

A noter qu’un serveur TFS peut posséder autant de services proxy que requis, aucune configuration n’est à faire sur le serveur ciblé, tout se passe sur les proxy.

Pour activer l’utilisation d’un proxy dans Visual Studio, cela se passe directement dans la fenêtre de configuration ci-dessous, accessible depuis les menus Outils / Options, onglet  Source Control / Visual Studio Team Foundation Server  :

image

A noter que si le serveur proxy ne répond pas aux demandes de Visual Studio, celui-ci est automatiquement désactivé afin que les appels se fassent directement vers le serveur Team Foundation Server.

Pour la doc détaillée MSDN de présentation et configuration du serveur Proxy, cela se passe par ici: http://msdn.microsoft.com/fr-fr/library/ms252490(VS.80).aspx

Et voila!

PS: Si vous voulez que je traite et détaille des sujets particuliers autour de Visual Studio Team System, n’hésitez pas à laisser un commentaire!

PS2: Non Nix, je n’expliquerai pas comment installer TFS 2008 SP1 sur une machine x64 :)

Posted: lundi 16 mars 2009 16:06 par azra
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

tja a dit :

Merci pour l'article. Personnellement je serai intéressé par un article qui traite le sujet "the best practices" lors de la création de projets (arborescence des projets, builds, configuration de la sécurité, etc.)

A bientôt,

# mars 16, 2009 21:39

Kangoo a dit :

Ben au niveau bonne pratique y'a un bouquin qui existe, en Français, qui aborde plein plein de sujet autour de TFS ! En plus, l'auteur ce livre est aussi l'auteur de ce blog ;)

# mars 17, 2009 00:39

Alexandre Marlot a dit :

Je confirme il s'agit d'un excellent livre :)

# mars 17, 2009 09:37

azra a dit :

@tja: ok, je vais prépare un truc dans ce sens sur la création de Team Project

@Kangoo, Alexandre: *:)*

# mars 17, 2009 22:04

azra a dit :

# mars 17, 2009 22:05

tja a dit :

Merci pour vos réponses.

# mars 18, 2009 17:22
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Office 365: Nettoyage des versions de List Item avant migration depuis SharePoint On Premise vers SharePoint Online par Blog Technique de Romelard Fabrice le 08-08-2017, 15:36

- Office 365: Comment supprimer des éléments de liste SharePoint Online via PowerShell par Blog Technique de Romelard Fabrice le 07-26-2017, 17:09

- Nouveau blog http://bugshunter.net par Blog de Jérémy Jeanson le 07-01-2017, 16:56

- Office 365: Script PowerShell pour assigner des droits Full Control à un groupe défini par Blog Technique de Romelard Fabrice le 04-30-2017, 09:22

- SharePoint 20XX: Script PowerShell pour exporter en CSV toutes les listes d’une ferme pour auditer le contenu avant migration par Blog Technique de Romelard Fabrice le 03-28-2017, 17:53

- Les pièges de l’installation de Visual Studio 2017 par Blog de Jérémy Jeanson le 03-24-2017, 13:05

- UWP or not UWP sur Visual Studio 2015 ? par Blog de Jérémy Jeanson le 03-08-2017, 19:12

- Désinstallation de .net Core RC1 Update 1 ou SDK de Core 1 Preview 2 par Blog de Jérémy Jeanson le 03-07-2017, 19:29

- Office 365: Ajouter un utilisateur ou groupe dans la liste des Site collection Administrator d’un site SharePoint Online via PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-24-2017, 18:52

- Office 365: Comment créer une document library qui utilise les ContentTypeHub avec PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-22-2017, 17:06