Doc GitLab : publication de versions

gitlab/applications_vitis.md

 # [Procédure] Applications Vitis
 
-## 1. Subtrees
+## 1. Structure
 
-### 1.1. Définition
+### 1.1. Subtrees
+
+#### 1.1.1. Définition
 
 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.
 
@@ -14,7 +16,7 @@ Pour faire ceci le plus simplement possible, nous utiliserons des [subtrees](htt
 
 ![subtree](images/subtrees_1.png)
 
-### 1.2. Subtrees dans les applications
+#### 1.1.2. Subtrees dans les applications
 
 Plusieurs fichiers utilitaires sont disponibles sur les applications pour agir sur les subtrees :
 - **pull_subtrees.sh** : permet de mettre à jour l'ensemble des subtrees
@@ -33,7 +35,7 @@ Quand on crée une branche pour effectuer un correctif ou une évolution pas bes
 
 L'utilisation de **pull_subtrees.sh** et **push_subtrees.sh** se fera uniquement depuis les branches **master** et **next_version**.
 
-## 2. Installation locale
+### 1.2. Installation locale
 
 Pour utiliser une application versionnée localement, il faudra l'installer car l'architecture proposée avec les dépendances dans le dossier src/ ne convient pas, pour ce faire nous utiliserons des liens symboliques sur linux et des copies de fichiers sous windows.
 
@@ -46,3 +48,64 @@ Pour créer ces liens de manière automatique on peut utiliser la procédure sui
 Une fois ceci fait les dossiers client/ et vas/ seront créés et vous pourrez modifier directement les fichiers dans le dossier src/ ou directement dans client/ et vas/.
 
 Sur **windows** les liens symboliques ne permettent pas leur utilisation dans ce contexte, il faudra donc éditer dans **src/** puis lancer **update.bat** pour appliquer les modifications.
+
+
+
+
+
+
+
+## 2. Publier une version
+
+On peut facilement publier une version en 4 étapes à l'aide d'outils automatisés, on distinguera deux types de versions, les **versions mineures** correspondant à des corrections de bugs qui seront taguées en changeant uniquement le dernier nombre (ex: 2018.01.**xx**), les **versions majeures** correspondent à des évolutions apportées au produit, elles seront taguées en changeant le nombre du milieu (ex: 2018.**xx**.00).
+
+### 2.1. Versionner les modules impactés
+
+La première chose à faire c'est de versionner les modules modifiés, pour cela on va envoyer les modifications au module en utilisant **push_subtrees.sh**, puis aller sur la branche impactée pour créer une branche qui portera comme nom le nom **pre-2018.xx.xx**.
+
+Dans notre exemple on veut créer un e version mineure, la version en cours est la 2018.03.01 on créera donc une branche pre-2018.03.02
+
+![](images/publier_version_1.jpg)
+
+La deuxième chose à faire c'est de versionner l'application, pour cela on créera une branche portant le nom de la version à générer, puis on modifiera le fichier **conf/\_install/dependency.xml** pour utiliser les branches de pre-production et enfin on utilisera **pull_subtrees.sh** pour rapatrier les nouvelles branches sur l'application.
+
+
+### 2.2. Générer une version pre-prod et effectuer les tests
+
+Maintenant que la structure est versionnée in faudra générer un setup et effectuer les tests, pour cela il suffit de ce rendre sur http://jenkins.veremes.net/ et lancer un job de type **Generate un and test app**.
+Ce dernier va générer un setup, le poser sur S3, démarrer une machine AWS, installer la version dessus et lancer les tests API-REST.
+
+Pour lancer le job il faudra saisir les paramètres suivants:
+
+* **APP_NAME** : nom de l’application à générer
+* **OS** : le ou les OS sur lesquels installer
+* **VERSION** : numéro de version à générer
+* **RUN TEST** : cocher la case pour lancer les tests API-REST (en cours de développement)
+
+![](images/publier_version_2.jpg)
+
+Une fois le job terminé vous pouvez résupérer l'url de l'application générée en cliquant sur l'étape "*Run app on ...*" puis aller tester manuellement l'application.
+
+![](images/publier_version_3.jpg)
+
+**Il est important d'effectuer également des tests en mise à jour**, aucun job n'a été développé pour l'instant donc il faudra effectuer le test manuellement.
+
+
+### 2.3. Créer les tags associés
+
+Une fois que les tests sont concluants on pourra créer les tags associés pour ceci il faudra sur chacune des branches modifiées appliquer la procédure suivante :
+
+1. Faire un merge vers master
+1. Créer un tag à partir de la branche pre-prod
+1. Supprimer la branche de pre-prod
+
+Pour l'application la procédure est légèrement différente :
+
+1. Modifier dependency.xml pour utiliser les tags créés précédemment
+1. Utiliser pull_subtrees.sh pour être sur d'avoir intégré toutes les modifications
+1. Créer un tag à partir de la branche pre-prod
+1. Supprimer la branche de pre-prod
+
+### 2.4. Générer une version de production
+
+La dernière étape consiste à rejouer l'étape 2.2 puis récupérer le setup généré sur https://s3.console.aws.amazon.com/s3/buckets/veremes-dev-ressources/builds/