Gestions des numéros de version avec SVN

Le but de cet article est d’expliquer comment gérer les versions successives d’une application avec SVN. Par « gérer les versions », j’entends gestion des différents tags, branches de maintenances, merge, … Je vais m’appuyer sur SVN tout au long de cette article, mais tout ceci est également valable pour Git (bien que Git facilite grandement certaines des opérations à effectuer !)

Principe de la numérotation des versions

Il y a beaucoup de manières de numéroter un projet. Mais la façon la plus habituelle est généralement d’utiliser trois chiffres séparés par des points X.Y.Z :
– Le premier chiffre représente un changement majeur dans l’application. Mais cette notion de « majeur » est déjà très subjective : une refonte technique du logiciel (migration de technologies, refonte du modèle de données, …) pourra être considérée comme majeure par les développeurs, mais comme mineure par un utilisateur, car elle n’apporte aucune modification sur les fonctionnalités. Une bonne pratique consiste à réserver ce numéro pour les évolutions fonctionnelles de l’application.
– Le second chiffre correspond à des évolutions mineures : ajout de fonctionnalités, modification de quelques aspects d’ergonomie, …
– Le troisième chiffre correspond généralement à des corrections d’anomalies, des patchs, ou des refactors techniques.

Voilà pour la théorie. Le cœur du sujet de cet article repose sur la gestion de ces numéros de version à travers SVN.

Gestions des versions dans le développement d’une application

A l’issue d’un développement (par exemple on termine la version 1.3.0), on pose souvent un tag sur la version stable du tronc afin de pouvoir figer les sources au moment d’une livraison, et de pouvoir y revenir par la suite. Le nom de ce tag contient généralement le numéro de la version : « application-1.3.0-DATE ».

Peu après, une anomalie est remontée. Il faut donc la corriger. Mais où ? Si aucune évolution n’est prévue, on peut continuer à utiliser le tronc de l’application pour la corriger. On va alors taguer une version « application-1.3.1-DATE » avec le correctif. Mais l’idéal est, comme nous le verrons par la suite, de créer une branche de maintenance.

On souhaite maintenant poursuivre les développements de l’application et ajouter de nouvelles fonctionnalités qui restent relativement mineures. Là se pose la question : je pars sur une version 1.3.2 car c’est mineur, ou alors sur une version 1.4.0 mais qui apportera seulement de faibles évolutions ?

Si ces fonctionnalités demandent du développement, il n’y a pas à hésiter : il faut créer une version 1.4.0 ! Pourquoi ? Parce que s’il survient une anomalie sur la version 1.3.1 qu’il faut corriger en urgence, où va-t-on la faire ?

Si on a réservé la version 1.3.2 pour nos évolutions mineures, il faudra nécessairement que le correctif soit ajouté dans cette version, et il faudra attendre que celle-ci soit terminée pour que l’utilisateur puisse profiter de la correction de son anomalie. Si en revanche les développeurs travaillent sur un tronc qui va vers une version 1.4.0, il est toujours possible de créer une branche à partir de la version 1.3.1 pour effectuer la correction demandée, la déployer pour l’utilisateur, puis la fusionner avec le tronc pour que ce correctif soit également intégré dans la version 1.4.0.

Il faut toujours penser que le troisième chiffre, dans cet exemple, représente un patch, et doit donc être réservé pour la correction d’anomalies.

Gestion des versions avec SVN

Voyons maintenant comment tout ceci se passe côté SVN, et comment gérer concrètement cette numérotation de versions.

Je développe ma nouvelle version seul (le rectangle blanc représente mon répertoire local) :

svn-1

Je suis rejoint par un autre développeur :

svn-2

Petit à petit, les versions et corrections avancent :

svn-3

Je dois travailler sur ma version 1.3.0. Je pourrais travailler sur le tronc et laisser les corrections de la version 1.2 se faire sur des branches, mais par précaution, je crée une branche de développement pour ma nouvelle version afin de garder un tronc toujours en phase avec la dernière version du logiciel.

svn-4

Je pars sur ma version 1.4.0 avec de nouvelles fonctionnalités. Je crée alors une nouvelle branche (branche de maintenance) pour corriger les anomalies qui vont remonter sur ma version 1.3.0.

svn-5

On a l’impression que les branches vont se multiplier, mais finalement, il n’y en a que deux :
– La branche de maintenance sur laquelle je gère mes corrections d’anomalies et qui va finalement s’occuper d’incrémenter le troisième chiffre de mon numéro de version
– La branche de développement sur laquelle je développe mes nouvelles fonctionnalités et donc qui gère le second chiffre de mon numéro de version.

Bonne pratique de gestion de versions SVN

Voici quelques bonnes pratiques de travail avec SVN (les principes généraux sont bien sûr transposables à Git).
– Updater régulièrement, et surtout toujours avant de commiter.
– Ne pas commiter sur un tag. Il peut être tentant de faire un correctif rapide sur un tag pour ne pas avoir à créer de nouvelles versions du logiciel, mais il sera généralement préférable d’éviter et d’inclure ces corrections dans une nouvelle version.
– Limiter le nombre de branches. Mais si les branches sont de bonnes pratiques, leur surnombre complexifie grandement la gestion des versions et des merge. Particulièrement sur SVN, les merge ne sont pas toujours faciles à réaliser, donc c’est une manipulation à faire avec précaution.
– A chaque tag posé sur le tronc, penser à mettre à jour toutes les branches actives avec ces modifications du tronc (merge du tronc vers la branche). Il faut cependant étudier au préalable que la branche peut recevoir l’évolution du tronc, ce n’est pas toujours le cas !
– Lorsque l’on pose un tag sur une branche de maintenant (1.3.1, 1.3.2, …) il est bon de reporter ce tag sur le tronc en indiquant qu’il s’agit d’un tag de merge : merged-1.3.1, merged-1.3.2.
– Lorsqu’on crée une branche de maintenant, on la nomme X.Y.x ou x correspond à la succession des évolutions de cette branche (voir image ci-dessous).

svn-6

Conclusion

La gestion des numéros de version d’une application est dans la théorie assez simple (X.Y.Z), mais dans la pratique, ce n’est pas si facile à mettre en œuvre. Lorsqu’on se retrouve à devoir travailler sur une nouvelle version d’une application, sur la correction d’anomalies et sur des tests pour une future évolution innovante, cela se traduit pas la gestion à la fois du tronc, d’une branche de maintenance, d’une branche évolutive, d’une branche de test d’innovations, et des répertoires locaux de chaque utilisateur. Il est alors nécessaire de mettre en place dès le début du projet de bonnes pratiques pour faire coexister l’ensemble de ces lignes de gestions de versions, et de bien décider comment on va incrémenter les différentes versions de l’application.

Sources :
Versions d’un logiciel : http://fr.wikipedia.org/wiki/Version_d%27un_logiciel
Gestion des versions avec SVN : http://www.geek-directeur-technique.com/2009/03/31/gestion-de-sources-versions-de-logiciels

VN:R_U [1.9.22_1171]
Rating: 0 (from 0 votes)
Share
Ce contenu a été publié dans Non classé. Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire