diff --git a/gitlab/applications_vitis.md b/gitlab/applications_vitis.md index 722f94c27db9792bdda782a5cfc1beb90bc0f94d..ea7d85e591b92ab666c45800613578e2a63298fa 100644 --- a/gitlab/applications_vitis.md +++ b/gitlab/applications_vitis.md @@ -1,8 +1,10 @@ # [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  -### 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 + + + +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) + + + +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. + + + +**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/ diff --git a/gitlab/images/publier_version_1.jpg b/gitlab/images/publier_version_1.jpg new file mode 100644 index 0000000000000000000000000000000000000000..a4823d5242e6a9bcc3a32e75081175b8a5766ed1 Binary files /dev/null and b/gitlab/images/publier_version_1.jpg differ diff --git a/gitlab/images/publier_version_2.jpg b/gitlab/images/publier_version_2.jpg new file mode 100644 index 0000000000000000000000000000000000000000..4397e7a36575d1ebc011bbbffa95ccaaf4a5f942 Binary files /dev/null and b/gitlab/images/publier_version_2.jpg differ diff --git a/gitlab/images/publier_version_3.jpg b/gitlab/images/publier_version_3.jpg new file mode 100644 index 0000000000000000000000000000000000000000..d44b2fa36d3e8dccc7f659f419e0ec25408b925e Binary files /dev/null and b/gitlab/images/publier_version_3.jpg differ