Bandeau
PL Conseil - Audit et accompagnement des entreprises
PL Conseil - Notre mission : Accompagner les entreprises en difficulté ou souhaitant se développer

PL Conseil accompagne l’Entreprise dans toutes les étapes de ses projets, de l’audit à la formation en passant par la rédaction du cahier des charges et le suivi de la mise en œuvre. PL Conseil - Chef de projet - Consultant - Assistance et conseil - Formation gestion du temps des priorités et du stress - QVT - Brainstorming - SQL - SQL Server

logo article ou rubrique
Gestion de projet : La gestion des versions logicielles
Article mis en ligne le 1er décembre 2014
dernière modification le 13 mars 2019
Noter cet article :
1 vote

Comment gérer la version d’un logiciel ?

Le "versionning" ou "la gestion du numéro de version d’un logiciel" est le fait d’attribuer un code unique à la version d’une application.
Tout au long de la durée de vie d’un logiciel, les évolutions et les correctifs seront identifiés et associés à ce code.
Il existe plusieurs méthodes permettant de gérer ces codes de versions :

  • le versionning simple,
  • le versionning étendu.
  • la gestion du cycle de vie.

1/ Le versionning simple : X.Y
Cette gestion simple est utilisable dans tous les projets.
X sera la "Version" (découpage fonctionnel dans lequel se trouve le logiciel à un instant T) et Y la "Révision" (état d’un lot fonctionnel).

  • La première version sera identifiée par le numéro 1.0 (version 1 révision zéro).
  • Lors de correctifs, si les fonctionnalités sont identiques, ce même lot sortira sous le numéro de version 1.1 (version 1 révision 1). Le numéro de révision sera incrémenté à chaque lot correctif.
  • La seconde version (release) officielle sortira sous le numéro 2.0 (même si la version 1 est en révision 1.6).
    Une variante intéressante de cette forme de versionning consiste à attribuer l’année en version et le mois en révision. Cette méthode permet un repérage rapide des fonctionnalités dans le temps. Par exemple, 14.08 est la version d’Août 2014.

Dans le cas de projets comportant de nombreuses fonctionnalités, il est possible d’utiliser un "versionning étendu" :

2/ Le versionning étendu : X.Y.Z
Le versionning étendu permet de différencier les lots d’évolutions en leur ajoutant une hiérarchisation.
X sera la "Version majeure", Y la "Version mineure" et Z la ’Révision’.
Le chef de projet fonctionnel effectuera ce découpage et la hiérarchisation des fonctionnalités.

3/ Cycle de vie d’une application : X-Y-Z-E
Afin d’identifier qu’une version n’est pas officielle et comporte des restrictions, ou un état dont la stabilité n’est pas garantie, Il est possible d’ajouter à son numéro de version un identifiant qui indique l’état d’avancement du cycle de développement.
Le numéro de version sera suffixé par un indicateur (état)
X sera la "Version majeure", Y la "Version mineure", Z la ’Révision’, E "l’état’
Exemples :

  • 1.6.1-dev Version en cours de développement. Généralement utilisée en interne.
  • 1.6.1-alpha Version en cours de développement. Les fonctionnalités ne sont pas toutes développées et peuvent contenir des bugs. Généralement utilisée comme POC (Proof Of Concept) afin de valider un fonctionnement général.
  • 1.6.1-beta Version en cours de développement. Les fonctionnalités sont presque toutes développées et peuvent contenir des bugs. Souvent utilisée pour une première campagne de tests en conditions réelles, notamment dans le cadre de beta private (nombre d’utilisateurs restreint).
  • 1.6.1-rc1 Version admissible ou "pre-release", (rc signifie ’release candidate’). Les fonctionnalités sont toutes développées mais peuvent contenir des bugs que la RC a pour but de corriger. Il y a souvent un versionning des RC (rc1, rc2, rc3, etc.).
  • 1.5.1-stable Version terminée et validée. Les fonctionnalités sont toutes développées et considérées comme stables (utilisables en production).

Une stratégie de gestion impactante et à définir au plus haut niveau :

La gestion de versions est effectuée par le chef de projet fonctionnel qui devra trouver un bon compromis dans le rythme des versions publiées, leurs tests et leur documentation, la communication et le planning éditorial.
La stratégie dépendra également du type de développement (client lourd avec installation de type client-serveur ou client léger, full web) et du mode de commercialisation (SAAS ou autre).
Il faudra ainsi définir une politique stricte de versionning, (est-il possible de gérer une version par client ? une version a chaque bug ? etc...).
Cette réflexion sera proposée par le chef de projet au Comité de Direction qui adaptera sa stratégie commerciale en fonction des décisions prises conjointement.


Les outils de gestion de versions :
Il existe de nombreux outils permettant de gérer les versions (SVN, SourceSafe, Git, RedMine, BugTacker, Endevor, une feuille Excel…). Le principe de base consiste à établir une liste des taches (Corrections ou évolutions) et à positionner en face, un numéro de version dans laquelle la tache sera réalisée. Ce principe est souvent complété de fonctionnalités plus ou moins complexes et utiles en fonction de la taille du projet. Certains de ces logiciels gèrent les taches dans leurs phases de développement.

Les logiciels de gestion de versions
Libres

  • Gestion locale GNU RCS (1982) · GNU CSSC
  • Client-serveur CVS (1990) · CVSNT (1992) · SVN (2000)
  • Décentralisé GNU arch (2001) · Darcs (2002) · DCVS (2002) · SVK (2003) · Monotone (2003) · Codeville (2005) · Git (2005) · Mercurial (2005) · Bazaar (2005) · Fossil (2007) · Veracity (2011)

Propriétaires

  • Gestion locale SCCS (1972) · PVCS (1985)
  • Client-serveur Rational ClearCase (1992) · CCC/Harvest (années 70) · CMVC (1994) · Visual SourceSafe (1994) · Perforce (1995) · AccuRev SCM (2002) · Sourceanywhere (2003) · Team Foundation Server (2005) · Rational Synergy (2006)
  • Décentralisé BitKeeper (1998) · Plastic SCM (2007)

Concepts

  • Branche · ChangeLog · Commit · Codage différentiel · Comparaison de fichiers · Changeset · Dépôt · Fork · Merge · Tag · Trunk


puceplan site puceContact puce RSS

2013-2019 © PL Conseil - Audit et accompagnement des entreprises - Tous droits réservés
Haut de page
Réalisé sous SPIP
Habillage ESCAL 4.3.16