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
Dans le domaine de la data, la qualité de la donnée est primordiale. Pour s'en assurer, plusieurs moyens existent, et nous allons nous attarder dans cet article sur l'un d'entre eux : tester unitairement avec Pytest.
Le domaine de la data est présent dans le quotidien de chacun : la majorité de nos actions peut être traduite en données. Le volume croissant de ces données exploitables a un nom : "Big Data". Dans cet article, nous verrons comment exploiter ce "Big data" à l'aide du framework Apache Spark.
Découvrez Crossplane, un outil open-source qui étend Kubernetes avec des concepts de platform engineering et permet de gérer le cycle de vie de vos ressources cloud dans une boucle de réconciliation.