Gestion de version

Gestion de versions

La gestion de versions (en anglais version control ou revision control) est une activité qui consiste à maintenir l'ensemble des versions ou révisions d'un logiciel ou autre document. Essentiellement utilisée dans le domaine de la création de logiciels, elle est surtout concernée par le code source ; mais elle peut être utilisée pour tout type de document informatique.

Cette activité étant fastidieuse et relativement complexe, un appui logiciel est presque indispensable. À cet effet, il existe différents logiciels de gestion de versions qui, bien qu'ayant des concepts essentiels communs, apportent chacun son propre vocabulaire et ses propres usages. À titre d'exemple, on trouve un mécanisme de gestion de versions dans Wikipédia : pour chaque article, l'historique est disponible en cliquant sur le lien Historique.

Les versions

Les logiciels évoluant, chaque étape d'avancement est appelée version. Les différentes versions sont nécessairement liées à travers des modifications.

Une modification peut correspondre à des ajouts, modifications, suppressions ou une combinaison des trois sur une version donnée. Schématiquement, on passera de la version N à la version N + 1 en appliquant une modification M. Un logiciel de gestion de versions nous aidera alors à soustraire la modification M de la version N + 1 pour retrouver la version N.

Les concepteurs du logiciel de gestion de versions RCS ont choisi de parler de « révisions » (revisions) afin de ne pas confondre la version du logiciel avec les « révisions » de ses fichiers sources.

Pour des raisons pratiques, on associe généralement un « numéro » à une version (voir Version d'un logiciel).

Modifications et ensemble de modifications

Une modification constitue donc l'évolution entre deux versions. On peut donc aussi bien parler de la différence entre deux versions que de modifications ayant amené à une nouvelle version.

On utilise généralement la gestion de versions à un ensemble de fichiers qui constitue un projet. De ce fait, il est courant de parler de modifications pour un seul fichier et d'ensemble de modifications (change set) lorsqu'il s'agit du projet (et donc de plusieurs fichiers). En effet, les deux n'évoluent pas au même rythme.

Pour illustrer, prenons l'exemple d'un logiciel nommé « Toto ». Il est constitué des fichiers A, B et C. À la version 1.0 de « Toto » correspondent les versions 1.0 de chacun des fichiers. Admettons que l'ajout d'une fonctionnalité à « Toto » impose la modification de A et de C. Présentons la situation à l'aide d'un tableau

versions de « Toto »	versions de A	versions de B	versions de C
1.0	1.0	1.0	1.0
1.1	1.1		1.1

Du point de vue du projet, les modifications apportées à A et à C font partie du même ensemble.

Dépôt et copies locales

Avant toute modification, le développeur effectue une copie locale des fichiers qu'il souhaite modifier, voire de tous les fichiers du logiciel. Selon les systèmes de gestion de version, il disposera des droits d'écriture sur tous les fichiers ou seulement sur les fichiers qui lui auront été assigné par le chef de projet, il pourra poser ou non des verrous que d'autres utilisateurs pourront ou non contourner, etc.

Le développeur modifie ce qu'il doit modifier et effectue ses premiers tests localement, indépendamment de toutes les modifications qui pourraient advenir dans les dépôts du fait du travail simultané d'autres développeurs.

Lorsque le développeur veut livrer son travail, que celui-ci soit totalement terminé ou non, il doit soumettre ses modifications afin qu'elles soient retranscrites dans le dépôt. C'est là que peuvent apparaître des conflits entre ce que le développeur souhaite soumettre et les modifications effectuées entre temps par d'autres personnes.

Branches

Des modifications divergentes peuvent intervenir sur un ensemble de fichiers. On parle alors de branches. Parfois il s'agit aussi de faire converger des branches. On parle alors de fusion de branches.

Les branches sont utilisées pour permettre :

• la maintenance d'anciennes versions du logiciel (sur les branches) tout en continuant le développement des futures versions (sur le tronc) ;
• le développement parallèle de plusieurs fonctionnalités volumineuses sans bloquer le travail quotidien sur les autres fonctionnalités.

Conflit de modifications

Dans le cas d'un développement en équipe, et surtout en équipes répartie dans le monde entier, chacun travaille de façon indépendante et c'est tout l'intérêt du système de gestion de version que de rendre cela possible. Toutefois, des fusions régulières sont nécessaires à un avancement global du logiciel.

Il n'est pas rare que certaines modifications soient contradictoires (par exemple lorsque deux personnes ont apporté des modifications différentes à la même partie d'un fichier). On parle alors de conflit (de modifications) puisque le logiciel de gestion de versions n'est pas en mesure de savoir laquelle des deux modifications appliquer. Parfois ce n'est même ni l'une ni l'autre et il est nécessaire de reprendre une troisième fois le logiciel pour que ces modifications puissent finalement coexister harmonieusement.

Systèmes centralisés et décentralisés

CVS et Subversion sont des logiciels centralisés, ce qui veut dire qu'il n'existe qu'un seul dépôt des fichiers, dépôt qui fait référence. Cela peut simplifier le modèle mais cela est contraignant pour certains usages (travail sans connexion au réseau ou tout simplement travail sur des branches expérimentales ou bien contestées).

Il existe donc également des logiciels décentralisés comme Mercurial, darcs, Bazaar ou Git. Avec ceux-ci, il existe plusieurs dépôts dont aucun n'a de statut privilégié.

Tronc, branches et taillis inextricable

Un système de gestion de versions permet à une équipe répartie dans le monde entier de développer progressivement un logiciel formé d'un très grand nombre de fichiers, puis de corriger les bogues, d'ajouter les nouvelles fonctionnalités, de développer des variantes incompatibles, etc.

Mais, comme toujours, l'outil n'est pas tout. Une équipe trop nombreuse, trop dispersée, travaillant sur trop de versions simultanées du même logiciel rencontrera vite des problèmes apparemment techniques — par exemple une série de conflits rebondissants les uns sur les autres sans jamais aboutir à une solution stable et consensuelle, des modifications effectuées correctement mais pas dans la bonne branche, des modifications effectuées par une personne puis involontairement effacées une autre, etc.

Au-delà d'une certaine complexité, l'usage du système de gestion de version devra être règlementé par de nombreuses bonnes pratiques et complété par d'intenses activités de communication et de test. En fonction du volume, d'autres outils peuvent alors devenir nécessaires pour structurer, encadrer et archiver ces activités.

Fonctionnalités notoires des logiciels de gestion de versions

Étiquetage ou marquage

Cela consiste à associer un nom à une version donnée. Pour certains outils de gestion de versions (comme CVS) qui gèrent les versions à une faible granularité (beaucoup de modifications non significatives), c'est un moyen de retrouver facilement une version significative.

Comparaison

Il est possible de comparer plusieurs versions pour en extraire les modifications.

Verrouillage et notifications

Pour le travail en équipe, certains logiciels de gestion de versions apportent des outils pour communiquer.

Par exemple, le verrouillage permet d'interdire la modification d'un fichier, tandis que la notification émet un avertissement à tous les autres membres lorsqu'un fichier est modifié.

Exemples de logiciels de gestion de versions

Les logiciels de contrôle de versions sont nombreux. Sous UNIX, il y a eu SCCS qui a suscité un logiciel libre alternatif : RCS (Revision Control System) qui est devenu un standard de fait. Comme RCS ne gérait que des fichiers individuels, nombre de ses utilisateurs ont créé des sur-couches gérant les arborescences de fichiers. Certaines de ces sur-couches furent distribuées librement. Il en fut ainsi de PRCS et de CVS. CVS est devenu extrêmement répandu dans le monde du logiciel libre sur Internet, mais aussi dans les entreprises. CVS est simple à mettre en œuvre et offre les fonctionnalités fondamentales qu'attendent ses utilisateurs.

Mais l'histoire des logiciels de contrôle de versions ne s'arrête pas en 2006 et de nouveaux logiciels libres concurrencent CVS, comme par exemple GNU Arch, Subversion, SVK, darcs, Mercurial, Bazaar, Git ou Monotone.

Dans le monde propriétaire, ClearCase (de IBM), Synergy/CM (de Telelogic, société rachetée en 2008 par IBM) et Serena Dimensions (de Serena) sont les plus répandus. Visual Source Safe (de Microsoft) est largement utilisé aussi, notamment du fait de son intégration avec l'outil de développement Visual Studio, malgré de nombreuses lacunes et des mises à jour peu fréquentes. En 2006, Microsoft lance une nouvelle famille d'outils de développement et de gestion de configuration logicielle sous le nom de Team Suite et Team Foundation Server. Cette suite qui s'appuie sur Visual Studio 2005 intègre entre autres un nouveau logiciel de gestion de versions plus complet et ambitieux que Visual Source Safe. Il existe aussi Perforce et AlienBrain, ce dernier étant souvent utilisé dans le monde du jeu vidéo car particulièrement adapté à la gestion de ressources graphique et sonores (assets) grâce à un système évolué de visualisation.

Voir aussi

Wikibooks propose un ouvrage abordant ce sujet : la gestion de version.

• Logiciel de gestion de versions
• Gestion de configuration
• Version d'un logiciel
• Gestion de version décentralisée

Ce document provient de « Gestion de versions ».