Comment gérez-vous le fait de gérer et maintenir plusieurs version en parallèle ?

[Argorate]

Bonjour,

je viens a vous aujourd'hui pour savoir si certains rencontrent les mêmes difficultés que moi et surtout s'ils opèrent différemment face à celle-ci.

J'ai une version X de mon jeu actuellement ne ligne, et j'en prépare une nouvelle.
Le problème est que je dois du coup posséder en local les fichiers de la version en ligne et les fichiers de la nouvelle version (je dois posséder les deux versions de manière distincte de façon a pas écraser le travail, et également que la partie déjà coder de la nouvelle version ne soit pas mise en ligne).
Jusque là logique et relativement peu problématique, cependant, lorsque je dois faire des correctif ou petit ajout sur la version en ligne, je dois immédiatement et systématiquement faire la même modif sur les fichiers de la nouvelles versions (fichier qui du coup non plus forcement les meme taille ni les numéros de ligne qui corresponde etc), ce qui fait que chaque changement me fait double de travail (alors même si c'est parfois que des copier coller), faut a chaque fois y penser, ça prend du temps, et on peu se planté...

Donc ma question est comment faites vous? comment gérer vous la création d'une nouvelle version tout en maintenant celle en ligne? Conseils? Astuces?

j'écoute vos expériences

Merci.

[niahoo]

tu bosses à l'envers on dirait.

La logique voudrait que tu améliores la version en développement, et que quand elle est stable tu mettes à jour la version en ligne.
Par conséquent tu n'aurais qu'une seule version majeure de ton jeu. or la tu bosses avec deux.

Donc rapidement passes ton jeu sur la nouvelle mouture.

[Arius Vistoon]

Pour ma part je crée des branches sous SVN
Le trunck c est ma version de développement et les différentes branches les version en prod des différent client qui évolue potentiellement différemment de la version up to date avec des fonctionnalité personnalise mais devant of course être corrige des même bug ou de fonctionnalité identique ou similaire. Donc bien évidemment tu ne travaille pas a l envers c est tour a fait normal comme situation et c est tout a fait normal de ne vouloir coder 10 fois la même chose
Dans ce cas il faut faire un merge des modif sur tel ou tel branche ou du trunk vers ou venant de tel ou tel branches ou trunk la version de développement pouvant ne pas être la derniere version même si fonctionnellement parlant ce n est jamais le cad

[zeppelin]

Comme niahoo, je pense que c'est mieux de travailler dans l'optique des "patchs". Donc une seule version que tu développe en local, et toute les semaines par exemple tu applique un patch avec les changements / corrections.

[niahoo]

...

bien sûr ce que tu dis est censé mais de la façon dont il parle je devine qu'in n'utilise pas un systeme de controle de versions. En tous cas il n'en utilse pas les fonctions de gestions de branches.

Lui il corrige les bugs sur sa version prod puis veut refaire les mêmes corrections sur le code de dev.

[srm]

Et bien par moment tu es obligé, admettons que tu ajoutes des nouvelles fonctions sur la futur release et paff, en prod tu découvres un bug justement autour de ce code, tu dois modifier à la fois ta production et ta dev.

Sous git je remerge mes changements de la prod (préprod en fait) à la dev.

[Sephi-Chan]

C'est là que tu payes l'amateurisme et la non-utilisation d'un outil de versionnement.

Au boulot, on utilise juste Git (généralement avec Git Flow) pour le versionnement et Capistrano pour le déploiement.
Du coup, on suit ce modèle de branchement :

• On développe sur la branche nommée develop, puis pour chaque fonctionnalité (inventaire, carte du monde, etc.), on crée un branche dédiée. Quand la fonctionnalité est terminée, on la merge sur develop.
  
• Quand la branche de développement atteint une avancé qui nous convient, on crée une branche de release et on y merge develop. On met ensuite ça en préproduction (certains disent staging).
  
• Pour tout ce qui est correction de bugs, on peut les corriger sur les branches de release et on les merge tout de suite après dans develop.
  
• Quand la release est complètement opérationnelle, on la merge dans master et on tag le commit et on déploie en production.
  
• Quand il faut corriger un bug critique, on crée une branche de hotfix depuis master, on règle le bug et on merge cette correction dans la branche develop.
  

Et voilà, avec ça tu peux développer sereinement, ça marche bien. Ça demande en revanche pas mal de rigueur avant de devenir une habitude.

[Argorate]

niahoo : je ne bosse pas à l'envers, je fais se que tu dis, mais imaginez que vous devez résoudre un bug de manière ponctuel sur le version prod. Vous voulez résoudre rapidement ce bug sans faire attendre les utilisateurs d'avoir fini de coder la nouvelle version qui apporterais le correctif. Donc il faut corriger le bug sans mettre toutes les mise a jour de la nouvelle version que vous avez en local. Sachant que de grosse modif de code peuvent être apporté dans la nouvelle version, il faut donc nécessairement avoir les fichiers "new version" et "current version", mais même avec ton outil de version sephi, je ne vois pas quel autre solution tu as que de dupliquer le correctif, à la fois sur le code de la nouvelle version et sur celui en prod, non?

D'après ton schéma sephi, tu as en prod que les versions les une après les autres, hors moi je veux justement toucher à la version en prod avant la mise en ligne d'une nouvelle version. Pour les modif/corectifs qui ne peuvent attendre, pas d'autres choix... et c'est ce cas particulier qui m'embête donc...

[Sephi-Chan]

Git permet tout ça, c'est fait pour. Ça a été développé pour versionner le développement du Kernel de Linux, qui est un endroit autrement plus hostile qu'une application Web.

Quand il faut corriger un bug critique qui est sur la version de production (un hotfix) :

• Tu crées une branche pour ce hotfix à partir de la branche master (la production) ;
  
• Tu effectues la correction. Normalement ce sont des modifications assez légères ;
  
• Tu merge la branche de hotfix dans la branche develop et dans la branche master.
  

Et voilà, ça roule.

[Argorate]

Non mais je suis d'accord, mais ton étape "Tu merge la branche de hotfix dans la branche develop et dans la branche master." représenté par des flèches des deux cotés de la branche "hotfix" sur ton schéma veux bien dire que tu copies le correctif à deux endroits très différent, donc tu es bien obligé d'aller chercher dans ta branche develop le bon endroit où mettre le corectif.