Discussion :

[Orwel]

Bonjour,

je suis actuellement en charge du développement d'une application. Cette application à plusieurs dérivés en fonction de deux domaines métier. De plus une autre dérivés est une version légère de l'application. Voici un récupilatif :

-Application métier1
-Application métier2
-Aplication métier 2 léger

Ces trois applications repose sur une même base d'interface graphique et de méthode interne. Il y a donc une partie commune "Application base". De plus, ces applications utilisent des DLLs. Chaque application utilise certaines DLLs. Il y a cinq paquets de DLL.

Donc on a trois projets distincts, avec de nombreuses dépendances communes. Voici un schéma récupilatif de ce charabia :


L'ensemble est codé en C# (VB pour certaines vielles DLLs, pas d'évolution, juste de la correction de bug). On utilise l'IDE Visual Studio avec l'extension GitExtension.

Actuellement, on utilise donc l'outil de solution de Visual Studio pour l'ajout de dépendance dans le projet. Donc en ouvrant la solution de Application métier 1, on peut accéder directement aux sources des Dlls ou de Application base. Chaque projet (application et dépendance) a son propre dépôt. Donc on mémorise dans des notes les branchements de révision et on charge à la main, ce qui est peu pratique.

On aimerait avoir une méthode subversionnage adapter à ce genre de projet qui comprend plein de dépendance commune.

Le mieux serait lorsque l'on charge une branche/révision d'une des applications, il charge aussi la branche/révision correspondante dans les Dlls et Application Base. Le but étant de promouvoir les modifications des dépendances vers l'ensemble des applications, mais sans les rendre immédiatement obligatoire. Chaque modification dans les dépendances devra être répercuter un jour dans les applications.

Par exemple, je modifie Application metier 1 qui demande une modification dans Application base. Ensuite j'ai une correction de bug urgente dans Application metier 2. J'aimerais pouvoir corriger mon bug rapidement sans effectuer en plus les modifications de Application Base

Actuellement c'est possible, il suffit d'ovrir Application metier 2 et de recharger les révisions de chaque dépendance (grâce aux notes), mais ce n'est pas ergonomique et très sensible aux erreurs (il ne faut pas se tromper de révision des dépendances).

J'ai vu qu'il existait un système de gestion de sous-module dans Git, mais cela procède à une copie complète de chacune des dépendances. De plus, il faut faire des modifications dans la dépendance d'origine, ensuite demander une mise à jour dans l'application. Ce processus est relativement lourd. On aimerait faire des modifications directement depuis les solutions Visual Studio des applications.

Il est possible depuis une solution Visual Studio d'une application d'accéder et de modifier les sources des dépendances. Ce qui impacte l'ensemble des applications. Mais avec la gestion des sous-module de Git, cela n'est pas possible. Car les sources des dépendances sont dupliquées et il n'est pas possible de les modifier directement.

J'aimerais donc avoir vos idées ou une opinion sur le système actuelle.

Petite précision, on ne travaille que sur une application à la fois. Il n'est pas possible d'avoir plusieurs branches d'un dépôt Git active en même temps.

[Philippe Bastiani]

Git n'est qu'un SCM ! Et, non pas, un outil de build...

Les sous-modules ne sont rien d'autre que des dépots externes que tu lies à un dépot principal... ton dépot principal et chacun de tes modules gérant ses propres ressources !

Git n'est pas SVN : la gestion d'un dépot git s'appuie sur le gestion de branches ! Chaque branche est une vue de ton dépot... Une branche (tout comme un sous-module d'ailleurs) n'est pas une copie de ressource...

Les sous modules te permettrant d'avoir un cohérence d'ensemble des tes dépots... le versionnage sera alors réalisé via branches et tag dans chacun des dépots! Tu peux associer une version à un tag et/ou une branche... Et, encore une fois sans faire de copie.

Après, il faut savoir, que la gestion de sous-modules imposent des contraintes supplémentaires ! Et, souvant une gestion totalement indépendante des modules est plus facile à maintenir : tu peux très bien avoir un même nom de tag et/ou un branche sur plusieurs dépots séparés... en partant de là, tu poses des références sur chacun de tes dépots ! Et rien n'empêche à ceci d'avoir leur propre cycle de vie...

a+
Philippe

[Orwel]

Git n'est qu'un SCM ! Et, non pas, un outil de build...

Notre outil de buil est le solutionnaire de Visual Studio.

Les sous-modules ne sont rien d'autre que des dépots externes que tu lies à un dépot principal... ton dépot principal et chacun de tes modules gérant ses propres ressources !

C'est pour cela que je souligne ce point. Il s'agit d'une fonctionnalité de Git proche de ce que l'on veut, mais il faudrait que les dépots principals puisse faire évoluer les sous-modules. Hors, chacun gére ses propres ressources.

Les sous modules te permettrant d'avoir un cohérence d'ensemble des tes dépots... le versionnage sera alors réalisé via branches et tag dans chacun des dépots! Tu peux associer une version à un tag et/ou une branche... Et, encore une fois sans faire de copie.

Sans faire de copie??? EN parlant de sous-module on parle bien de la commande "git submodule"??? Si la copie n'est pas obligatoire, il faudra que je reprenne ce point et ma question première est juste stupide

Après, il faut savoir, que la gestion de sous-modules imposent des contraintes supplémentaires

Je pensais que les contraintes étaient de devoir copier le dépôt et de ne pas avoir le droit de le modifier, juste faire des checkout et des updates.

Et, souvant une gestion totalement indépendante des modules est plus facile à maintenir : tu peux très bien avoir un même nom de tag et/ou un branche sur plusieurs dépots séparés... en partant de là, tu poses des références sur chacun de tes dépots ! Et rien n'empêche à ceci d'avoir leur propre cycle de vie...

Je n'ai pas compris ce passage. La problématique est qu'un checkout sur un déôt principale entraîne en cascade des checkout sur les dépôt des dépendances.

Je te remercie pour tes explications. Je pense que je vais approfondir submodule, mon paramétrage ne devait pas être correct?

ps:Réellement, ce compte est inscrit depuis 2010 et c'était mon premier message. Je suis vraiment un lecteur passif

[Philippe Bastiani]

Je t'ai pris le premier exemple trouvé sur github:

https://github.com/bmchild/gitmodules-superproject est le dépot global ! Dans ton dépots tu n'as pas une copie des 3 sous modules mais une référence (i.e. un pointeur et non pas une copie) à ceux si :

Dans le .gitsubmodules tu retrouves les modules

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
[submodule "gitmodules-parent"]
    path = gitmodules-parent
    url = git@github.com:bmchild/gitmodules-parent.git
[submodule "gitmodules-model"]
    path = gitmodules-model
    url = git@github.com:bmchild/gitmodules-model.git
[submodule "gitmodules"]
    path = gitmodules
    url = git@github.com:bmchild/gitmodules.git

ensuite, le dépot pointe sur des références de commit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gitmodules @ 3ffb7d2

Quand tu fais un checkout, tu vas dans, ton workspace retrouver l'ensemble des projets ce qui représente une vue (ce n'est pas une copie mais une reconstitution puisque les dépots distants (depots bare) n'ont pas directement tes fichiers sources) !

Quand, je dis 'ajout de contraintes' : regardes le chapite Git sous-modules du livre PRO Git... il faut absolument travailler sur une branche. Ensuite, comme les sous-dépots restent indépendants il va falloir faire des synchros... imho, pas simple au quotidien (i.e. commandes git spécifiques)...

Un bon mini tuto : http://blog.courtine.org/2011/03/04/...ules-avec-git/

Après reste à savoir si tu as réellement besoin des sous-modules: as-tu besoin de l'ensemble des sources dans ton workspace ? Ton système de build n'est-il pas capable d'aller tirer une version spécifique sur un dépots distant ?

Concernant le passage que tu n'as pas compris : je voulais dire qu'une bonne gestion des branches des tags et des numéros de version sont souvent amplement suffisants...

Tu pourrais travailler ainsi pour git sans sous-modules:
-1- chaque versions publiées a sa branche de maintenance et son tag sur chacun de tes dépots (i.e. tu retrouves la branche/tag Vxx sur chaque dépot de tes modules).
-2- régulièrement un point de synchro est réalisé (version globale interne): tu forces l'incrémentation des versions des modules - voir plus bas). Et, éventuellement tu poses des tag et/ou tu ouvres des branches.
-3- chaque module peux avoir sa propre évolution entre 2 synchros globales
-4- pour de la maintenance tu reviens sur la branche en question (tu récupères ainsi les dernières version publiées de chaque module pour la version concernée). Tu fais ton fix et tu republies.

Concernant la numérotation: tu imposes une numérotation globale de tes versions (par exemple: versionglobale . sousversionmodule ... i.e. numérotation en 2 parties).
A chaque publication ou point de synchro:
- la version globale est mises à jour
- les sous-version de chaque module repartent de 0

Ex: pour la version globale 10.0.1 on a une branche V10.0 sur chaque module
- le module 1 peux avoir le numéro 10.0.1.5 sur la branche V10.0
- le module 2 peux avoir le numéro 10.0.1.9 sur la branche V10.0
Avec version globale
- 10.0.1 (version publiée 10.0 + synchro numéro 1)
- 5 versions internes du module 1 pour la version globale 10.0.1
- 9 versions internes du module 2 pour la version globale 10.0.1
Quand tu fais un checkout (des 2 modules) de la branche V10.0 tu retrouves les versions
10.0.1.5 & 10.0.1.9 des 2 modules...

Avantage de ce process
- simple à mettre en oeuvre (i.e. gestion de base pour git - maintenance par branche)
- cohérence entre les versions des modules vis-à-vis de la version globale
Inconvénient
- entre 2 version publiée, tu dois gérer à la main les dépendances... il faut donc prévoir des points de synchro réguliers !

Sur mon projets actuel nous travaillons ainsi avec de nombreux dépots séparés et inter-dépendants (nous faisons un point de synchro pour chaque itération scrum)... En plus de cette gestion des sources purement git nous utilisons un gestionaire de dépots pour le build => chaque développeur n'a pas besoin d'avoir sur son poste toutes les sources d'une version donnée... Voilà en espérant avoir été clair !

a+
Philippe

[Orwel]

Je te remercie du temps que tu as pris pour m'expliquer cela. Maintenant c'est plus clair dans ma tête.

Premièrement, je me suis mal exprimé, mais j'ai déjà fait quelque recherches, donc je recherchais surtout un retour sur expérience car c'est ce qui me manque pour faire un choix judicieux.

je voulais dire qu'une bonne gestion des branches des tags et des numéros de version sont souvent amplement suffisants...

C'est actuellement ce que l'on fait. On mémorise dans des notes pour chaque révision des applications, les révisions des dépendances correspondantes. Mais il faut charger la bonne révision pour chaque dépendance lorsque c'est nécessaire lorsque l'on travaille sur une autre application. Vu que l'on a peu de modifications dans les dépendances, on s'en sort bien. Mais on prévoit d'en rajouter des nouvelles et d'en fusionner entre-elle (pour virer les dlls VB). Sans expérience, je ne sais pas si la procédure actuelle va piquer un peu, beaucoup ou pas du tout.

Un bon mini tuto : http://blog.courtine.org/2011/03/04/...ules-avec-git/

Dans ce tutorial, il propose une méthode qui consiste à créer un unique dépôt GIT qui contient tout. J'y ai pensé car très facilement réalisable avec notre architecture actuelle. Voici la structure des dossiers :

Application
-Application base
-Application metier 1
-Application metier 2
-Application metier 2 leger
-Dll 1
-Dll 2
......

Voici les avantages de cette méthode :
- 1 seul dépôt (un unique push/pull/checkout entre colloborateur)
- 1 seul checkout pour charger les dépendances d'une application
- Utilisation des commandes de base de GIT
- Très simple à mettre en oeuvre

Il suffirait d'avoir une branche par Application et de faire des synchronisations en fin de sprint (un peu comme vous). Mais j'ai peur de surcharger le dépôt en commit et de ne plus m'y retrouver (ce qui peut être stupide, vu l'immensité d'autre projet comme Unix).

Sinon j'ai vu une solution très intelligente qui est le super-projet. C'est très proche de la solution précédente, sans les avantages cités. Mais je cherche surtout un retour sur expérience ou des avis sur l’architecture actuelle/ma proposition (le problème venait de moi à la base) pour prendre ma décision.

Je me fourvoie violemment, je demandais bien des propositions dans le premier message. Puis fallait rectifier mes erreurs sur les sous-modules.

[Philippe Bastiani]

Ben, dans mon projet actuel nous devons avoir un bonne vingtaire de dépots avec des dépendances transitives... Quand tu fais un modification d'API il faut simplement avoir conscience que des modules clients vont être impactés... pour le reste, l'outil de build se charge de tirer les bonnes version ! IMHO, les sous-modules n'ont un intêret que pour les projets éclatés sur des équipes qui n'ont pas les mêmes pratiques en terme de gestion des dépots... Ensuite, en entreprise, je pense qu'il est préférable de délégué la gestion des dépendances à un outil dédié...

Autre indice : sur github, tu trouveras que très peu d'architectures basées sur les sous-modules !

Concernant le tuto : le dépot parent contient les références aux autres dépots (c.f. l'exemple github)... c'est le principe des sous modules !
Le mode de fonctionnement en sous-modules ne surcharge aucunément tes dépots distants... tu n'as finalement qu'un dépot supplémentaire allégé référençant d'autre dépots !

J'avais proposé cette solution alternative il y a quelques mois dans cette discussion...

a+

[Orwel]

Je pense actuellement pour utiliser un unique dépôt git qui subversionne l'ensemble des applications et des dépendances.

On n'a pas de dépôt distant, on travaille uniquement en local en groupe de deux. Donc on n'effectue jamais de push, uniquement un pull deux fois par jour pour récupérer les modifications du collègue. Mais avec ce projet, on effectue 7 pull, ce qui est laborieux.

Voici un récupilatif des avantages et des inconvénients de cette solution.
Avantages :
- 1 seul dépôt (un unique push/pull/checkout entre collaborateur)
- 1 seul checkout pour charger les dépendances d'une application
- Utilisation des commandes de base de GIT
- Très simple à mettre en oeuvre
- Possibilité de fusionner l'historique actuelle des dépôts

Inconvénients:
- On ne peut pas déclarer certaine dépendance en lecture seule (pour limiter le collègue).
- Chaque application est liée à l'ensemble des dépendances (même si inutile).
- Le tag d'une application contiendra des informations inutiles concernant les autres applications.
- Il sera plus difficile de voir les modifications concernant un ex-dépôt en particulier.

J'ai marqué projet complexe, mais en comparaison avec votre travail, je passe pour une peluche.