Introduction
Avoir une stratégie de versioning est un point primordiale pour nos applications. La gestion sémantique de version X(Major).Y(Minor).Z(Patch) est la stratégie la plus utilisée dans le développement informatique.
Elle propose un ensemble de règles faciles à comprendre au moment où il faut incrémenter le numéro de version.
En bref,
- vous passer de 1.3.1 → 1.3.2 lorsque vous ne publiez que des correctifs de bogues.
- vous passer de 1.3.1 → 1.4.0 lorsque vous ajoutez de nouvelles fonctionnalités.
- vous passer de 1.3.1 → 2.0.0 lorsque vous introduisez des modifications incompatibles avec les versions antérieures.
En déploiement continu, chaque commit est une “release candidat”. Donc potentiellement, une nouvelle version de notre produit. Et comme le principe de base de déploiement continu est l’automatisation, on délègue le changement de version à l’outil de construction (Jenkins, Maven, …).
Solutions courantes
Incrémenter le Z
Certains outils de construction, comme Maven, propose des fonctionnalités pour incrémenter la version courante. C’est à dire :
- vous passer de 1.3.1 → 1.3.2 lorsque vous ne publiez que des correctifs de bogues.
- vous passer de 1.3.1 → 1.3.2 lorsque vous ajoutez de nouvelles fonctionnalités.
- vous passer de 1.3.1 → 1.3.2 lorsque vous introduisez des modifications incompatibles avec les versions antérieures.
Finalement, on se trouve avec une séquence de numéro qui n’a aucune signification.
Ajouter le numéro de construction
Il est possible d’utiliser le numéro de construction (numéro de build) comme numéro de patch.
L’inconvénient majeur est qu’on est trop lié au système de construction. Si on souhaite passer de Jenkins à gitlab-ci ou si on perd notre Jenkins, l’indicateur de build sera remis à 0. Un autre inconvénient, le patch ne sera jamais remis à 0 même si on change le major et le minor.
Ajouter le numéro court du commit
Afin de garantir l’unicité d’une version, surtout pour les snapshots, il est possible d’ajouter le numéro du commit lors de la construction du livrable. L’inconvénient de cette stratégie est la perte la lisibilité car il n’y a plus d’ordre chronologique. On ne peut pas savoir à première vue quelle version entre 1.3.2b49af6 et 1.3.5e75973 précède l’autre.
Utilisation des tags git
L’idée est de laisser le développeur fixer les parties major et minor de la version et le système de build fixe la partie patch en se basant sur les tags git. Par exemple, la version définie dans le code source est 1.3. Le système de build va chercher tous les tags qui commence par 1.3 et incrémente le patch le plus grand.
En pratique
Un exemple d’utilisation de cette stratégie est disponible dans notre github. En fait, il s’agit d’un fork du projet spring-petclinic, dans lequel on a ajouté un Jenkinsfile qui fait appel à notre jenkins shared library.
Conclusion
Seul un humain peut évaluer le contenu d’un commit et par la suite attribuer une nouvelle version à son application. Cependant, un des principes de déploiement continue est “Automatiser autant que possible”.
Pour cela nous proposons une solution mixte où le développeur définit la partie sémantique de la version et le système de construction incrémente la partie patch.
Enfin, il existe d’autres solutions afin d’automatiser à 100% la gestion des version en se basant sur le message du commit ou le nom de la branche.
