Discussion :

[monsieurluge]

Hello,


J'aimerais avoir quelques avis sur l'organisation d'un projet, pour éviter un maximum de problèmes lorsque deux équipes distinctes travaillent sur le même code.

En effet, nous avons actuellement une équipe qui travaille sur le la correction à long terme et des évolutions techniques, et l'autre qui travaille sur de petites évolutions en fonction des besoins métier.
Le gros point noir de notre fonctionnement est la période de VNR (pour éviter toute régression) que la première équipe doit effectuer systématiquement avant toute mise en prod.

La structure actuelle de notre repository :
|--- trunk

|--- correctifProd

|--- branches/mep15062015

|--- branches/mep15062015-equipe1

|--- correctif1

|--- correctif2

|--- evol

|--- branches/mep15062015-equipe2

|--- evol1

|--- evol2

|--- evol3

Les gros problèmes que cette structure engendre :
- Si une équipe livre en retard (sur la branche commune, donc), ça ralentit tout le monde
- Tant que la VNR n'est pas terminée sur la branche commune, les devs ne sont pas redescendus sur le trunk, donc l'équipe 2 ne peux pas démarrer de nouvelle branche depuis le trunk pour continuer de développer des évolutions
- Le merge des branches des deux équipes est très complexe à gérer, surtout que souvent les deux équipes doivent finir à peu près en même temps leurs développements pour la mise en prod à une date donnée

Je pensais proposer les changements suivants, basés sur le fait que le trunk n'est plus une image de la prod (les tags le sont, alors pourquoi se faire chier ?)
- Faire sauter un niveau, à savoir la branche "mep15062015"
- Chaque équipe, une fois ses développements terminés, fusionne avec le trunk
- la VNR s'effectue depuis le trunk
- Chaque équipe peut ainsi démarrer une nouvelle branche depuis le trunk pour continuer des évolutions
- Un tag est créé depuis le trunk quand la VNR est ok
- Toute correction de prod est effectuée depuis le dernier tag, et reprise sur le trunk

Qu'en pensez-vous ?

Autre question : si le développement d'une évolution prévue par exemple pour la mise en prod de fin octobre n'est pas terminé, que cette évolution est reportée dans la mise en prod suivante, comment déplacer "proprement" ce développement qui dépend de la branche qui a été redescendue sur le trunk (via reintegrate) vers la branche dédiée à la future mise en prod ?
|--- trunk

|--- branches/mep15062015-equipe2

|--- evol1

|--- evol2 pas terminée

|--- evol3

vers

|--- branches/mep02082015-equipe2

|--- evol2 reportée

Je ne suis peut-être pas bien clair, donc n'hésitez pas à me demander de reformuler.
Et, merci d'avance pour qui aura l'envie de répondre ^^

[kolodz]

Bonjour,

Le travail multi branche sur SVN a toujours été problématique. Mon conseil personnelle est de passé le plus rapidemenet possible un gestionnaire de source un peu plus moderne (Git, Mercurial)

Pour ce qui est de la gestion des branches en elle-même, je te propose de lire un article très intéressant sur le sujet : A successful Git branching model

Il y a quelques grandes lignes :

• La production est totalement séparé du développement.
• Il y a une branche spécifique pour la recette.
• Chaque développement dispose de sa propre branche.
• On intégré un développement dans la branche de développement qu'une fois celui-ci "finit" au niveau du développement. (Compile, passe les TU, en gros stable stable)

Avec cette disposition, il est à tout moment possible de repartir de la branche de développement pour un nouveau développement.

Cette façon de procédé n'est pas réellement possible avec SVN, car les merge de branche sont impossible à faire proprement.

J'ai l'impression que dans l'idée, tu présente la même chose, mais avec les contraintes de SVN.

Différence avec Git :
En général quand des modifications sont poussé sur une branche principal tel que master ou dev. Les personnes se rebase dessus avant de livrer leur fonctionnalité. Il arrive même que le développeur se rebase plusieurs fois (genre tout les matins) avant de livrer son développement pour ne pas avoir le "mega merge" à faire à la fin.

Cordialement,
Patrick Kolodziejcyzk.

Note : Il est totalement possible de reprendre un dépôt SVN via Git avec l'ensemble de son historique. En général, si les développeurs ne savent pas utilisée git, une présentation et une fiche mémo est en général suffisant. Et l'installation de git n'est pas super long.

[monsieurluge]

J'avoue que si on avait la possibilité de mettre SVN à la benne et de passer sur GIT tous nos soucis actuels seraient de l'histoire ancienne.
Je vais tenter de mettre un coup de pression pour adopter ce changement, mais étant donné l'inertie de la boîte pour laquelle je travaille je pense que ça va être compliqué.

Il me semble que j'ai déjà parcouru le lien que tu as indiqué. J'ai pas mal écumé les forums et sites divers pour trouver une solution à peu près convenable... et à chaque fois, ça se trouvait sur GIT ^^

[kolodz]

En fonction de "l'inertie" dans ta boite, il est toujours possible de faire adopter Git l'une ou au deux équipes et de ne conserver SVN que pour la partie visible de l'extérieur.
Un collègue avait fait cela sur un projet où il n'avait pas la main. Afin d'éviter les contraintes de SVN, tout ses développements était sous Git et transférait les modifications sur SVN le moment où on lui demandait. Et le jour, où il a eu la main dessus SVN est passé à la benne.
Si tu as un peu d'accroche sur l'une des équipes, tu peux faire un passage à git "en projet pilote" (officiel ou non). Mais, ça c'est de la gestion de ressource humaine / politique et non de la gestion de source

Cordialement,
Patrick Kolodziejczyk.

[monsieurluge]

Bon, on n'a pas trouvé de solution valable. Tant pis.

Mais une lumière d'espoir vient de s'allumer au loin car ils entrevoient de passer les projets sous GIT. Enfin !