Versioning, Releases : semantic-release est là ! – Seconde partie

 Utilisation

 Prérequis

Une fois que vous aurez configuré les éléments requis concernant votre projet grâce à notre précédent article, vous allez pouvoir créer des commits sur GitLab (ou GitHub) mais attention ! Nous cherchons ici à réduire au maximum le risque humain !

Il est donc conseillé d'installer le plugin conventional commit dans Visual Studio Code vous permettant de catégoriser vos commits et permettre au semantic-release de mieux détecter de quel type de release il s'agit (Patch, Minor, Major) !

Si vous utilisez un autre IDE (Environnement de Développement Intégré) vous pourrez toujours utiliser le système des pre-commit pour contrôler les messages écrits par vos développeurs

 Workflow

Et oui, en fonction de votre workflow git vous allez avoir différents types de branches comme :

  • La branche master/main
  • Celle de pre-release
  • Une alpha
  • Une beta

Heureusement pour vous, Semantic-release gère tous types de workflow, à condition bien-sûr d'installer et de configurer l'outil. C'est ce que nous allons voir :

Fonctionnement

Par exemple :

  • Un fix donnera un patch (version 1.0.X)
  • Un feat donnera une minor release (version 1.X.0)
  • Une Breaking change donnera une major release (version X.0.0).

Au moment où vous pusherez votre code, le job correspondant au semantic-release se jouera.

Durant ce job :

  1. La commande semantic-release sera lancée.
  2. La branche où vous avez push/merge va être analysée.
  3. Si un tag est déjà présent alors on passe à la version suivante
  4. Comme dit précédemment, les commits passés vont être analysés, ce qui permettra de déterminer quelle sera la version suivante.

Exemple avec un passage à une version patch pour une pre-release:

Commitez votre code avec comme type de commit fix (et ici comme description: passage en node18) :
git commit -m "fix: passage en node18"
(Vous pouvez aussi utiliser l'extension "conventional commit" dans Visual Studio Code vous permettant de faire des commits propres facilement)

Ce qui donnera lors de l'analyse :

Et à la fin, vous aurez :

  • Votre nouvelle version :

  • Votre release (que vous pourrez retrouver dans Deployments > Releases) :

    Et voici votre release toute chaude, sortie du four de la CI 😉

Merci à vous d'avoir lu cet article 🙂