La gestion du développement avec semantic-release

La gestion des versions pose souvent des difficultés, en particulier pour les projets impliquant des mises à jour fréquentes et différents intervenants. L’implémentation d’un flux de travail optimisé avec semantic-release a pour effet de simplifier le processus de validation et d’assurer un versionnage et une distribution cohérents.

semantic-release est un outil open source populaire utilisé pour automatiser le versionnage et la publication d’applications logicielles. Il reprend les principes du versionnage sémantique, dans lequel les numéros de version livrent des informations sur les changements de code. Grâce à semantic-release, les développeur·euse·s peuvent se concentrer davantage sur l’écriture de code sans avoir à se soucier autant de la gestion des versions.

Le flux de travail

Considérons l’ensemble d’un peu plus près. Nous commencerons par une brève introduction du sujet, avant de montrer les problèmes que semantic-release permet de résoudre. Lorsque l’on travaille sur un projet de logiciel avec plusieurs développeur·euse·s et des mises à jour fréquentes, il est indispensable d’adopter un processus de publication standardisé. La gestion manuelle des numéros de version, la création de change logs et la publication sur plusieurs canaux de distribution peuvent prendre énormément de temps et entraîner des erreurs. semantic-release résout ce problème en automatisant des tâches à l’aide de règles prédéfinies et de conventions de message d'engagement.

Pour illustrer le flux de travail, nous prendrons l’exemple d’un projet de package de nodes. Ce projet respecte les conventions Git Branching, les différentes branches représentant ainsi les différents stades de développement. Nous avons des branches « feature » ou « fix » pour le développement en cours, une branche « next » pour la préparation de la prochaine version et une branche « main » pour la version de production stable. Il est également courant d’utiliser une branche « develop », mais dans notre cas, nous pouvons simplement installer une version pré-release publiée comme dépendance dans nos autres applications.

Configurer un projet

Avant de configurer semantic-release pour notre projet de node package, nous devons installer les dépendances nécessaires. Nous utilisons l’outil « npm » pour exécuter la commande suivante :

npm install semantic-release @semantic-release/changelog @semantic-release/git

Nous configurons ensuite semantic-release en créant un fichier release.config.js dans le répertoire racine du projet. Ce fichier de configuration spécifie les règles de publication, les plug-ins et autres paramètres spécifiques au projet.

Pour utiliser l’assistant de configuration et la configuration elle-même, il faut utiliser la commande suivante :

semantic-release-cli setup

Voici un exemple de configuration de release.config.js :

module.exports = {
  branches: [
    'main’,
    { name: 'next', prerelease: true },
    { name: 'develop', prerelease: 'beta' },
  ],
  plugins: [
    '@semantic-release/commit-analyzer',
    '@semantic-release/release-notes-generator',
    '@semantic-release/changelog',
    ['@semantic-release/git', {
      assets: ['CHANGELOG.md'],
    }],
    '@semantic-release/npm',
  ],
};

Il est également possible d’utiliser un fichier releaserc. Dans ce cas, la configuration serait la suivante :

{
  "branches": [
    "main",
    { "name": "next", "prerelease": true },
    { "name": "develop", "prerelease": "beta" },
  ],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/npm",
    [
      "@semantic-release/git",
      {
        "assets": ["package.json"],
        "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
      }
    ]
  ]
}

Dans cette configuration, trois branches sont définies : « main » pour les versions stables, « next » pour les pré-versions et « develop » pour le développement en cours. D’autre part, on définit les plug-ins nécessaires à l’analyse des engagements, à la création des notes de version et des change logs, à la publication sur GitLab et à la publication sur « npm ».

Une fois la configuration de semantic-release achevée, il est possible d’utiliser les commandes permettant d’automatiser la gestion de publication. Voici les commandes semantic-release les plus utilisées :

semantic-release

Cette commande engage le processus de diffusion. Elle analyse l’historique des engagements, détermine la version appropriée en fonction des règles de versionnage sémantique, génère des notes de version et des change logs, met à jour la version du package et publie la version sur le canal de distribution indiqué.
En règle générale, on procède à un test avant la publication. Pour cela, on utilise l’option « --dry-run » après la commande ou on attribue la valeur « true » à la propriété dryRun dans la configuration ci-dessus.

semantic-release-cli setup

Cette commande mène vers un assistant de configuration qui aide à créer le fichier « release.config.js » et à configurer semantic-release pour le projet.

Configurer l’intégration continue

En plus des commandes, l’intégration de semantic-release avec Continuous-Integration (CI) améliore encore davantage le processus d’automatisation des diffusions. En déclenchant semantic-release pour certains événements – par exemple le déplacement de modifications vers certaines branches ou la fusion de pull requests – on peut être sûr que les diffusions seront automatiquement déclenchées et mises à disposition.

Si on utilise par exemple des services de CI courants tels que Travis CI ou GitHub Actions, il est possible de configurer le pipeline de CI de sorte que la commande semantic-release soit exécutée sur les branches correspondantes après des builds réussis. Ainsi, semantic-release sera déclenché chaque fois que de nouvelles modifications sont enregistrées, ce qui a pour effet d’automatiser le processus de diffusion.

De plus amples informations sur la configuration avec différents services CI sont disponibles dans la documentation semantic-release.

Une fois la configuration achevée, semantic-release analyse automatiquement les engagements, détermine la prochaine version appropriée en fonction des règles de versionnage sémantique, crée des notes de version et des change logs, met à jour la version du package et publie la version via les canaux de distribution spécifiés.

Conclusion

On peut dire que la mise en place d’un flux de développement avec semantic-release permet d’automatiser et de simplifier les processus de diffusions complexes dans le cadre de projets logiciels. Une fois configuré, semantic-release prend en charge la gestion des versions, la création de change logs et la publication. De cette manière, les développeur·euse·s peuvent se concentrer sur l’écriture du code et assurer un cycle de diffusion fluide.

Cet exemple montre comment semantic-release est configuré pour un exemple de projet et les avantages qu’il présente pour la gestion de flux de travail complexes pour la diffusion. En respectant les conventions et les meilleures pratiques de semantic-release, il est possible d’améliorer considérablement le processus de développement et de fournir sans problème des logiciels de qualité.

Il ne faut pas oublier toutefois que la configuration doit être adaptée aux contraintes spécifiques du projet et aux canaux de distribution. L’intégration de semantic-release à la boîte à outils de développement permet de rendre les processus de diffusion plus efficaces, plus uniformes et plus fluides.

La documentation de semantic-release contient des informations et des instructions complémentaires pour répondre à différentes configurations et utilisations.