TFS 2012: Gestion des droits de vos projets d’équipe
La gestion des droits dans Team Foundation Server 2012 à été grandement simplifiée par rapport à la version 2010. Cela est d’autant plus le cas dans le cadre de projet Agiles avec l’apparition de la notion d’équipe.
Groupes de sécurité et gestion des droits dans TFS 2012
Lors de la création de votre projet, le compte utilisateur utilisé pour créer le projet sur TFS dispose automatiquement des rôles administrateur du projet et est également le premier membre de l’équipe. Basiquement, on ajoutera simplement des membres à notre équipe et tout fonctionne.
Cependant, il est possible très simplement de modifier avec précision la gestion des droits d’accès au projet depuis l’onglet Security de l’interface web d’administration du projet d’équipe.
Les niveaux de droits proposés par TFS sont gérés, au niveau de chaque projet, avec les groupes suivants:
- Team Project Member: Il s’agit des membres de l’équipe du projet: ils disposent des rôles contributor et builder
- Build Administrators : groupe de sécurité prévu pour les membres chargés de la création, modification et suppression de builds mais aussi de la gestion des builds planifiée et terminées.
- Contributors : groupe de sécurité disposant des droits de modification du code sources et des tests et d’accès aux information de projet tels que les work items.
- Project Administrators: Administrateurs du projet qui disposent de tous les droits jusqu’à la modification du projet
- Readers : personnes non actives dans le projet disposant uniquement des droits de lecture aux information du projet ainsi que les resultat de test.

Ces groupes propose une base pour la répartition des droit au sein d’une équipe mais il est possible de modifier les niveaux de droits de tous ces groupes hormis pour les Project Administrators qui disposeront toujours de tous les droits. De plus, il est également possible de créer un nouveau groupe afin de gérer un nouveau type d’utilisateur. Par exemple on créera un groupe Testers disposant uniquement de droits de création et modification des tests et accès aux données du projet.
Cas d’une équipe unique par projet
Dans le cas d’un projet avec une seule équipe de développement, il suffit d’ajouter les membres à l’équipe du projet depuis Team Explorer, ou le Team Web Access, pour que ceux-ci dispose des droits d’accès et de contribution au projet. Par défaut les membres de l’équipe disposeront de tous les droits, hors suppression et modification au niveau projet, leur permettant ainsi de pouvoir tout (voir trop) faire.
Afin d’en affiner la gestion, il suffit de passer par l’onglet Security de l’interface d’administration du projet.
Cas d’équipes multiples par projet
Dans le cas ou l’on souhaites en revanche impliquer plusieurs équipes distinctes sur un même projet, il devient nécessaire pour des question d’organisation mais aussi de sécurité de pouvoir délimiter le périmètre d’action de nos équipe.
Prenons pour exemple un projet impliquant deux équipes: Equipe “Team Work” et Equipe B.
L’équipe “Team Work” est leader du projet doit par conséquent avoir un accès total à l’ensemble des éléments du backlog, des work items, mais aussi du contrôle de code source.
L’équipe B quant à elle ne devra intervenir que ponctuellement sur le projet et l’on souhaites par conséquent limiter les informations auxquelles ses membre pourront accéder.
Il faut donc créer deux équipes distinctes dans le projet d’équipe. Pour pouvoir compartimenter les informations, l’utilisation de deux Zones (Work Item Area) distinctes permet la séparation fonctionnelle des tâches, et permet d'offrir à chaque équipe un portail d’équipe entièrement personnalisé.
Création des équipes
Comme on l’a vu, une équipe existe déjà à la création du projet dans TFS mais l’on souhaites en créer de nouvelles. Depuis le site d’équipe du projet, il faut se rendre dans l’interface d’administration de celui-ci avec un compte disposant des droits administrateur. Pour rappel, celle-ci est disponible depuis le site d’équipe ou depuis la rubrique Settings du Team Explorer, en étant connecté à un compte disposant des droits d’administration sur le projet.
Dans l’onglet Overview de l’interface web d’administration du projet d’équipe, il est possible d’ajouter une nouvelle équipe à celle existante.

La création d’une nouvelle équipe entraine automatiquement la création d’une nouvelle zone, sous-zone de la principale, qui sert de zone par défaut pour la nouvelle équipe. De par la relation parent-enfant qui lie les deux zone les membres de l’équipe travaillant sur la zone principale, disposent par défaut des accès à la zone enfant.
Il est également possible de créer d’autre zone et de changer la zone par défaut de chaque équipe afin d’affiner encore l’administration.
Gestion des zones
Dans l’onglet Area de l’interface d’administration, il est possible de définir une hiérarchie de zones afin de faciliter le classement des éléments de travail dedans et ainsi faciliter la gestion de la visibilité de ceux-ci par nos équipes.
Ainsi la Team Leader “Team Work” dispose d’un accès à la zone Team Work et tout ses enfants (et donc la zone Team B également). L’équipe B quand à elle ne dispose que d’un accès à la zone Team B et donc pas aux éléments de l’équipe leader.

Création des branches
La création de deux branches de développement distinctes dans le contrôle de code sources est également envisageable pour compartimenter le travail des deux équipes. Il est possible d’en délimiter l’accès dans la gestion des droits d’accès à celles-ci. On définira par exemple la branche TeamWork comme branche mère de la branche TeamB. Il sera alors possible à tout moment d’effectuer des merge entre les version des deux équipes.
La gestion des droits sur les branche s’effectue depuis le Team Explorer connecté à notre projet d’équipe. Lorsque l’on dispose de nos branches dans TFS, un clic droit sur l’une d’elle puis Advanced>Security permet de définir les droits d’accès à la branche.

La création de nouvelles branches s’exécutent depuis le contrôleur de code source dans Team Explorer. La création et la gestion des branches dans TFS est très étendue et de nombreuses ressources sont disponibles sur le sujet. Ce n’est pas le sujet de ce billet et je ne vais donc pas m’étendre la dessus.
Cependant, de nombreuses ressources sont disponible sur ce sujet et notamment sur la MSDN que je vous invite vivement à consulter si ce n’est pas le cas.
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 :