semantic-release : quand la CI gère nos versions à notre place

Joël Piazzalunga-Lerat — Mon, 17 Nov 2025 10:05:45 +0000

Vous utilisez les Conventional Commits et vous commencez à apprécier la clarté de l’historique Git (si ce n’est pas le cas, voici un article pour le découvrir).

Mais vous continuez à gérer vos versions à la main, écrire le changelog, créer les tags, publier les nouvelles versions…

Et si tout ça se faisait tout seul ? C’est la promesse de semantic-release.

Par défaut, semantic-release est étroitement lié à l’écosystème npm, puisqu’il est développé en JavaScript et pensé à l’origine pour les projets Node.js mais certains plugins peuvent exister dans d’autres contextes.

Pourquoi semantic-release ?

Versionner à la main peut être une source d’erreurs multiple :

on oublie d’incrémenter le numéro de version
on modifie le changelog une fois sur deux
on ne sait plus si on doit passer en 1.4.2 ou 1.5.0
et parfois on publie sans tag

semantic-release résout tout ça automatiquement en s’appuyant sur les messages de commit (suivant la norme Conventional Commits).

En clair : vous écrivez votre code, vous faites vos commits correctement, vous mergez et le reste se fait tout seul.

Comment ça fonctionne ?

Tout part de l’analyse des commits depuis la dernière version publiée (ex : 1.0.0) :

un fix: déclenche une version patch (ex : 1.0.1)
un feat: déclenche une version mineure (ex : 1.1.0)
un ! ou un BREAKING CHANGE déclenche une version majeure (ex : 2.0.0)

Une fois la version déterminée, semantic-release :

met à jour le changelog automatiquement
crée un tag Git
et publie la nouvelle version (sur npm, GitHub, GitLab, etc.)

Chaque étapes peut être supprimée ou configurée.

En somme : un cycle de release entièrement piloté par votre historique Git.

L’écosystème autour de semantic-release

semantic-release ne travaille pas seul. Il s’intègre parfaitement avec :

commitlint et Husky, pour vérifier la structure des commits
GitHub Actions, GitLab CI, ou n’importe quelle pipeline CI/CD

Une fois en place, il s’impose comme un maillon essentiel du processus d’intégration continue.

Mise en place

Si vous souhaitez l'intégrer sur votre projet, la documentation officielle est relativement bien faite.

En résumé

Avec semantic-release, vous éliminez toute la partie fastidieuse du versioning et vous rendez votre cycle de release fiable, prévisible et sans effort manuel.

En un mot : publie sans y penser.

Conventional Commits : un premier pas vers l’automatisation

Joël Piazzalunga-Lerat — Fri, 04 Jul 2025 15:11:14 +0000

« Fix truc », « maj test »... Vous aussi, vous vous demandez parfois ce que vous vouliez dire il y a trois semaines ? Ou vous tombez sur un « some updates » sans vraiment savoir ce qui a changé ?

Les commits conventionnels (ou conventional commits) s’inscrivent dans une logique d’intégration continue et posent un cadre simple pour écrire des messages clairs et explicites. Voici un apperçu rapide de son fonctionnement.

Qu'est-ce qu'un commit conventionnel ?

C'est un format de message de commit structuré, qui suit une syntaxe précise. L'idée est de décrire clairement le type de changement apporté dans le code. Voici la structure de base :

type(scope): description courte

type : la nature du changement (ex : feat, fix, docs, refactor, etc.)
scope (optionnel) : la partie du code concernée (ex : auth, api, ui)
description : une phrase concise à l'impératif
! (en suffixe du type) : indique un changement majeur (breaking change)

Exemples :

feat(api): add account creation endpoint
fix(ui): fix misaligned submit button in mobile registration form
docs: update README with installation instructions
feat!: remove deprecated /login endpoint

Pourquoi utiliser les commits conventionnels ?

Adopter cette convention apporte de nombreux bénéfices :

Clarté de l'historique Git : plus facile de comprendre les changements
Génération automatique de changelogs : avec des outils comme semantic-release
Versioning sémantique facilité : les types de commits permettent de déduire les changements de version (MAJOR, MINOR, PATCH)

Les types les plus courants

Voici quelques types standard que vous pouvez utiliser :

feat : ajout d'une fonctionnalité
fix : correction de bug
docs : documentation uniquement
style : mise en forme, indentation, etc. (sans impact sur le code, rien à voir avec le CSS)
refactor : modification du code sans ajout de fonctionnalité ni correction de bug
test : ajout ou modification de tests
chore : tâches diverses (ex : MAJ de dépendances)

L'objectif final : l'automatisation des versions

Une fois vos messages de commit structurés, vous pouvez aller encore plus loin : automatiser la gestion des versions.

Certains outils comme semantic-release permettent de déterminer automatiquement les numéros de version à partir des types de commit, de mettre à jour le changelog, de créer un tag Git et de publier la version, le tout sans intervention manuelle.

Un gain de temps, de rigueur, et de la charge mentale en moins!

Quelques outils pour faciliter son utilisation

Vous retrouverez:

La spécification officielle des commits conventionnels : pour comprendre la syntaxe en détail
Cet article de Eleven Labs : un bon complément pour découvrir plus en profondeur semantic-release et l'automatisation des versions

Pour vous aider à mettre en place les commits conventionnels, plusieurs outils existent :

Commitizen (cz-cli) : pour créer des commits via une interface interactive guidée
commitlint : pour vérifier que les messages de commit respectent la convention
Husky : pour intégrer des vérifications (comme commitlint) en pré-commit

Forem: Joël Piazzalunga-Lerat