Discussion :

[fufurax]

Bonjour à tous,

J'ai un projet sous TFS avec GIT comme gestionnaire de code source.

Je souhaite déployer la gestion des branches sur ce projet. Techniquement, je sais faire. Par contre, niveau organisationnel...pas vraiment :p

Le cycle de vie est très simple. Mon idée est d'avoir une branche par version de binaires "déployés".

--> Trunk (ma prod)
---> pre-prod
---->Recette (UAT)
-----> Dev (potentiellement plusieurs)

1. L'équipe travaille en Dev sur une fonctionnalité. Ils font les checkin sur la branche de Dev à la fin du dev de la fonctionnalité.
2. Le Chef de projet merge sur la branche recette et génère les binaires sur le serveur de recette.
3. L’équipe de recette valide.
> OK : je merge en pre-prod
> NOK : On fait les modifs sur le Dev et je re-merge en recette pour revalidation ? ou je fais les modifs sur la recette et je les merge en Dev ?
4. L'équipe de validation pre-prod valide
> OK : je pousse en prod
> NOK : Idem que sur la recette. Je fais les modifs ou ?

Autre cas : En prod, j'ai un gros bug qui me bloque 1000 personnes. Je dois repasser toutes mes branches ? ou l'urgence me donne des passes droits :p

Ma question est donc. En cas de bug, sur quelle branche doit on faire les modifications dans les règles de l'art.

Mon mode de gestion vous semble t'il cohérent ou je suis

Merci pour votre aide

[Philippe Bastiani]

V'là un flux à la SVN !

Premier point : rien ne d'interdit d'avoir plusieurs depôts dédiés pour ton projet !

Deuxième point : git encorage le travail sur branches... A savoir, tu ouvres une branche quand tu en as besoin.

Je t'encourage à t'inpirer de (ou utiliser) git-flow.
Par exemple pour un flux simple avec 4 domaines (prod/dev/integration/hotfix):
- Ta master sera ta prod avec des tag de version
- A partir de ta master et de la version prod souhaitée tu ouvres X branches de dev avec une branche de dev principale.
- Pour l'intégration (i.e. création d'une release), tu crées une nouvelle branche depuis ta branche de dev... branche que tu mergera sur master (ta livraison finale avec tag) et ta branche de dev principale ! Tu peux alors détruire ta branche d'intégration qui n'a plus de valeur ajoutée.
- Pour les hotfix tu branches depuis la master et la release concernée.... puis, tu merge ta branche hotfix sur ta master et ta branche de dev.

a+
Philippe

[fufurax]

Bonjour et merci pour ta réponse.

Quelques points sont assez obscure. Je pense qu'en fait, je pèche sur la sémantique

Ma 1ere indication n'est pas juste. Le moteur utilisé est celui de TFS (Team Foundation Version Control) et pas GIT.

V'là un flux à la SVN !

Comprends pas la remarque

Aurais tu un schéma explicatif pour la gestion que tu décris ?

[Philippe Bastiani]

Bonjour et merci pour ta réponse.
Comprends pas la remarque

Tu semblais indiquer 4 branches assez rigides en //.

Avec git, la façon de travailler est de créer des branche lorsque tu en as besoin.
Par exemple
- tu crées une branche nouvelle version de dev depuis une version prod
- tu crées tes branches d'intégration lorsque tu as besoin de faire ta release depuis ton dev
- tu crées tes branches de hotfix depuis ta prod
- etc
Après, tTu merges tes branches...; et, tu peux détruire si tu le souhaite les branches qui n'ont plus de valeur ajoutée.
Dans tous les cas tu peux crééer un branche depuis n'importe quel commit...

Aurais tu un schéma explicatif pour la gestion que tu décris ?

Git-flow est une extension de git. Voir ici et ici ou ici pour la présentation initiale...

a+
Philippe

[fufurax]

OK, merci pour ton aide.

Je pense qu'en effet, mon modèle était trop statique/rigide dans mon esprit.