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

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.

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.

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 ).

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.
   • Contrôle de version, mieux expliqué

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

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.

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é:

• Implémentation de Team Foundation Server avec une petite équipe de développement
• Bienvenue sur la plate-forme d'intégration TFS!
• Développement d'équipe avec TFS Guide
• Mise en place d'un environnement de développement

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).

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.