Skip to content
Snippets Groups Projects
Commit 5d47b7dd authored by Armand Bahi's avatar Armand Bahi
Browse files

Doc GitLab : publication de versions

parent 14ee6993
No related branches found
No related tags found
No related merge requests found
# [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/
gitlab/images/publier_version_1.jpg

47.8 KiB

gitlab/images/publier_version_2.jpg

377 KiB

gitlab/images/publier_version_3.jpg

393 KiB

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment