[Procédure] Applications Vitis - Submodules

1. Definition

Les applications Vitis sont des ensemble de modules composés potentiellement eux mêmes de SQL, Backend et Frontend, chaque application ainsi que chaque module doivent être versionnés, tagués et mis à jour en permanence, comme vous pouvez l’imaginer tout ceci rend l’opération particulièrement difficile à versionner.

Pour faire ceci le plus simplement possible, nous utiliserons des submodules, un submodule est clairement un dépôt contenu dans un dépôt mais en gardant un certain lien.

L’image ci-dessus est l’exemple du dossier src/ de vMap, on retrouve dans ce dossier l’ensemble des modules et autres dépendances utilisées par l’application :

• closure : utilisé pour la compilation
• module_anc : module anc
• module_cadastre : module cadastre
• module_cadastreV2 : module cadastreV2
• module_vm4ms : module vm4ms
• module_vmap : module vMap
• vitis : framework Vitis

Vous remarquerez sur cette image que chaque submodule inscrit après son nom une référence :

Cette référence correspont à un commit, il est très important de comprendre que un submodule contient un depôt non sur sa version en cours mais sur un commit précis.

Gitkraken gère parfaitement les submodules, en ouvrant le projet il va directement détecter l’ensemble des submodules utiliés, puis il permettra de les administrer facilement.

Sur l’image ci-dessous on voit le projet vMap contenant les différents submodules.

2. Effectuer une correction / évolution

2.1. GitLab

Chaque issue est répertoriée dans un premier lieu au niveau de l’application, lorsqu’elle sera identifiée l’administrateur la copiera dans le(s) module(s) impacté.

Lors de la copie il mentionnera l’URL de l’issue de l’application, ainsi un lien sera crée entre les deux.

| | | |:—————————-:|:—————————-:| | Application | Module |

Pour commencer le correctif, le développeur créera depuis l’issue du module une merge request ce qui aura pour effet de créer également la branche associée.

2.2. GitKraken

2.2.1. Avant développement

Pour faire une correction ou une évolution il va falloir modifier le contenu d’un des modules, dans notre exemple il s’agit d’une évolution au niveau du module_vmap.

En doublecliquant sur le submodule GitKraken me propose de l’ouvrir.

| | | |:—————————-:|:—————————-:| | Application | Module |

Une fois dedans deux détails sont importants à remarquer.

• Sur le bandeau du haut on voit bien qu’on se situe sur le submodule, plus précisément sur une branche HEAD.
• Parmis les branches disponibles, on me propose la branche correspondant à l’issue que je veux corriger.

Pour commencer le developpement, double-cliquer sur la branche en question pour se placer dessus.

Vous pouvez désormais effectuer vos correctifs directement dans le répertoire src/ de l’application.

2.2.2. Après développement

Une fois les développements effectués vous pourrez commiter sur la branche impliquée, faire le push, puis assigner le responsable de projet.

Une fois la merge request acceptée, GitKraken nous indique que nous devons faire un pull sur next_version (car sur l’exemple il s’agit d’une évolution).

Il ne restara qu’à re-passer sur master/next_version puis faire un pull pour rapatrier les modifications précédament effectuées pour que le module soit à jour.

L’application quand à elle pointe toujours sur le même commit qui lui sert de référence.

En remontant au niveau de l’application sur GitKraken on remarque donc qu’il y a eut des modifications sur module_vmap.

En faisant un clic droit et en cliquant sur Commit changes on modifie le commit de référence par le nouveau, désormais lorsque quelqu’un fera un clone il disposera de la nouvelle feature.