Gestion de la publication de l'application¶
Principes¶
Nous n'utilisons pas la semver.
Version¶
Une version est matérialisée par une branche.
Une version est nommée et non numérotée.
Il existe 3 types de version :
- Les versions LTS (ex :
mammouth) n'évoluent qu'avec les correctifs d'anomalie. - La version
canaricontient les dernières fonctionnalités publiables ainsi que les correctifs. - La version
masterqui est la version de travail, exceptionnellement publiable en interne.
Révision¶
Une révision est matérialisée par un tag.
Une révision est numérotée à partir de 1.
Une révision est publiable.
Schéma¶
Concernant les versions LTS :
- Aucune nouvelle fonctionnalité n'est fusionnée dans la version
mammouth. - Seuls les correctifs de bugs des fonctionnalités déjà présentes sont fusionnés dans la version
mammouth. - Lorsqu'une nouvelle version LTS
pterodactyleest disponible, l'ancienne version LTS n'est plus maintenue. - Seules les révisions
1,2,3, etc. des versions LTS sont publiables (= installables chez les clients).
Concernant la version canari :
masterest fusionnée danscanariau bon vouloir de l'équipe produit, après tests de validation.- Seules les révisions
35,36,37, etc. de la versioncanarisont publiables (= installables chez les clients).
Concernant la version master :
- Rien ne change concernant notre cycle de fusion des PRs.
- Seul HEAD de
masterest publiable mais ne doit être utilisée qu'en interne, par exemple sur le serveur d'intégration.
Liste des versions¶
Le QG contient toutes les versions disponibles sous forme de fichiers contenant le numéro de la dernière révision disponible.
Concernant le schéma d'exemple ci-dessus :
https://qg.efalia.com/static/mgx/versions/mammouth.txt(contient uniquement le numéro de la dernière révision publiée :3)https://qg.efalia.com/static/mgx/versions/pterodactyle.txt(contient uniquement le numéro de la dernière révision publiée :1)https://qg.efalia.com/static/mgx/versions/canari.txt(contient uniquement le numéro de la dernière révision publiée :37)
Quelle que soit la version utilisée par un client, l'instance pourra toujours être mise à jour à la dernière révision (on ne bloque pas une instance à une révision particulière).
Sélection d'une version¶
La version sélectionnée pour une instance est spécifiée dans son fichier manifeste, via une nouvelle clé publication/version.
Par exemple, si le client "Plein Nord Distribution" décide d'utiliser la version LTS mammouth, son fichier manifeste https://qg.efalia.com/static/mgx/plein-nord-prod.json contiendra :
Implémentation¶
Déploiement¶
Le script self-deploy.sh :
- Récupère la version dans le fichier manifeste correspondant et la stocke dans
$VERSIONet dans le fichiershared/instance/VERSION(avec un lien dansapi/public). - Vérifie que le fichier
https://qg.efalia.com/static/mgx/versions/$VERSION.txtexiste et récupère son contenu dans$REVISIONet le stocke directement dans le fichierapi/public(pas dansshared/instance/REVISIONcar il va potentiellement changer lors du déploiement). - Génère le nom du tag
$VERSION-$REVISIONet l'utilise pour cloner le projet directement sur le bon tag.
Vérification du besoin de mise à jour¶
Le front :
- Récupère la version courante de l'instance dans
http://localhost/service/api/public/VERSION. - Récupère la révision courante de l'instance dans
http://localhost/service/api/public/REVISION. - Compare la révision courante au contenu de
https://qg.efalia.com/static/mgx/versions/$VERSION.txt
Si la révision courante est inférieure à la révision disponible, il est alors possible d'informer l'utilisateur et de l'inciter à mettre à jour son instance.
Peut-être serait-il même intéressant de bloquer la mise à jour avec un message explicatif si l'instance est déjà à la dernière révision disponible.
Cas particulier de la version master.¶
Si la version de l'instance est master :
- Le script
self-deploy.shne gère pas la révision et clone simplement le projet sans spécifier de tag. - Le front ne fait aucune vérification et autorise toujours la mise à jour sans afficher de message.