Y at-il quelque chose qui cloche dans notre façon de contrôler les versions?

53

Je travaille avec une équipe de programmeurs en tant qu'analyste d'entreprise. Nous venons de publier la version 2.0 de notre produit et travaillons sur la prochaine version qui sortira dans 3 mois (c'est un logiciel interne). Malheureusement, la version 2.0 présente des problèmes qu’ils ont dû résoudre et nous allons les déployer dans quelques semaines. Le problème est que nous ne souhaitons pas non plus déployer les modifications sur lesquelles nous travaillons et ne sommes pas prévues pour être publiées avant 3 mois.

Les programmeurs ont décidé que le moyen de gérer cela était que seul le code des défauts soit archivé et que le code des nouvelles améliorations soit conservé sur les machines locales du développeur jusqu'à leur exécution. Je vais devoir tester les versions locales de leurs machines car s'ils enregistrent le code et que nous devons installer un autre correctif pour corriger les défauts, nous ne voulons pas inclure ces améliorations pour l'instant. Il existe également le problème suivant: le même fichier de code contient à la fois des correctifs et des améliorations. Ils doivent donc copier le fichier de code localement, puis apporter une modification pour corriger un bogue et le vérifier, puis reprendre le travail sur les améliorations en prenant le copie locale ils ont fait.

Cela semble assez compliqué - existe-t-il une meilleure façon de gérer ce type de scénario? Nous utilisons Team Foundation Server et Visual Studio 2010.

Ryan
la source
113
Feu tes programmeurs.
Bernard
11
Donnez-leur une branche chacun. Appliquer des contrôles quotidiens.
16
@Ryan La seule excuse plausible qu'ils auraient pu avoir serait s'il s'agissait d'un projet hérité sur quelque chose d'ancien comme SourceSafe. Cependant, Team Foundation Server 2010 est une très bonne solution de contrôle de source qui ne devrait pas avoir de problèmes pour gérer plusieurs branches et effectuer des fusions de ces branches dans la branche principale. S'ils ne le savent pas, ils sont obscurément incompétents et devraient être renvoyés. Cependant, il est plus probable qu’ils soient trop paresseux ou apathiques pour se sentir dérangés par les branches et qu’ils fusionnent afin de vous nourrir.
maple_shaft
10
@Jan_V Rien dans SourceSafe n'est facile.
maple_shaft
30
Je ne connais pas bien TFS, mais cette question se lit comme une publicité pour Mercurial ou GiT.
Jim In Texas

Réponses:

77

Ce que nous utilisions, la V2.0, aurait dû être appelé une "branche à l'état stable" (nous avons utilisé Perforce, pas TFS) une fois qu'elle a été publiée. Tous les correctifs pour la v2 auraient été apportés à cette branche, puis propagés dans la branche de développement v3 alors que les fonctionnalités de la v3 étaient également en cours d’exploitation, c’est-à-dire qu’un défaut de la v2 entraînerait également un défaut de la v3.

Avoir des modifications sur les machines du développeur pendant longtemps entraînera probablement un cauchemar d'intégration.

James
la source
6
MS a un livre blanc sur ce sujet (qui traite de façon beaucoup plus détaillée): vsarbranchingguide.codeplex.com/releases/view/38849
Richard
2
Et ils peuvent toujours créer une branche de version dans TFS basée sur la version 2.0 de la date et l'heure de génération.
DaveE
2
J'ai beaucoup partagé
BZink
50

Eh bien, il existe de nombreuses manières de traiter de tels problèmes, généralement couvertes par une balise 'branching' , chacune avec ses propres avantages et inconvénients.

Mais approche choisie par vos développeurs ... Je vais le citer verbalement pour m'assurer que je n'ai pas mal interprété ...

le code ... sera conservé sur les machines locales du développeur jusqu'à ce qu'elles soient terminées ...

... le chemin comme ci-dessus est probablement le seul qui soit totalement, complètement faux!

Pour moi, ce qui est criminel au plus bas, c’est que, pour TFS, il existe un excellent guide facile à comprendre, intitulé Guide de branchement de Microsoft Team Foundation Server - document volumineux et détaillé contenant des recommandations de stratégies de branchement soigneusement adaptées et expliquées pour tous types de projets ( version HTML ici ).

moucheron
la source
6
Sérieusement, les programmeurs doivent lire ce Guide de branchement de Team Foundation Server et ne pas écrire une autre ligne de code tant qu’ils ne l’ont pas compris et créé des branches distinctes pour les corrections de bogues 3.0 dev et 2.0.
Carson63000
@ Carson63000 convient que cela vaut la peine d'être lu, même pour les gars non-TFS (comme moi). La façon dont les gars de Microsoft classent les projets et en particulier les facteurs à prendre en compte lors du choix d’une stratégie de branchement appropriée ne tient pas compte des outils et constitue un excellent sujet de réflexion.
moucher
40
  1. Vos développeurs ont un malentendu fondamental sur l'utilisation du contrôle de version.
  2. Ne discutez pas du "bon" logiciel de contrôle de version. Ce n'est pas le problème.
  3. Chaque modification du code rend le problème plus difficile à résoudre.
  4. QUAND vous décidez tous de faire ce qui s'impose, vous ne pouvez pas continuer à modifier le code pendant que vous corrigez les problèmes. Vous DEVEZ arrêter tout développement et obtenir le code dans le contrôle de version.
  5. Les développeurs doivent ressentir suffisamment la douleur pour au moins s'asseoir et en parler.
  6. Tous les logiciels de contrôle de version prennent en charge les concepts de base:
    • TOUT le code va dans le référentiel de contrôle de version.
    • Tous les fichiers de code ont des numéros de version. Ces numéros s’incrémentent automatiquement lorsque le code est ré-archivé.
    • Une balise marque tous les fichiers de code d'une version (et d'une version) particulière. Ainsi, nous pouvons par exemple étiqueter la version 1 du logiciel.
    • une branche est un "détour" du tronc principal .
      • Toute modification apportée à une branche n'affecte pas le tronc.
      • Vous pouvez éventuellement fusionner les modifications de branche dans le tronc principal à un moment donné.
      • Ainsi, nous pouvons expérimenter sans craindre de gâcher "les bonnes choses".
  7. Vous devez avoir le contrôle de version "acte de foi" comme je l'appelle. FAITES CONFIANCE que le respect des règles de base suivra. L'inexpérience nous fait penser autrement, croyez-moi.
  8. Voici un tutoriel décent. Il est assez général et complet pour ne pas avoir à fouiller beaucoup d’autres sources.

modifier

  • Mettez le contrôle de version sur votre ordinateur de travail.
    • Vous pouvez le faire maintenant avec la coordination de l'équipe
    • Même avec le contrôle de version en équipe, je le recommande vivement.
    • Si votre équipe utilise Git ou Mercurial, vous utilisez un référentiel local indépendant. C'est ainsi que fonctionne le contrôle de version distribuée.
    • Vous pouvez utiliser différents logiciels VC de votre équipe. Notre équipe utilise Subversion, j'utilise Mercurial localement. Les métafichiers du logiciel VC (".svn", ".mg", dossiers cachés) ne sont pas en conflit.

Vous n'agissez pas en tant que référentiel d'équipe de facto. C’est pour la gestion de votre propre travail, les efforts de refactoring, etc., et pour que vous restiez en tant que membre de l’équipe continue de faire évoluer la base de code de FUBAR.

fin éditer

radarbob
la source
3
Nitpick: "Tous les fichiers de code ont des numéros de version. Ces numéros sont incrémentés automatiquement" Certains VCS (par exemple, Subversion, Git) ont des ID de version par référent au lieu de par fichier, et les ID de version ne sont pas nécessairement numériques (Git). Bien sûr, le point fondamental est toujours valable.
Sleske
versioning "par fichier / par repo (sitory)". Oui. C'est une différenciation fondamentale du logiciel VC. J'ai utilisé les deux types - "country AND western" (+1 à quiconque connaît cette référence). J'aime plus le modèle "au repo".
radarbob
13

Ce que vous décrivez est un moyen terrible d’utiliser le contrôle de version. Il aurait dû y avoir une branche créée pour la version 2.0, une balise ou un identifiant. De cette façon, les modifications apportées à cette version peuvent être contenues et de nouveaux développements peuvent continuer.

Cet article peut vous donner quelques idées. C'est écrit avec l' gitesprit, mais il n'y a aucune raison pour que cela ne fonctionne pas mercurialaussi bien. Je me rends compte que vous n'utilisez ni l'un ni l'autre, mais c'est aussi un problème que vous devriez envisager de résoudre.

jdl
la source
9
Quel est le problème avec l'utilisation de TFS?
Bernard
2
Cela dépend de ce que vous essayez d'accomplir. Les avantages et les inconvénients sont un sujet commun sur SO. C'est un bon point de départ. stackoverflow.com/questions/4415127/…
jdl
4
Les systèmes de contrôle de version distribués n'ont pas toujours de sens.
maple_shaft
3
-1: Malgré ce que prétendent les évangélistes, le contrôle de révision distribué n'est pas la réponse à tous les problèmes et ne le résoudrait pas.
mattnz
3
@Ant: Peut-être avez-vous raison, mais dans le contexte de la question initiale, je ne pense pas que le fait de savoir si TFS est utilisé pour le contrôle de source est sans importance. Tant que TFS prend en charge la création de branches, il devrait être utilisé par l'équipe de développement du PO.
Bernard
7

Réponse rapide: l'équipe de développement doit disposer d'une branche de production distincte pour que le déploiement de la base de code V2.0 soit séparé du tronc principal .

Toutes les corrections de bogues doivent d'abord être effectuées dans cette branche, puis testées et déployées dans d'autres branches, afin de maintenir le code synchronisé .

Votre projet doit également avoir plusieurs environnements for health developmenttels que Prod, Staging, QA et Dev (parfois UAT). Ces environnements doivent être configurés avant de passer à la version de production.

Dans l’ensemble, être prêt pour les bogues et les modifications est le moyen de prendre en charge une application publiée.

Comme TFS a été mentionné en tant que contrôle de version, j'ai également compilé une liste d'articles qui seront utiles pour définir un ou plusieurs environnements de développement pour la santé:

EL Yusubov
la source
4

Non, car lorsque vous utilisez un VCS, vous ne faites pas de contrôle de version.

Le concept central du contrôle de version consiste à suivre les différences dans le temps. Vous planifiez d'enregistrer certaines différences, mais pour le moment, la plupart de vos modifications ne sont pas enregistrées.

Comme d'autres l'ont dit, vous devriez utiliser des branches. Une fois cette configuration configurée, vous devriez vérifier toutes les modifications fonctionnelles (c’est-à-dire non pas chaque frappe, mais chaque fois que vous corrigez un bogue, ajoutez une fonctionnalité, supprimez une fonctionnalité ou apportez une autre modification de sorte qu’elle soit toujours construite et fonctionne).

jmoreno
la source
0

Je suis un développeur et on nous donne un code de branche et une base de données différents pour les correctifs de la version actuelle et un autre pour les améliorations et les versions ultérieures consécutives.

Une fois que nos correctifs sont terminés, ils sont fusionnés avec la production et sont déployés, nous obtenons une nouvelle branche pour fonctionner à nouveau avec des améliorations.

De plus, nous suivons une pratique comme si j’avais 10 correctifs pour ma version actuelle

J'écris comme

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

De même pour d'autres correctifs, je le fais simplement pour chaque ligne que je modifie ou ajoute pour la correction. Et juste comparer et commettre. De la même manière, s'ils faisaient en parallèle sur la même branche, ils peuvent utiliser

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+FLa commande et le type //Start Iteration 2, Fix No-1, Branch No-"ABC" de recherche dans la solution complète aide beaucoup à trouver les emplacements exacts, les fichiers dans lesquels le code est modifié et prendre du code frais, seule cette partie peut être utilisée pour la validation.

Shilpa
la source