Introduction

Le versionnement permet de marquer et d’organiser les différentes versions d’un logiciel, ce qui facilite la gestion des modifications, le suivi des fonctionnalités et la garantie de la stabilité du logiciel.

Il permet aux développeurs de comprendre comment le logiciel a évolué au fil du temps, d’identifier les modifications et de revenir à des versions antérieures si nécessaire (rollback).

Les numéros de version assure également une communication claire avec les utilisateurs et les clients. Ils peuvent indiquer la nature des changements (nouvelles fonctionnalités, corrections de bogues, etc.) et aider les utilisateurs à comprendre à quoi s’attendre lors de la mise à jour.

Comprendre SemVer (Semantic Versioning)

Semantic Release s’appuie sur le concept clé de Semantic Versioning, abrégé SemVer. SemVer est une convention de numérotation des versions qui permet aux développeurs de comprendre rapidement l’impact d’une mise à jour logicielle. Une version SemVer se compose de trois parties : MAJOR.MINOR.PATCH. Ces composants représentent respectivement des changements majeurs, mineurs et de correctifs dans le logiciel.

• MAJOR : Les modifications majeures qui peuvent entraîner des incompatibilités avec les versions antérieures.
• MINOR : Les ajouts de fonctionnalités sans introduire d’incompatibilités majeures.
• PATCH : Les corrections de bugs et autres améliorations mineures sans ajouter de nouvelles fonctionnalités.

Exemple : v1.0.2 (MAJOR.MINOR.PATCH)

Gestion Manuelle des Versions

Avant l’avènement d’outils d’automatisation tels que Semantic Release, les développeurs devaient gérer manuellement la génération des versions de leurs projets. Cela impliquait de mettre à jour le numéro de version dans plusiers fichiers spécifiques comme package.json, CHANGELOG.md, README.md etc.. Ces mises à jour manuelles étaient sujettes à des erreurs humaines, telles que l’oubli d’incrémenter la version correctement ou l’omission de détails dans les notes de version.

Pour une meilleure compréhension, il est intéressant d’observer le parcours emprunté par le développeur tout au long du processus de création d’une version de son application.

# Créer un nouveau dossier
$ mkdir mon_projet
$ cd mon_projet

# Initialiser un référentiel Git
$ git init

Lorsque vous commencez à travailler sur un projet, effectuez le premier commit pour marquer le point de départ.

# Ajouter tous les fichiers à l'index
$ git add .

# Créer un commit initial
$ git commit -m "Initial commit"

Création de Branches
Les branches permettent de travailler sur des fonctionnalités ou des correctifs sans affecter la branche principale (généralement main).

# Créer une nouvelle branche pour une fonctionnalité
$ git checkout -b feature/nouvelle_fonctionnalite

# Faire des modifications et créer un commit
$ git add .
$ git commit -m "Ajouter la nouvelle fonctionnalité"

Merge de Branches
Pour fusionner une branche avec la branche principale après avoir terminé une fonctionnalité.

# Se placer sur la branche principale
$ git checkout main

# Fusionner la branche de la fonctionnalité
$ git merge feature/nouvelle_fonctionnalite

Gestion des Tags
Les tags permettent de marquer des versions spécifiques de votre logiciel.

# Créer un tag pour la version 1.0.2
$ git tag -a v1.0.2 -m "Version 1.0.2"

Versions Préliminaires (Release Candidates ou pré-release)
Les versions préliminaires, sont des versions publiées avant la version stable et définitive. Elles peuvent être utilisées pour recueillir des retours d’utilisateurs avant le lancement officiel de la version stable, ou destinées à des tests tout simplement. Pour indiquer une version préliminaire, vous pouvez ajouter un suffixe au numéro de version.

# Créer un tag pour une version préliminaire
$ git tag -a v2.0.0-rc.1 -m "Release Candidate 1 for version 2.0.0"

Récapitulatif des Versions
Visualisez les versions et leurs messages associés.

# Liste des tags
$ git tag

# Afficher les détails d'un tag
$ git show v1.0.2

Publication
Une fois les versions définies, vous pouvez les publier au niveau du référentiel git.

# Pousser les tags vers le référentiel distant
$ git push origin --tags

Se rendre sur votre repository gitlab > deployments > releases. Créer une “Release” en sélectionnant un tag. Une release peut inclure des notes de version qui regroupe les changements entre deux tags, des fichiers joints, et des descriptions détaillées des changements.

La gestion manuelle des versions peut entraîner des retards dans la publication des nouvelles versions, car les développeurs consacrent du temps à effectuer ces tâches administratives au lieu de se concentrer sur le développement de fonctionnalités.

Conventional Commit

Pour résoudre ces problèmes, Semantic Release s’appuie sur un autre concept clé : Conventional Commit. Conventional Commit est une convention de création de messages de commit structurés, qui suivent un format spécifique. Chaque commit est classé en fonction de son intention, que ce soit une nouvelle fonctionnalité, une correction de bug, une amélioration, etc.

Ces types de commit sont généralement préfixés par des mots clés spécifiques. Voici quelques-uns des types de commit les plus couramment utilisés par Conventional Commits :

feat (Feature) : Utilisé pour signaler l’ajout d’une nouvelle fonctionnalité ou d’une nouvelle capacité au code.

git commit -m"feat: Ajout de la fonctionnalité de recherche avancée"

docs (Documentation) : Utilisé pour des changements uniquement liés à la documentation, tels que l’ajout ou la modification de commentaires dans le code.

git commit -m"docs: Mise à jour de la documentation relative à l'API"

style (Style) : Implique des changements liés au style du code, tels que des modifications de formatage, des espaces, etc.

git commit -m"style: Réorganisation des espaces et des indentations"

chore (Chores) : Utilisé pour des tâches de maintenance, des mises à jour de dépendances, des ajustements de configuration, etc.

git commit -m"chore: Mise à jour des dépendances du projet"

refactor (Refactoring) : Indique des changements de code qui ne modifient pas le comportement externe, mais améliorent la structure interne ou la maintenabilité.

git commit -m"refactor: Réorganisation du code pour la maintenabilité"

perf (Performance) : Utilisé pour des modifications destinées à améliorer les performances

git commit -m"perf: Ajout d'index au niveau de la table company"

test (Tests) : Utilisé pour des modifications liées aux tests, telles que l’ajout de nouveaux tests unitaires ou la modification des tests existants.

git commit -m"test: Ajout de tests pour la validation du formulaire"

Il y a aussi les scopes dans Conventional Commits qui sont des indicateurs optionnels utilisés pour fournir des informations supplémentaires sur la portée ou le contexte spécifique d’un changement dans le code. L’ajout de scopes peut aider à organiser et à catégoriser les modifications, en offrant une visibilité plus fine sur les parties spécifiques d’un projet qui sont affectées par un commit. Les scopes sont inclus entre parenthèses après le type de commit.

git commit -m"feat(api): Ajout de la gestion des utilisateurs dans l'API"
git commit -m"fix(ui): Correction du problème du bouton connexion"
git commit -m"refactor(database): Optimisation des requêtes SQL"

Versionnement automatique avec Semantic Release

Semantic Release est un outil de gestion de versions qui automatise le processus de création de version (tag), de publication (push des tags) et de création de releases en se basant sur deux conventions clés : Semantic Versioning (SemVer) et Conventional Commits (mentionné précédemment).

Dans Semantic Release, les types de commit sont utilisés pour déterminer le niveau de version (MAJOR, MINOR, PATCH) à incrémenter lors de la création d’une nouvelle version du logiciel.

PATCH (Correctif)
Les commits de type fix (fix) ,chore (Chores) ou docs (Documentation)… entraînent une incrémentation du niveau de version patch. Ces commits sont généralement associés à des tâches de maintenance, de documentation ou d’autres ajustements mineurs qui n’affectent pas directement le comportement du logiciel.

MINOR (Changement mineur)
Les commits de type feat (Feature) entraîne une incrémentation du niveau de version mineur si la fonctionnalité ajoutée est rétrocompatible.

MAJOR (Changement majeur) :
Les commits n’importe quel type entraîne avec presence du mot BREAKING CHANGE au niveau du footer, indique a semantic release que le changement introduit est majeur.

git commit -m"feat: Ajout d'une fonctionnalité de paiement en ligne\n\n
BREAKING CHANGE: Cette modification nécessite une maj des libs."

Conclusion

En automatisant la génération des versions logicielles, Semantic Release offre une solution élégante pour résoudre les problèmes liés à la gestion manuelle des versions. En combinant les concepts de SemVer et Conventional Commit, cet outil permet aux développeurs de se concentrer davantage sur le développement de fonctionnalités et d’améliorations, tout en garantissant des versions logicielles cohérentes et bien gérées.