4 minutes

Lorsque vous développez vos projets en suivant les méthodes DevOps, vous savez qu’un des objectifs de cette culture est d’automatiser le plus de processus possibles. En utilisant des conventions de commits et en gérant de manière sémantique vos versions, vous pouvez automatiser le versioning de vos logiciels, ainsi que la mise en forme des notes associées aux versions ! Voyons comment cela fonctionne.

Qu’est-ce qu’une gestion sémantique de version ?

Gérer vos versions de manière sémantique va vous sembler plutôt évident. D’ailleurs, vous utilisez très probablement une méthode similaire à celle que nous allons vous présenter ! 

Les bénéfices pour vos équipes projets

En utilisant une gestion sémantique de vos versions, vous assurez qu’elles auront toutes du sens et de l’intérêt pour vos utilisateurs. La communication au sein de vos équipes et avec de potentiels contributeurs sera simplifiée et gagnera en efficacité.

Quelle nomenclature utiliser ?

La nomenclature présentée ci-dessous est la plus commune. Avec elle, votre version se compose de trois informations, notées X.Y.Z.

X correspond à des changements majeurs, ceux qui ne sont pas rétrocompatibles avec votre logiciel. Y correspond aux changements mineurs, ceux qui sont rétrocompatibles avec votre application. Enfin, Z correspond au patch, c’est-à-dire à toutes les corrections de bug qui n’affectent pas votre solution finale. Ces trois lettres sont représentées par des nombres grandissant à chaque modification.

Il existe quelques règles à respecter :

  1. Toutes vos versions doivent contenir une information sur les modifications majeures, mineures et les patchs (donc les 3 lettres X.Y.Z).
  2. Les nombres ne peuvent que grandir. Les informations concernant les modifications patchs et mineures commencent de 0, et les modifications majeures partent de 1 (sinon on parle de version bêta ou alpha).
  3. Quand une version mineure est publiée, le numéro de patch repart de 0.

Par exemple : 3.2.1 – 3.2.2 – 3.3.0 – 3.3.1

  1. La même règle s’applique pour les versions mineures et patchs lors de la publication d’une version majeure.

Par exemple : 3.2.1 – 3.2.2 – 3.3.0 – 3.3.1 – 4.0.0 – 4.0.1 

  1. Une fois une version publiée, il ne faut pas faire de retour en arrière sur votre produit.

Qu’est-ce qu’une convention de commits ?

Les conventions de commits sont utilisées dans votre git flow. Lorsque vous travaillez sur votre branche de développement et souhaitez que votre collège fasse un retour sur votre travail, ce sera plus simple pour lui de comprendre ce que vous avez développé si votre historique de commits est clair !

Les bénéfices pour vos équipes projets

En utilisant des conventions de commits, tous les membres du projet écriront leurs commits de la même manière. La communication dans votre équipe sera donc améliorée ! Cela se ressentira également dans les contributions : il sera plus simple pour quelqu’un arrivant dans le projet de comprendre ce qui a déjà été réalisé. Enfin, une fois que vous utilisez des conventions de commit, vous pourrez générer automatiquement les notes de déploiements de votre projet, et ainsi gérer dynamiquement vos versions ! 

Comment construire vos commits ?

Il existe plusieurs manières de rédiger vos commits. Nous vous présentons ici la convention de commit V1.0.0 ! En suivant ces étapes, vous ajouterez de nombreuses informations dans vos descriptions de commit, donnant ainsi du sens aux informations accessibles au reste de l’équipe.

Si vous respectez les règles de cette convention, vos commits seront rédigés de la manière suivante : 

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit construit en suivant la convention de commits

Le type correspond à l’action qui a été réalisée dans le commit. Habituellement, vous trouvez ici l’indication fix: ou feat: (pour feature). Bien entendu, il existe de nombreux autres types, tels que : build:, chore:, ci:, docs:, style:, refactor:, perf:, ou encore test:. Cette liste n’est pas exhaustive, vous pouvez créer autant de types que vous le souhaitez pour répondre aux besoins de votre projet.

Lorsque vous utilisez cette convention, le type que vous ajoutez à votre commit va donner du contexte au reste de l’information. Fix: fait référence à une version avec modification du patch. Feat: indique des modifications mineures dans votre version.

Enfin, vous pouvez ajouter un point d’exclamation (!) juste après le scope, symbolisant ainsi une modification majeure. En indiquant le titre “Breaking changes” dans le footer, vous renforcerez le point d’exclamation.

Dans le scope, vous pouvez ajouter des informations sur la feature qui sera affectée par les changements effectués dans le commit. Enfin, vous pouvez compléter le tout en apportant des informations complémentaires dans la description. Attention cependant, il ne s’agit pas ici de répéter le scope ou le type !

Comment combiner les deux systèmes ?

Pour combiner les nomenclatures de version et les conventions de commit, vous pouvez utiliser un outil spécifique, qui fera le lien entre les deux. Chez Go2Scale, nous utilisons le job Semantic Release

Vous pouvez l’ajouter directement dans votre pipeline de CI/CD à l’aide d’une seule ligne de code. Une fois fait, ce job créera une nouvelle version (et sa documentation) de votre application ou développement à chaque fois que votre pipeline se déclenchera.

Pourquoi associer conventions de commit et nomenclature de version ?

Ces deux pratiques sont un réel plus pour les processus DevOps. Vous incorporerez les bénéfices des deux systèmes dans vos développements, et automatiserez la création des versions et des changelogs de votre projet, sans ajouter du travail à vos équipes, seulement des procédures !