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 Afficher l'historique.

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).

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

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

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.

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.

Gestion de versions centralisée

CVS et Subversion sont des logiciels de gestion de versions centralisée, ce qui veut dire qu'il n'existe qu'un seul dépôt des versions, dépôt qui fait référence.

Cela simplifie la gestion des versions mais est contraignant pour certains usages (travail sans connexion au réseau ou tout simplement travail sur des branches expérimentales ou contestées).

Gestion de versions décentralisée

Avec l'arrivée des logiciels libres et leur développement communautaire, une autre façon de voir la gestion de versions est apparue. Cette autre vision consiste à voir l'outil de gestion de versions comme un outil permettant à chacun de travailler à son rythme, de façon désynchronisée des autres, puis d'offrir un moyen à ces développeurs de s'échanger leur travaux respectifs. C'est ce que l'on nomme la gestion de versions décentralisée.

Mercurial, Darcs, Bazaar, Git, Monotone, GNU Arch et BitKeeper (propriétaire) sont des logiciels de gestion de versions décentralisée. Avec ceux-ci, il existe plusieurs dépôts de versions et aucun n'a de statut privilégié.

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 par 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.

É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é.

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ère 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.