Votre application est prête à être livrée. Pour cela, vous avez besoin de marquer votre application avec un numéro de version. Une convention permet de faciliter le suivi de version : Gestion sémantique de version.
La livraison de la version 1.0.0 s'est déroulée avec succès. Maintenant, vous avez besoin d'ajouter de nouvelles fonctionnalités. Il faudra donc incrémenter le numéro de version.
Deux options possibles :
Voyons donc comment automatiser ce processus afin de gagner en efficacité.
Afin d'automatiser le processus de marquage des versions, nous allons nous référer à l'historique des commits du dépôt Git. Une nouvelle version d'une application peut se définir par un ensemble de commits entre la précédente version et la tête de la branche principale.
Nos commits doivent respecter une convention. Pour cela, nous allons utiliser Commits Conventionnels.
Pour simplifier, un commit commençant par :
Une fois que nos commits respectent la nomenclature défini par Commits Conventionnels, nous pouvons utiliser un outil pour effectuer le différentiel de version : semantic-release.
commitlint va lire le message de commit et faire respecter la nomenclature Commits Conventionnels.
Cela nécessite quelques configurations.
Tout d'abord, il faut créer un fichier .commitlintrc.yaml avec le contenu suivant :
extends: - "@commitlint/config-conventional"
Cette configuration permet d'indiquer à commitlint d'utiliser les commits conventionnels.
Dans le fichier .gitlab-ci.yml, ajoutons une tâche pour tester le message de commit.
stage: - tests lint:merge_request_title: image: dockerhub.ftven.net/node:lts stage: tests before_script: - npm install @commitlint/{cli,config-conventional} script: - echo "${CI_COMMIT_MESSAGE}" | npx commitlint
Alternatif
Dans le cas d'une merge request, il est possible de vérifier uniquement le titre de la merge request. Ce cas de figure fonctionne bien dans le cas où la branche est fusionnée et squash vers la branche principale.
Pour cela, utiliser la variable Gitlab $CI_MERGE_REQUEST_TITLE.
semantic-release va automatiser ce processus de marquage d'une version d'une application.
Cela nécessite quelques configurations.
Tout d'abord, il faut créer un fichier .releaserc.yml avec le contenu suivant :
plugins: - - "@semantic-release/commit-analyzer" - preset: "conventionalcommits" - - "@semantic-release/release-notes-generator" - preset: "conventionalcommits" - "@semantic-release/gitlab" branches: - "main"
Cette configuration ajoute deux modules pour utiliser les commits conventionnels, et un troisième pour s'intégrer avec Gitlab.
Enfin, la branche de référence en main dans notre cas.
Dans le fichier .gitlab-ci.yml, ajoutons une tâche pour générer le prochain numéro de version.
stage: - release release: image: dockerhub.ftven.net/node:lts stage: release variables: GITLAB_TOKEN: ${RELEASE_TOKEN} before_script: - npm install semantic-release @semantic-release/gitlab conventional-changelog-conventionalcommits script: - npx semantic-release rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH when: manual
Prévisualiser le contenu de la prochaine version
Le jeton RELEASE_TOKEN est créé en suivant la documentation suivante https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html
Lors de la prochaine exécution du pipeline Gitlab CI, une tâche release va apparaître. Elle sera en attente d'une action utilisateur. Une fois que l'utilisateur a validé, la nouvelle version est créée et publiée dans Gitlab (voir documentation : https://docs.gitlab.com/ee/user/project/releases/).
Félicitation, vous avez automatisé la création d'une version de votre application. Prenez une boisson chaude pour vous détendre.
Auteur(s)
Thierry T.
Super Data Boy
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
Il arrive qu'une fonction ou action ne puisse pas être réalisée à un instant donné. Cela peut être dû à plusieurs facteurs qui ne sont pas maîtrisés. Il est alors possible d'effectuer une nouvelle tentative plus tard. Dans cet article, voyons comment le faire.
Le formatage du code est une source de querelle entre les membres d'une équipe. Résolvons-le une bonne fois pour toute avec le formateur de code Black.
Après avoir développé une nouvelle fonctionnalité pour votre application, le code est revue par l'équipe. Pour que le relecteur puisse mieux se rendre compte des changements, il est intéressant de mettre les changements à disposition dans un environnement de revue. Cet article va expliquer les étapes pour le faire avec Gitlab CI.