Sans cette identification, il est difficile de communiquer avec les différents acteurs d'un projet : les développeurs, les testeurs, jusqu'aux utilisateurs finaux.
En conventionnant le nommage, on assure une compréhension plus rapide de l'état d'un projet.
For an english version of this article, follow this link : http://antoine-agthe.blogspot.com/2013/02/naming-convention-for-software-version.html
Sortir de la logique du service de versioning
Il est facile de céder à la tentation de communiquer sur des numéros de versions calqués sur le service de versioning. Si vous utilisez SVN par exemple, vous seriez tenter d'utiliser les numéros de révisions.
C'est une fausse bonne idée. En effet, cette logique semble pertinente jusqu'au moment où vous déciderez de faire évoluer votre système de versioning vers Mercurial, Git, ou Perforce, perdant au passage les numéros de révisions.
Proposition de convention
La convention que je décris n'est ni la plus pertinente, ni la meilleure, ou la plus facile à maintenir. Elle est le fruit d'une expérience personnelle et fonctionne dans la plupart des cas, mais peut tout à fait être remise en question. Elle peut aussi être une base sur laquelle vous bâtirez votre propre convention.Logique du nommage incrémental
Pour nommer les versions de logiciel, j'utilise la forme M.F.R[.T]. On peut utiliser une forme à trois valeurs, mais la logique incrémentale doit être complexifiée si on veut pouvoir identifier facilement les versions de test et les versions exploitables en production.
M est le numéro de version Majeure. Ce niveau de numérotage a une dimension tant technique que marketing, car communiquer sur un changement de version majeure est toujours plus attractif.
Son incrémentation est le signe de changements importants au niveau fonctionnel de l'application, souvent (mais pas toujours) signe d'une incompatibilité avec les versions précédentes.
F (comme Fonctionnalités) est le numéro de version mineure. À ce niveau, on communique sur l'ajout ou la modification d'une, ou plusieurs fonctionnalités, des changements qui assurent toutefois bien souvent une rétrocompatibilité avec les versions mineures, de la même version majeure.
R est le numéro de Révision. C'est un niveau qui n'a qu'une dimension technique. Il sert à indiquer des corrections de bugs, des optimisations de codes. Les révisions d'une même version mineure doivent être compatibles entre elles sur le plan des fonctionnalités, au delà de la correction des bugs.
T est le numéro de Tag. C'est un niveau réservé aux équipes de développement afin d'identifier les versions testables. Ce qui veut dire qu'une version exploitable en production n'aura pas ce numéro.
Exemple
La logique est la suivante :- Nous sommes au début du projet. Tout est à faire. La version du logiciel serait donc théoriquement 0.0.0.0, mais cette version n'a aucune raison d'exister, car aucun code ou autre élément n'a encore été produit.
Le plan définit un ensemble de fonctionnalités à développer pour constituer une version 1.0.0 communicable aux utilisateurs finaux (et non 1.0.0.0) - Les équipes commencent à développer les différentes briques du logiciel. Quand une première version est testable, on marque l’évènement en créant une version.
C'est la version 0.0.0.1.
Cette version indique que du développement a été réalisé depuis la version précédente (la 0.0.0.0), que les développeurs ont réalisé les tests techniques de premier niveau (typiquement les tests unitaires), et qu'il doit être réalisé un test fonctionnel. - Cette version 0.0.0.1 est donc testée, et deux issues sont possibles : les tests valident, ou invalident la version.
- En cas de validation, une nouvelle version de logiciel sera créée. Le tag est supprimé, car les fonctionnalités de cette version sont exploitables.
- Si les développements ont aboutis à une mise à jour fonctionnelle, on incrémente la version mineure et on remet la révision à zéro.
On sera donc à la version 0.1.0. - Si c'est une mise à jour technique, on passe à la révision suivante.
On sera donc à la révision 0.0.1. - En cas d'invalidation, les développeurs doivent prendre en compte les modifications à réaliser, et à l'issue de ces corrections, une nouvelle version de test est produite.
Ce sera la version 0.0.0.2. - Quand l'ensemble des fonctionnalités prévues est développé et testé, on incrémente le numéro de version majeure, et on remet à zéro les deux autres numéros.
La version 1.0.0 est créée. - La suite du développement suit la même logique.
Le cas de Subversion
C'est grâce aux tags que l'on va pouvoir créer des versions. Grâce à cette fonctionnalité, on peut très rapidement, depuis un numéro de révision SVN (à ne pas confondre avec le numéro de révision logiciel) créer un snapshot du projet. Cette dimension d'instantané dans le temps convient bien à l'idée qu'une version de logiciel doit être fixée au niveau fonctionnel comme au niveau technique.
Les branches vont nous servir à deux choses.
La première est utile quand il faut faire vivre et évoluer plusieurs versions d'un même logiciel en même temps. Ainsi, on peut créer une branche v1.x, une branche v2.x, ou même plus précisément une branche v1.3.x, etc. De cette manière, on peut intervenir à plusieurs niveaux dans le code pour corriger des bugs ou améliorer les performances d'une version précise du logiciel. Le développeur n'a qu'à switcher d'une branche à l'autre pour intervenir sur le code.
La deuxième utilisation possible des branches est de créer une version de travail pour ne pas perturber le développement collaboratif tout en permettant la sauvegarde du code.
J'estime que les services de versioning n'ont pas pour objectif de protéger le développeur d'une panne matérielle ou d'une destruction de données. Il existe d'autres services pour ça. Cependant, j'avoue également qu'il est assez pratique de sauver son travail dans une branche personnelle, même si le code n'est pas compilable, car ça limite le nombre de services à gérer.
Aucun commentaire:
Enregistrer un commentaire