Migration SVN vers GIT - architecture projet GIT

Bonjour à tous,

Je vais essayer de présenter rapidement ma réflexion et mes interrogations.

Nous avons un projet utilisant actuellement SVN.
Ce projet est livré chez trois clients : X, Y, Z. Et nous avons une beta avec tout nos devs recents et R&D.
X est en V6 avec sa recette, pre-pro et prod.
Y et Z sont en version V7. Chacun a sa recette, pre-pro et prod.
Beta correspondant à trunk.

Nous souhaitons donc migrer SVN sur GIT et correctement architecturer et utiliser GIT pour notre besoin.
Nous ajoutons régulièrement des features sur la V6 (par exemple) et reportons sur l'ensemble des versions supérieurs, idem lors de la détection d'un incident.

Quels seraient selon vous l'architecture à mettre en place ? Une Version = une branche ?

Nous envisageons d'utiliser la sur-couche git-flow.

Merci d'avance pour votre retour et en espérant avoir été clair.
Cordialement,
Seb

Si je résume vous avez un logiciel qui a "versions" V6 et V7. V6 peut très bien incorporer des features qui n'existent pas dans V7 tant que celles-ci n'ont pas été reportées.

Deux questions fondamentales en passant :

1/ Existe-t-il des features de V6 qui n'existent jamais dans V7 ?
2/ Existe-t-il des features de V7 que le client ayant déployé V6 ne voudra jamais avoir ?

Si la réponse à une seule de ces questions est oui, alors vous n'avez pas 2 versions mais 2 lignes de développement c'est à dire 2 branches parallèles qui parfois partagent des points communs et parfois ont des features exclusives.

Ces deux lignes de développement doivent chacune avoir leur propre numéro de version indépendant.

Vous avez besoin d'un environnement de recette pour V6 et d'un autre pour V7 (le doublon sur le 2ème client est inutile). Les données de recettes doivent être des données de test qui peuvent être extraites d'un client ou forgées par vous. En revanche il doit bien y avoir un environnement de pre-prod contenant un backup des données du client correspondant pour chaque client en question.

Vous ne pouvez pas utiliser le Git Flow dans ce cas de figure, il ne sait gérer qu'une seule ligne de développement (une seule branche develop). Vous pouvez toujours essayer de faire 2 branches develop en faisant par exemple develop-V6 et develop-V7 mais vous allez très rapidement taper plusieurs murs, en particulier sur les git merge.

Je vous conseille de faire donc 2 branches de développement (et d'éviter de suivre Git Flow à la lettre, le trunk based development serait adapté mais c'est hors de portée des débutants avec Git) et de git cherry-pick de l'une vers l'autre les features qui doivent aller de l'un vers l'autre plutôt que de faire des git merge.

Si en revanche la réponse aux 2 questions est non, vous n'avez qu'une seule ligne de développement. Vous pouvez utiliser le Git Flow et traiter V6 comme une branche de release permanente. Au lieu de développer les features à destination de V6 dans cette branche faites-le dans V7 et faites des cherry-pick depuis develop vers release-V6. C'est une bonne manière de s'éviter les reports de codes. On ne développe jamais de nouvelles features dans une branche de release mais on peut envisager des cherry-pick de features existantes pourquoi pas.

Concernant le Git Flow oubliez la branche master elle ne sert absolument à rien et ne va que vous poser des problèmes (taguez simplement les versions de prod sur les branches de release avant de merge back vers develop).

Dernier point vous devriez envisager une solide formation pour tous vos développeurs avant de passer de svn à git, ça ne s'improvise pas et il s'agit quand même de gérer le code source c'est juste fondamental, sinon c'est catastrophe assurée.

Re-bonjour,

tout d'abord merci beaucoup pour votre retour. Votre réponse est très précise et argumentée.

Le denier point que vous soulevez nous semble inévitable, mais nous voulions étudier nous même la faisabilité avant de se faire aider.
Dans notre cas, nous serions dans le cas 2. Chaque version sera un enrichissement de la précédente et si un dev est fait pour une version antérieur, il sera reporté sur toute les versions qui suivent cette version antérieur.

Encore merci et bonne soirée

Citation:

---

Envoyé par erretegia

Dans notre cas, nous serions dans le cas 2. Chaque version sera un enrichissement de la précédente et si un dev est fait pour une version antérieur, il sera reporté sur toute les versions qui suivent cette version antérieur.

---

Attention avec ce procédé, ça revient à avoir 2 branches develop. C'est très très pénible à gérer avec le Git Flow au quotidien et c'est même dangereux (merge nightmare) si la fréquence des reports est trop faible, et ça va très très vite quelques jours suffisent pour obtenir un merge nightmare.

Vous ne devriez pas développer les features pour V6 depuis V6 mais depuis V7 pour ensuite les cherry-pick vers V6. Là vous n'avez plus besoin que d'une seule develop et vous conservez simplement une branche de release pour V6 pour accueillir les cherry-pick. Point de vue testing ça supprime les risques de régressions sur V7 lors du report, vous n'avez plus qu'à tester la feature normalement pour V7 et tester le cherry-pick sur V6 mais avec un scope fonctionnel forcément moins dense que si vous mergiez de V6 à V7, donc c'est beaucoup moins risqué.

Bonjour,
Merci pour votre retour encore une fois :)

Dans notre réflexion, nous avons une question autour du sujet.
Nous avons bien compris que tout nos devs seront fait sur

Code:

---

develop

---

puis cherry-pick.
Comme je disait dans notre cas d'exemple : Y et Z sont en version V7. Chacun a sa recette, pre-pro et prod.

Admettons nous développons 2 features.
Comment pourra-t-on gérer si un des clients sur V7 souhaite seulement une des deux features sur sa production ?

Bonne journée

En fait il faut commencer par revoir la terminologie pour avoir les idées des claires.

Ce que vous appelez V6 ou V7 ne correspond pas à une version dans votre usage mais à une ligne de développement donc une branche. Une version dans le monde Git ça correspond à un tag et c'est simplement un alias d'un commit. Quand tu crées un tag sur une branche, tu crées un alias du commit le plus avancé sur la branche à ce moment là. On pourrait utiliser directement le sha1 d'un commit mais ceb3defd5aa93d84473a1e2f8153b960207b2f0f est moins sexy que v1.3.1.

C'est très important parce que c'est ce référentiel qui va déterminer à partir de quoi vous buildez vos livrables à déployer dans vos environnements. La config des environnements doit (impérativement) y être incluse. Cela permet de retrouver vos petits quoi qu'il se passe.

Je précise parce que à force d'appeler un chat un chien et parler ensuite d'un chien on ne sait juste plus de quoi on parle. Donc commencez par revoir votre nommage, "V-quelque-chose" n'est pas un nommage adapté à une branche, le mot "version" c'est pour les tags.

Ceci dit, pour en revenir à votre problème de feature, si un client ne veut pas le même contenu il n'est pas sur la même branche. CQFD. C'est la règle de base.

Pour votre "V6" vous pouvez bidouiller parce que les fonctionnalités développées pour ce client vont toutes sans aucune exception dans V7 ET parce que tous les autres clients acceptent toutes ces features, donc vous pouvez cherry-pick depuis develop mais il faut avoir conscience que ça relève du hack. Normalement votre client devrait tout simplement migrer sur V7. Ou alors il a sa propre branche develop.

Pour votre "V7" avec son 2ème cas particulier, et ben là ça commence à faire beaucoup. Si vous commencez à maintenir une branche release pour chaque client dans laquelle vous allez cherry-pick les features qu'il veut ou pas ça va être l'enfer à maintenir et l'enfer à tester.

Dans un tel cas de figure, où on a une mainline depuis laquelle on dérive plusieurs releases différentes avec des contenus différents tirés de la mainline (develop), la seule alternative (autre que une develop par client) en conservant un seul dépôt c'est d'introduire de la configuration de feature pour activer / désactiver ces features sur la base d'un fichier config avec des "si feature bidule est active alors blablabla". Mais ça ne scale pas du tout et ça augmente la complexité des tests (considérablement car explosion combinatoire des cas de tests). Donc gros warning sur la qualité, ça va faire plus de bugs et plus complexes à gérer.

D'une manière générale, quand des lignes de dev dérivent de cette manière, généralement ça finit en fork (un dépôt par ligne de dev et chacun vit sa vie, avec éventuellement un dépôt commun pour mutualiser ce qui peut l'être).

La véritable question de fond serait plutôt, quel produit est-ce que vous développez ?

- Un produit unique avec un seul client récalcitrant un peu à la bourre et les autres dans les clous (ça peut justifier l'exception dans son cas cf post précédent) ?
- Un produit unique configurable où chaque client choisit ses features ? Dans ce cas le fait de pouvoir configurer les features est en soi une feature (très complexe) à mettre en oeuvre (elle doit être financée comme les autres et attention au niveau technique de l'équipe, ce type de fonctionnalité est hors de portée des débutants).
- Un produit pour chaque client avec certains points communs. Ça mériterait de revoir le découpage, il vaudrait peut être mieux avoir un dépôt par client et une lib pour mutualiser ce qui peut l'être.

Voilà les différentes options, après c'est difficile d'aiguiller correctement sans avoir une vision claire de la nature du produit et des contrats avec les clients (ce à quoi vous vous êtes engagés, des fois il faut savoir dire non).

Bonjour,

Encore merci pour toute vos informations.
Je passe le sujet en résolu

Bonne journée