TFS: étiquettes vs changesets
J'essaie de proposer les meilleures pratiques en matière d'utilisation du contrôle de source TFS. À l'heure actuelle, chaque fois que nous faisons une construction, nous étiquetons les fichiers qui sont archivés dans le TFS avec le numéro de version. Cette approche est-elle meilleure ou pire que simplement archiver les fichiers et avoir le numéro de version dans les commentaires? Pouvez-vous ensuite utiliser le changeset pour revenir en arrière si nécessaire ou les étiquettes sont-elles encore plus polyvalentes?
Merci!
Ils ont deux objectifs différents: ChangeSet, c’est lorsque les fichiers ont réellement changé et que vous souhaitez conserver un enregistrement permanent de ce changement. Les étiquettes marquent une certaine version des fichiers afin que vous puissiez facilement y revenir. À moins que votre version ne modifie réellement les fichiers sous contrôle de source et que vous souhaitiez enregistrer ces modifications. Vous devriez étiqueter.
En outre, l’étiquetage nécessite beaucoup moins de ressources. Et vous pouvez avoir plusieurs étiquettes sur la même version d'un fichier.
Vous devez étiqueter les versions des fichiers source qui composent votre construction. Si vous utilisez TeamBuild, il le fait automatiquement pour vous. Il combine le nom de votre définition de build, la date et le numéro de build. Donc, vous n'avez rien à faire.
Votre autre option n’est pas très conventionnelle et nécessite beaucoup de travail inutile. Si je le comprends bien, vous devez extraire vos fichiers source lors du processus de construction, puis les restituer avec un numéro de version spécifié dans les commentaires d’archivage. C’est ce qu’Alex a mentionné, exigeant beaucoup de ressources en termes de processus de construction et de référentiel de contrôle de source. De plus, comment obtiendriez-vous les fichiers source d'une version particulière si les informations de version sont incorporées dans les commentaires? Ce sera très difficile et vous devrez vous asseoir et écrire votre propre application qui utilise une API de contrôle de source TFS pour télécharger les fichiers source dans un espace de travail en recherchant le numéro de version dans les commentaires d’archivage. Cela crée une complexité inutile et des maux de tête.
Si vous utilisez plutôt des étiquettes, vous pouvez effectuer une extraction par étiquette dans VS IDE pour télécharger les fichiers source qui composent cette étiquette. Vous pouvez même dire à TeamBuild d'utiliser une étiquette au lieu de télécharger les derniers fichiers source lors de l'automatisation de la construction. De cette façon, vous pouvez facilement créer les versions précédentes de votre application. Avec les étiquettes, vous pouvez également appliquer des ensembles de modifications ultérieurs à une étiquette existante en cas de modification de code en obtenant simplement cette étiquette, puis en obtenant des ensembles de modifications spécifiques, puis en effectuant une étiquette rapide ou en créant une nouvelle étiquette.
L’étiquetage est très puissant, facile à utiliser et fait partie de TFS. Plutôt que de proposer votre solution personnalisée qui nécessite beaucoup d’efforts pour la faire fonctionner et la maintenir, essayez d’utiliser ce qui est déjà disponible.
Actuellement, chaque fois que nous faisons une construction, nous étiquetons les fichiers qui sont archivés dans le TFS avec le numéro de version.
Tu n'as pas besoin de faire ça. TFS peut faire référence à un état de la base de code de nombreuses façons, dont les étiquettes ne font qu'un, mais il en est de même pour les générations et même les ensembles de modifications. Vous pouvez voir les moyens disponibles pour reconstruire un moment particulier en effectuant un Get Specific Version... et en examinant les options du menu déroulant Type:
Changeset
Date
Label
Latest Version
Workspace Version
Changeset vous permet d’obtenir juste après un ensemble de modifications; Date est évident; Label l'est aussi, sauf que les constructions * créent automatiquement des étiquettes (choisissez Label dans cette liste déroulante, puis consultez la boîte de dialogue Find Label).
* Je pense que c'est automatique! Sauf si c'est quelque chose que nous avons spécialement mis en place là où je suis en ce moment ...
StackOverflow ne me laissera pas commenter les réponses ci-dessus, alors j'écris ceci comme une nouvelle "réponse". Je tiens à clarifier certaines des idées fausses énumérées ci-dessus.
Premièrement, utiliser les étiquettes TFVC nécessite PLUS de ressources que d’utiliser des changesets. Beaucoup plus. Les commandes telles que Branch, Merge et Get by Label sont plus lentes. Pour les serveurs d'entreprise dotés de bases de données volumineuses, vous ne souhaitez pas utiliser d'étiquettes.
Deuxièmement, les constructions ne créent pas automatiquement d'étiquettes, bien que les étapes de génération par défaut incluent une étape pour créer une étiquette.
Troisièmement, comme cela a déjà été mentionné, les étiquettes peuvent être déplacées ou supprimées. Elles sont donc beaucoup moins fiables que les ensembles de modifications immuables.
Dans l'ensemble, je vous recommande de ne pas utiliser d'étiquettes. L'alternative la plus simple consiste à ne mémoriser que le numéro de jeu de modifications de vos générations. Ou si vous souhaitez isoler différentes versions, vous devez créer des branches de version.
Les étiquettes conviennent aux petits systèmes, mais pas aux grandes entreprises.