Aller au contenu

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 canari contient les dernières fonctionnalités publiables ainsi que les correctifs.
  • La version master qui 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 pterodactyle est 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 :

  • master est fusionnée dans canari au bon vouloir de l'équipe produit, après tests de validation.
  • Seules les révisions 35, 36, 37, etc. de la version canari sont publiables (= installables chez les clients).

Concernant la version master :

  • Rien ne change concernant notre cycle de fusion des PRs.
  • Seul HEAD de master est 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 :

{
  "publication" : {
    "version": "mammouth"
  }
}

Implémentation

Déploiement

Le script self-deploy.sh :

  • Récupère la version dans le fichier manifeste correspondant et la stocke dans $VERSION et dans le fichier shared/instance/VERSION (avec un lien dans api/public).
  • Vérifie que le fichier https://qg.efalia.com/static/mgx/versions/$VERSION.txt existe et récupère son contenu dans $REVISION et le stocke directement dans le fichier api/public (pas dans shared/instance/REVISION car il va potentiellement changer lors du déploiement).
  • Génère le nom du tag $VERSION-$REVISION et 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.sh ne 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.