RELEASE.md

Gestion des versions

Ce document décrit comment est géré le versionnement de console, c'est-à-dire les différents aspects qui nous permettent de :

• Préparer la création d'une nouvelle version de console au fur et à mesure des ajouts
• Créer effectivement la nouvelle version
• Mettre à jour le chart Helm concerné
• Publier les nouvelles versions de modules NPM concernés

Schéma récapitulatif

Les sections suivantes vont expliciter ce schéma:

gitGraph
    commit id: "…previous commits"
    commit id: "Add basic features"

    branch release-please-main
    checkout release-please-main
    commit id:"bump to v1.2.0" tag: "v1.2.0"

    checkout main
    merge  release-please-main
    checkout  release-please-main
    branch "hotfix/v1.2.0"
    commit id: "Fix stuff"
    branch release-please-hotfix_v1.2.3
    commit id:"bump to v1.2.1" tag: "v1.2.1"
    checkout "hotfix/v1.2.0"
    merge release-please-hotfix_v1.2.3

    checkout main
    commit id: "Add features"
    checkout release-please-main
    commit id:"bump to v1.3.0" tag: "v1.3.0"
    merge main
    commit id:"bump to v1.3.0" tag: "v1.3.0"
    checkout main
    commit id: "More features"
    checkout release-please-main
    merge main
    commit id:"bump to v1.3.0 (recreated)" tag: "v1.3.0 (recreated)"
    checkout main
    merge release-please-main

    checkout main
    merge "hotfix/v1.2.0"
    checkout release-please-main
    commit id:"bump to v1.4.0" tag: "v1.4.0"
    merge main
    commit id:"bump to v1.4.0" tag: "v1.4.0"
    checkout main
    merge release-please-main

Loading

Versionnement de Console

Le flux de travail qui créé les nouvelles versions s'intitule create-or-update-release et est déclenché à chaque nouveau commit sur main (soit lorsqu'on fusionne une requête de fusion, soit un commit poussé en outrepassant l'interdiction de pousser sur main).

Le flux de travail utilise release-please-action pour automatiquement générer les tags Git ainsi que les nouvelles versions sur GitHub. À chaque fois que du code est poussé dans la branche main, une requête de fusion de version est créée en analysant les messages de commits pour déterminer le numéro de version à créer (patch/mineur/majeur). Si une requête de fusion de nouvelle version existe déjà, elle est mise à jour afin de refléter les nouveaux changements ajoutés à la future nouvelle version.

Les types de commits qui déclenchent une nouvelle version (ou mettent à jour la MR de la prochaine version) sont décrit dans la configuration de release-please, ./release-please-config.json

À chaque fois qu'une requête de fusion de version est fusionnée, les images de conteneur des applications (client, server, etc.) sont alors créées et hébergées dans la registry Github associée au dépôt.

Versionnement du chart Helm dso-console

Le déploiement de console se fait préférablement à l'aide de son chart Helm, nommé dso-console.

La dernière étape du flux de travail de création de nouvelles versions (cf. section ci-dessus) est la création automatique d'une requête de fusion dans le dépôt helm-charts pour la mise à jour du chart Helm dso-console. Une fusion manuelle sur ce dépôt est alors nécessaire pour déclencher la publication de la nouvelle version du chart Helm (embarquant donc la nouvelle version de console). Exemple d'une telle requête de fusion de nouvelle version du chart Helm : cloud-pi-native/helm-charts#204.

Versionnement des modules NPM

La publication des nouvelles versions de modules npm du dépôt est automatique et est inclus dans le flux de travail de création d'une nouvelle version. Il analyse les numéros de version présents dans les différents fichiers package.json pour déterminer si une nouvelle version du module doit être créée et publiée.

Il est possible de créer une version de pré-release d'un module npm en modifiant la clé publishConfig.tag dans le package.json avec par exemple beta pour générer une version beta.

Hotfixes

Autant que faire se peut il vaut mieux privilégier le "Fix Forward" avec de nouvelles releases.

Ceci étant dit, il arrivera, hélas, qu'un hotfix soit nécessaire sur une version livrée.

Voici donc le processus compatible avec l'utilisation de release-please:

• Se placer localement sur le tag de la version concernée: $ git checkout v1.2.3 (v1.2.3 est ici la version à hotfixer)
• En tirer une branche dédiée au hotfix: $ git checkout -b hotfix/my-urgent-hotfix-for-v1.2.3 (Note: Il n'est pas nécessaire de spécifier la version dans le nom de la branche, mais ça peut aider à la lecture et ainsi confirmer la version concernée)
• Faire les modifications nécessaires, committer, etc.
• Pousser la nouvelle branche sur le dépôt Github
• Une fois la nouvelle branche poussée, release-please va être déclenché par le flux de travail Github create-or-update-release afin de créer une requête de fusion pour la nouvelle version hotfixée (avec comme cible la branche de hotfix). Il est d'ailleurs à noter que dans le cas d'un hotfix on ne fait qu'une montée du "patch" quelque soit les commits (donc même un feat! ne fera pas de montée majeure)
• Valider la MR de version hotfixée (créée donc par release-please) à l'aide du flux de travail Github Continuous Integration
• Une fois la MR de version hotfixée validée et fusionnée, la nouvelle version est créée et, comme pour les versions traditionnelles, une requête de fusion est crée dans le dépôt helm-charts pour avoir là aussi une version hotfixée (mais, pour le chart Helm, c'est considéré comme une version classique)
• Il faudra ensuite faire des picorages (git cherry-pick) ou une MR de la branche de hotfix vers main afin d'intégrer le ou les commits de hotfix dans la prochaine version officielle