Comment mettre en place un système de versionning pour son projet avec Semantic Release sous Github Action
Écrit par
Publié le
Do not index
Do not index
Primary Keyword
Lié à Analyse sémantique (Articles liés) 1
Lié à Analyse sémantique (Articles liés)
Statut rédaction
A optimiser SEO
Lié à Analyse sémantique (Articles liés) 2
Introduction à Semantic ReleasePrésentation du Semantic VersioningPrésentation de Semantic ReleaseLes différents plugins de Semantic ReleaseCréation projet Angular pour tester Semantic ReleasePré-requis pour installer Semantic ReleaseInstallation de Semantic ReleaseConfiguration de Semantic ReleaseCréation jeton d’accès pour Semantic ReleaseCréation du fichier de configuration de Semantic ReleaseExemple d’utilisation de Semantic Release dans une pipeline Github ActionsConclusion
Introduction à Semantic Release
Le versionnage des projets est une étape essentielle du cycle de vie d’un logiciel. Elle permet, si bien réalisée, d’identifier les versions, les fonctionnalités, les changements critiques, ainsi que les correctifs appliqués à une application dans le temps.
Il est important de mettre en place des processus et des outils de gestion de version efficaces pour faciliter l’évolutivité de ses versions dans le temps, de cette façon, il sera plus facile de réaliser des mises à jours et retour en arrière au besoin.
Dans cet article, nous commencerons par présenter Semantic Release, un outil de versionnage qui permet de mettre en place les bonnes pratiques de versionnage, puis nous vous montrerons comment le configurer sur un projet Angular hébergé sur Github.
Présentation du Semantic Versioning
Avant de présenter Semantic Release, il est important de connaitre le Semantic Versioning. Le Semantic Versioning est un standard de versionnage très répandu dans le monde du logiciel et défini formellement sur son site officiel : https://semver.org/
Il permet aux créateurs de logiciels de mettre en avant les modifications de leur logiciel de façon standardisée via un système de version basé sur 3 nombres séparés d’un point sous le format Major.Minor.Patch où :
- Major : à incrémenter si un changement dans le code entraine en rupture avec la version précédente (changement d’URLs, changement de paradigme d’utilisation, etc)
- Minor : à incrémenter si une nouvelle fonctionnalité est ajoutée sans ajouter de changements qui casserait l’usage du composant après une mise à jour
- Patch : à incrémenter après avoir corrigé un bug ou introduit des changements ne changeant pas le comportement du logiciel
A noter que :
- Si une version majeure est incrémentée, les valeurs de mineur et de patch recommencent à zéro : 4.5.5 → 5.0.0
- Si une version mineure est incrémentée, la valeur de patch recommence à zéro : 4.5.5 → 4.6.0
Présentation de Semantic Release
Semantic Release automatise l'ensemble du flux de travail de publication de l’application, notamment la détermination du numéro de version suivant, la génération des notes de publication et enfin la publication du package. Son objectif principal est de permettre aux développeurs de se concentrer sur l'écriture de code de qualité plutôt que de passer du temps à gérer manuellement le processus de versionnage et de publication.
Cela supprime le lien immédiat entre les émotions humaines et les numéros de version, en suivant strictement le Semantic Versioning et en communiquant l'impact des modifications aux consommateurs.
Les différents plugins de Semantic Release
Pour automatiser le processus de publication de versions de logiciels, Semantic Release met à disposition un ensemble de plugins tels que :
@semantic-release/git: création et push de la nouvelle version du code source vers le dépôt Git correspondant, en utilisant la convention SemVer.
@semantic-release/changelog: génération d’un fichierCHANGELOG.mden se basant sur les commits effectués depuis la dernière version. Cela permet de documenter les changements apportés à chaque version.
@semantic-release/github: mise-à-jour des releases sur Github en y ajoutant les notes de version générées par le plugin@semantic-release/changelog.
@semantic-release/commit-analyzer: analyse les messages de commit pour déterminer s'il s'agit d'un changement majeur, mineur ou patch. Il utilise les conventions de message de commit pour identifier les types de changements et les associer à une version sémantique. Cela permet de générer la prochaine version de logiciel en fonction des changements effectués par les commits.
@semantic-release/release-notes-generator: génération des notes de version à partir des messages de commit. Il crée une liste des modifications effectuées depuis la dernière version et les organise par type.
Création projet Angular pour tester Semantic Release
Dans ce tutoriel nous allons créer un projet Angular pour la démonstration. Bien évidement, il est possible d’utiliser cet outil avec n’importe quel langage de programmation tant que vous avez Node.js installé sur votre machine.
Il est important de noter que les plugins disponibles pour Semantic Release peuvent varier selon le langage de programmation utilisé. Par exemple, il existe des plugins spécifiques pour les projets Node.js, Java, PHP, Python et Ruby, qui ont été développés pour répondre aux besoins spécifiques de ces langages.
Pour la création d’un nouveau projet Angular, il suffit de taper dans le terminal:
ng new my-projectAprès la création du projet, créez un répertoire sur Github et faites le push sur le répertoire distant.
# Pour plus d'informations: https://docs.github.com/en/get-started/quickstart/create-a-repoPré-requis pour installer Semantic Release
Version Git: ≥2.7.1
Version Node: ≥18.0.0
Installation de Semantic Release
Pour installer Semantic Release dans votre projet :
cd my-project
npm install -D semantic-release
npm install -D @semantic-release/commit-analyzer
npm install -D @semantic-release/exec
npm install -D @semantic-release/release-notes-generator # https://github.com/semantic-release/release-notes-generator
npm install -D @semantic-release/changelog #Pour plus d'informations: https://github.com/semantic-release/changelog
npm install -D @semantic-release/githubConfiguration de Semantic Release
Lorsque vous utilisez Semantic Release pour publier une nouvelle version de votre projet sur une plateforme comme NPM ou GitHub, vous avez besoin d'un jeton d'accès pour vous authentifier auprès de la plateforme et accéder aux fonctionnalités nécessaires pour publier la nouvelle version.
Le jeton permet donc à Semantic Release d'effectuer des opérations sur la plateforme de publication, comme créer une nouvelle version, mettre à jour les fichiers de version, publier des notes de version, etc.
Nous allons donc vous montrer comment créer un jeton ainsi que ses privilèges nécessaires pour opérer.
Création jeton d’accès pour Semantic Release
Pour configurer Semantic Release, nous commençons par la création d’un jeton
GH_TOKEN :Pour créer le jeton Github, connectez-vous à votre compte GitHub et accédez aux paramètres de votre compte > Paramètres de développeur > Jetons d'accès personnel > Générer un nouveau jeton.
repo: donner accès à votre référentiel et créer une nouvelle release en votre nom.
write:packages: autoriser la publication du package de la release sur GitHub Package Registry, si vous l'utilisez.
read:user: donner accès au nom d'utilisateur de votre compte GitHub.
user:email: donner accès à votre adresse e-mail.
Une fois que le jeton est prêt, allez sur votre répertoire > Paramètres > Secrets > Nouveau secret de dépôt :
GH_TOKEN=tokenEnsuite ajoutez les privilèges d’écriture au niveau des permissions du workflow : votre répertoire > Paramètres > Actions > Général
Création du fichier de configuration de Semantic Release
Créez le fichier
release.config.js :# Pour plus d'informations: https://semantic-release.gitbook.io/semantic-release/usage/configuration
module.exports = {
branches: ['main'],
plugins: [
'@semantic-release/commit-analyzer',
'@semantic-release/release-notes-generator',
[
"@semantic-release/changelog",
{
"changelogFile": "./CHANGELOG.md"
}
],
'@semantic-release/git',
'@semantic-release/github',
],
"dryRun": false # Par défaut : 'false' si exécuté dans un environnement CI, true sinon.
};Cette configuration active Semantic Release au niveau de la branche
main et génère le fichier CHANGELOG.md qui contient la liste des versions ainsi que des commits de chacun. Exemple d’utilisation de Semantic Release dans une pipeline Github Actions
Maintenant que vous avez créé le fichier de configuration de Semantic Release, vous pouvez l’intégrer facilement dans votre pipeline CI/CD en lançant une commande
npx comme ceci :name: Release
on:
push:
branches:
- main
jobs:
release:
name: Release
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
with:
fetch-depth: 0 # Pour cloner la totalité de l'historique Git du dépôt
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: "18.0.0"
- name: Install dependencies
run: npm ci
- name: Release
env:
GITHUB_TOKEN: ${{ secrets.GH_TOKEN }} # Permet l'authentification de Semantic Release
run: npx semantic-releaseCes jobs vont être déclenchés suite à un push au niveau de la branche
main (vous pouvez également configurer la branche selon vos besoins). 
Pour plus d’informations sur le format du message de commit, visitez la documentation officielle de Semantic-Release.
Conclusion
Dans ce tutoriel, nous vous avons montré comment mettre en place un système de versionnage pour son projet avec Semantic Release. Nous avons également montrer comment créer une pipeline de CI/CD avec Github Actions pour tester la configuration mise en place.
Grâce à ces outils, vous pouvez facilement conserver la trace des différentes versions, commits ainsi que des releases, et ce, de manière automatisée.
Écrit par
Rayen Merghad
Rayen est notre DevOps Junior, il aime partager son savoir et pratiquer la callisthénie 🤩
