Les versions

05/04/2013 09:00

Venant d'un univers où les progiciels sont commercialisés à plusieurs centaines d'exemplaires je suis assez sensibilisé au "versioning" (ou versionage) des produits.

 

Ma manière de voir les choses :

 

Dès lors qu'il y a la moindre modification, ne serait-ce qu'un accent ajouté dans un message d'info ou le déplacement d'un champ d'un pixel il faut faire une nouvelle version. Bien entendu on ne fera une nouvelle version que si le logiciel doit être installé.

 

Il faut faire la distinction entre versions mineures et versions majeures : l'une étant la correction de quelques bugs, l'autre comportant des ajouts fonctionnels. L'une étant livrable dans la journée, l'autre à plus ou moins long terme.

 

A mon avis la modification d'analyse doit être facilement détectable par rapport au changement du numéro de version.

 

Proposition de norme :

 

"1.02A09"

 

1 : Le premier numéro correspond à une très grosse évolution, voir un changement radical : par exemple changement de charte graphique ou d'ergonomie.  

 

02 : Modification de l'analye : la moindre zone ajoutée, la moindre relation modifiée doit faire l'objet d'un incrément de ce numéro.

 

Pourquoi ? Ca permet ainsi de savoir que toutes les versions 1.02 seront compatibles entre elles, qu'on pourra installer une 1.02G01 à la place d'une 1.02B04 sans problème sur les données. Si on installe une 1.03 une modification de structure se fera et on ne pourra plus installer une 1.02. Si on installe une 1.01 ça ne fonctionnera pas parce que l'analyse sera déphasée. Ce "truc" permet notamment de simplifier la vie des installateurs/formateurs.

 

A : Version majeure : par exemple ajout d'un nouvel état, d'un nouveau module, redéveloppement d'une fenêtre de gestion, etc...

 

09 : Versions mineures ou correctives : uniquement corrections, pas d'évolutions dans le logiciel.

 

Pourquoi formatter les numéros avec 2 chiffres (02 ou 09) ? Tout simplement pour le classement des versions sous forme alphanumérique.

 

Bien entendu ce n'est qu'une proposition, il y a possibilité de faire autrement, mais cette manière de qualifier les parties d'un numéro de version permet de s'y retrouver plus facilement et de faciliter le travail des personnes sur le terrain.

 

Faire le "grand écart" :

 

Imaginons le cas suivant : j'ai planifié une version majeure 1.03B01 qui doit sortir dans trois mois.

La version en cours chez les clients est la 1.03A07.

Un client m'appelle et a trouvé un bug qui le bloque. Ce n'est pas grand chose à corriger et je ne vais pas attendre la sortie de la grosse version 1.03B01 pour le dépanner. Je vais donc créer une version 1.03A08.

Mais attention, il va falloir que je reporte cette modification à la virgule prêt sur la version majeure !

Et plus la date de livraison de la grosse version sera éloignée, plus il y aura de chances pour que l'on fasse des corrections "en parallèle" sur les deux projets.

 

A mon avis il n'y a pas de solution miracle, il faut juste respecter quelques règles pour ne pas perdre pied :

 

• Toujours n'avoir qu'une seule version majeure en cours. Eviter de devoir livrer en urgence une version non terminée sous la pression. A tous les coups ça donne naissance à des "sous-versions" qu'il faudra maintenir ... et donc sur lesquelles on devra reporter les modifications de toutes les autres versions : cauchemar assuré !
• Faire autant de versions mineures (ou correctives) que nécessaires, même s'il n'y a qu'un tout petit "machin" à corriger.
• Reporter TOUT DE SUITE la modification de la version mineure sur la version majeure, quitte à devoir interrompre le travail de ceux qui bossent sur cette version.

 

Penser à archiver :

 

Dès qu'une version est validée il faut l'archiver, que ce soit sous forme de ZIP ou dans des branches dans le GDS. Dès lors la moindre modification apportée au projet fera l'objet d'une nouvelle version. Ca prend le temps d'aller boire un café.

 

Outil comparatif :

 

Il y a un outil bien pratique dans WD qui permet de comparer des projets : Fichier / Comparaisons / Comparer deux projets

Si vous devez faire tester votre application par une autre personne n'hésitez pas à éditer ce dossier comparatif (en y mettant éventuellement vos anotations).

N'hésitez pas non plus à l'éditer pour vous afin de contrôler que vous n'avez rien oublié (par exemple report de corrections d'une version à l'autre).

 

Un exemple :  sur une version mineure j'ai dû intervenir à trois endroits : déplacement d'un champ sur une fenêtre, modification d'une clause de requête et correction d'un alogorithme. Ces trois modifications apparaissent dans le dossier avec leur contexte d'exécution (par exemple algorithme exécuté lors du clic sur du bouton "Go"). La personne qui teste saura exactement ce qu'il faut vérifier et contrôler.

 

NOTE : attention les modifications d'analyse ne sont pas visibles avec cet outil. Pour ça, aller dans : Analyse / Gestion des versions.