Discussion :

[drKzs]

Bonjour,

J'ai toujours un doute dans ma gestion de conf, j'ai lu quelques posts dessus, mais je n'ai toujours pas la réponse qui me convainc... Ouvrons un petit débat

Bon, je passe outre les outils, actuellement j'utilise SVN, mais c'est une discussion générale sur l'organisation des branches (même si certains pratiques sont peut-être plus adaptées à certains outils, à voir plus tard)

Soit un petit projet.

Voilà actuellement comment je procède:

trunk (mon code stable)
|-> devel (une branche pour réunir les développements)
|----> devel_bug1
|----> devel_ajoutfonction_de_rodriguez
|----> devel_...
|-> release1 (par ex v1.0 du 01/01/2014 - correspond à un tag)
|-> demo1 (parx ex demo du 15/12/2013 - correspond à un tag)

L'avantage que j'y vois:
- la branche devel fait un peu office d'intégration, toutes ses branches dérivées (devel_bug1, devel_ajoutfonction_de_rodriguez, ...) sont mergées dedans
- on commit les sous-dev dans devel pour que ses copains intègrent les modifs, et on synchronise son sous-devel à partir de devel : le trunk ne bouge pas encore
- quand tous les developpements de chacun sont op, et fonctionnent bien ensemble dans devel, on peu merger dans le trunk => le trunk est (relativement ) stable

Les problèmes:
- trop de merge : il faut merger les sous-devel dans devel, puis devel dans trunk
- devel et trunk peuvent être très désynchronisé pendant un moment, le merge peut souvent être laborieux (avec svn 7 en tout cas)

Je crois savoir que normalement, on branche directement à partir du trunk. Comme ça il n'y a qu'un niveau de merge.

Mais ça veut dire que pour ques ses potes se synchronisent sur les fix/improve de chacun, il faut comitter dans trunk directement => à ce moment le trunk n'est plus vraiment stable
=> ce à quoi on peut me répondre, la version stable est le tag de la dernière release
=> ce à quoi je pourrai répondre, et si on fait pas soucvent de release ?

Merci pour vos avis/eclaircissement/pratiques

[Drizzt [Drone38]]

De mon point de vue il faut éviter le plus possible les merges.
C'est une source d'erreur et d'autant plus si tu merges en fin de release, avec donc peut de temps devant toi pour tout bien vérifier.

Donc pour moi oui il faut commiter dans le trunk, mais le développeur à le devoir de commiter quelque chose de stable.
Pour cela l'intégration continue est ton amie. Si un commit est foireux (au sens regression fonctionnelle, ça marche aussi au sens technique mais la le développeur n'est pas censé commiter un truc qui plante ou compile pas), tu le verras tout de suite.

En pratique l'état de ton trunk en cours de release n'est pas génant en soit. Si tu ne fais pas beaucoup de release rien ne t'empeche de faire des releases fictives intermédiaires si vraiment tu veux avoir des points de retour "stables". (Sur ce point ta solution n'apporte pas de plus d'ailleurs)

Il ne faut pas voir le trunk comme toujours dans un état livrable en production. Ce sont justement les tags qui te permettent de garantir un état stable à un moment donné. Ce qui se passe entre deux tags, ça n'a pas d'importance.

[drKzs]

Donc pour moi oui il faut commiter dans le trunk, mais le développeur à le devoir de commiter quelque chose de stable.
Pour cela l'intégration continue est ton amie. Si un commit est foireux (au sens regression fonctionnelle, ça marche aussi au sens technique mais la le développeur n'est pas censé commiter un truc qui plante ou compile pas), tu le verras tout de suite.

Oui ça me parait juste... Sauf que, peut-etre un cas qui nous est propre qu'à nous, mais l'intégration continue passe souvent, faute de moyens/temps donné, à la trappe, à notre grand damn, mais c'est une réalité :/

En pratique l'état de ton trunk en cours de release n'est pas génant en soit. Si tu ne fais pas beaucoup de release rien ne t'empeche de faire des releases fictives intermédiaires si vraiment tu veux avoir des points de retour "stables". (Sur ce point ta solution n'apporte pas de plus d'ailleurs)

Disons qu'on ne commit dans le trunk qu'une version testée intégralement sur la devel, donc on peut toujours partir du trunk si on nous demande une version stable

Si tu ne fais pas beaucoup de release rien ne t'empeche de faire des releases fictives intermédiaires si vraiment tu veux avoir des points de retour "stables". (Sur ce point ta solution n'apporte pas de plus d'ailleurs)
Il ne faut pas voir le trunk comme toujours dans un état livrable en production. Ce sont justement les tags qui te permettent de garantir un état stable à un moment donné. Ce qui se passe entre deux tags, ça n'a pas d'importance.

Oui ça me semble de bon sens... en revanche j'imagine qu'il faut se forcer dans ce cas à nettoyer qq tags "stables" de tps en tps, sinon on en a plein (sous svn le tag est une branche).


En tout cas merci pour ce premier retour

[tcomz]

Je pense que même s'il y a des bonnes pratiques svn, elles répondent avant tout à un besoin. Si ton besoin est simple, je te conseil d'avoir une organisation simple.

Personnellement j'organise mes dépôts de la façon suivante (on retrouvera certains points communs avec ton organisation initiale).

Je mets en place une branche par horizon de livraison. C'est à dire qu'une branche a un but, un objectif : "Développer la version 1.2.23 de mon application" par exemple.

Une question qui se pose est "ai-je besoin de créer des branches pour chaque développements avant de les merger sur ma branche de dev" ? La réponse à cette question est intrasèquement liées à une autre question : "as tu besoin de faire des développements parallèles ?" Si oui, il est effectivement préférable de travailler sur une autre branche et de merger avec ta branche principale, si non je ne suis pas convaincu que cela apporte une véritable valeur à ton projet.

Quand j'atteins une version stable que je désire livrer, je créé un tag comprenant la date & la version.

Là dessus, on me dit souvent "et tu fais quoi du trunk" ? Ton trunk peut être ce que tu veux. Il est avant tout important que tu choisisses comment tu t'organises et pourquoi tu fais ce choix. C'est pas important d'avoir raison, c'est plus important de comprendre ce qui nous amène à une situation.

Personnellement, j'aime bien avoir une image de la prod sur mon trunk. C'est à dire que parmis tous les tags de toutes mes livraisons, mon trunk correspond au tag qui est actuellement en production. Mais je ne peux faire ça que parce que je ne fais aucun développement sur mon trunk.

Ce que j'essaye de dire, c'est que tout dépend de la volumétrie de ton projet et de l'équipe, de ses besoins en terme de développement parallèle pour une même version, et de ses besoins de développer en parallèle plusieurs versions.

Tu es tout seul et c'est un projet pour le fun ? Alors prend un trunk et développe dessus sans te poser plus de question.
Si tu veux être plus sérieux, alors crée des branches pour les développements des différents modules.
Tu as besoin de développement parallèles ? alors créé des branches depuis ta branche de dev (ou ton trunk) pour éviter les conflits.
Tu as besoin de développer des versions en parallèles ? Alors le trunk ne peux plus être ta branche de développement. Il faut le décentralisé et avoir une branche de dev principal pour la V1X et une pour la V2Y (avec un ancêtre commun).

J'ai l'impression que j'aurais être plus concis dans ma réponse, mais bon ^^

Bon courage

[Marco46]

Bon, je passe outre les outils, actuellement j'utilise SVN, mais c'est une discussion générale sur l'organisation des branches (même si certains pratiques sont peut-être plus adaptées à certains outils, à voir plus tard)

Justement le workflow que tu proposes est très bien adapté à GIT et il est difficile à mettre en oeuvre avec SVN. Le workflow dépend avant tout du gestionnaire de source que tu vas utiliser. Si tu peux utiliser GIT, il n'y a pas à hésiter, il est plus moderne, plus rapide, plus flexible. Il a en revanche un cout de formation plus élevé que SVN.