Question
Si j'ai créé une étiquette dans TFS en l'attribuant à plusieurs fichiers, mes collègues ne peuvent pas modifier les versions des fichiers (ni en ajouter d'autres) à cette étiquette. Nous avons cette erreur:
TF14077: The owner of a label cannot be changed.
À la recherche du problème, j’ai trouvé cet article , qui indique:
Il est possible qu'un utilisateur soit autorisé à manipuler une étiquette partagée dans le dossier de développement mais seulement manipuler les étiquettes qu'ils possèdent dans un dossier de production. (c'est moi qui souligne)
Malgré tous mes efforts, je ne trouve aucune référence aux "étiquettes partagées". Autant que je sache, une étiquette doit avoir un propriétaire.
FWIW, ce que j'essaie de faire est d’utiliser un "flottant" label afin que les développeurs puissent indiquer que leur code est prêt à faire partie de la construction en le taggant avec une étiquette particulière. Ensuite, le processus de construction aurait juste besoin de tout obtenir avec cette étiquette, et d'obtenir automatiquement les éléments les plus récents qui sont réellement prêts à être construits, en ignorant les versions antérieures ainsi que les éléments plus récents qui ne sont pas prêts pour le prime time.
Mise à jour: Je suppose que si je ne peux pas créer une étiquette vraiment partagée, je peux au moins donner aux utilisateurs le droit de modifier les étiquettes créées par leurs collègues. C'est assez explicitement supporté. Les utilisateurs habituels Contributor n'ont pas ce droit, mais selon MSDN (voir l'article Autorisations de Team Foundation Server , sous Autorisations de contrôle de la source ), il peut être accordé via l'autorisation LabelOther :
Les autorisations de contrôle de source sont spécifique aux fichiers de code source et Dossiers. Vous pouvez définir ces autorisations en faisant un clic droit sur le dossier ou le fichier dans l'Explorateur de contrôles source, en cliquant sur Propriétés, et sur l'onglet Sécurité, sélectionner l'utilisateur ou le groupe pour lequel vous souhaitez modifier les autorisations, et puis éditer les permissions listées dans Autorisations Vous pouvez définir ces autorisations en utilisant le tf utilitaire de ligne de commande pour la source contrôle.
...
Administrer les étiquettes | tf: LabelOther | Les utilisateurs disposant de cette autorisation peuvent modifier ou supprimer les étiquettes créées par un autre utilisateur.
J'ai donc attribué ce droit au groupe de domaines contenant tous les développeurs, comme suggéré ci-dessus. Je peux vérifier qu'il est défini à l'aide de la commande autorisation tf :
tf permission /group:"CORP\Web Team"
et le résultat est celui attendu (j'ai également attribué une étiquette, juste pour le fun)
===============================================================================
Server item: $/Test1/TeamBuildTypes (Inherit: Yes)
Identity: CORP\Web Team
Allow:
Deny:
Allow (Inherited): Label, LabelOther
Deny (Inherited):
Pourtant, mon utilisateur de test n'est toujours pas autorisé à modifier l'étiquette que j'ai créée.
La solution 2
Je n'ai jamais réussi à faire fonctionner ce travail avec des étiquettes. Au lieu de cela, nous avons mis au point un processus complètement différent en utilisant la création de branches, ce que je recommande maintenant vivement à toute personne qui lit ceci.
Nous avons mis en place un schéma de branchement de manière à créer une branche de développement générale; à partir de là, chaque développeur a sa propre branche avec laquelle il peut faire ce qu'il veut, et il y a une branche Production.
- Les développeurs font leur "sale" " travaillent dans leur branche privée sans craindre de libérer accidentellement des choses, ni même d'interférer avec leurs collègues.
- Lorsqu'ils ont quelque chose de prêt à intégrer, ils fusionnent les modifications dans la branche de développement. Nous y construisons en continu et testons les résultats.
- Lorsqu'une version intégrée est entièrement testée et prête à être déployée, les modifications sont fusionnées dans la branche Production. Ceci est construit et déployé.
J'avais dit que je voulais
ce que j'essaie de faire est d'employer un " flottant " étiquette afin que les développeurs peut indiquer que leur code est prêt faire partie de la construction en marquant avec une étiquette particulière.
Le schéma que j'ai décrit ci-dessus répond pleinement à cet objectif, et plus encore.
Autres conseils
Les ensembles de tablettes seraient-ils une meilleure solution pour ce que vous faites? IIRC dispose d’une API assez riche pour travailler avec des ensembles de tablettes, tels que leur validation dans le cadre d’un processus de construction (ou autre).
J'ai trouvé les étiquettes dans TFS très limitées lorsque je les utilisais.