Les gestionnaires de versions

Lors de la conception d’une application ou d’un logiciel, il est indispensable de suivre  son évolution à travers des versions. Cela nous permet de revenir au besoin à une version antérieur ou bien de sauvegarder une version 1.0, de développer une version 2.0 ajoutant de nouvelles fonctionnalités tout en corrigeant les bugs qui pourrait survenir dans la version 1.0 en sortant des patch 1.1, 1.2, etc…

Il y a trois types de sauvegarde :

  • Complète : Ce type de sauvegarde est le plus fiable mais aussi le plus gourmand en mémoire. Il sauvegarde à chaque nouvelle version l’intégralité des fichiers modifiés ou non.
  • Incrémentielle (ou incrémental) : Chaque sauvegarde enregistre les modifications effectuées par rapport à la précédente sauvegarde(incrémental ou complète).  Cette méthode de sauvegarde est la plus rapide mais pas la plus fiable. En effet, afin de restaurer une version, il nous faudra la dernière sauvegarde complète ainsi que toutes les sauvegardes incrémentales jusqu’à la version voulu. En cas de perte d’une de ces versions, il est impossible de restaurer la version voulu.
  • Différentielle : Chaque sauvegarde enregistre les modifications effectuées par rapport à la dernière sauvegarde complète. Cette méthode est moins rapide que la sauvegarde incrémentielle mais plus fiable. En effet, afin de restaurer une version, il nous suffit d’avoir la version complète et uniquement la sauvegarde différentielle de la version voulu.
Sans appui logiciel, cette tâche s’avère très fastidieuse voir impossible. Une des méthodes consistait en effet à créer une copie des fichiers dans un autre répertoire. Il était donc courant d’oublier de faire une copie, de supprimer un de ses répertoires, d’oublier de faire les mise à jour 1.1 et 1.2 dans la version 2.0, etc…

Ainsi il existe différents logiciels qui s’occupent de gérer ces versions.Ils sont divisés en trois catégories :

  • LVCS : Local Version Control System
  • CVCS : Centralized Version Control System
  • DVCS : Distributed Version Control System

LVCS

LVCS (Local Version Control System ) est le système le plus simple pour gérer ses versions. En effet, les LVCSs possèdent une base de données local afin de sauvegarder les versions. Cette méthode est aussi la moins fiable. En effet, si l’on perd le disque dur, la version du logiciel sur laquelle nous travaillons ainsi que les autres sont perdues. De plus, un LVCS est inadapté pour un projet en équipe.

RCS est un des LVCS les plus connus.

Schéma d’un LVCS :

 

CVCS

CVCS (Centralized Version Control System) est un système ayant un dépôt référent situé sur un serveur. Il apporte une solution aux développeurs travaillant en équipe. C’est le serveur qui se charge de sauvegarder l’historique des versions et qui sert de référent. Il est possible pour l’administrateur du serveur de gérer les droits des développeurs. Ce système est le standard pour  les gestionnaires de version bien que les DVCS apparaissent de plus en plus. En effet, les CVCSs ont trois principaux inconvénients. Premièrement, le travail hors-connexion est impossible, le développeur ayant besoin d’être synchroniser avec le serveur. Deuxièmement, en cas de perte du serveur(et de non backup), toute les anciennes versions sont perdus. Enfin, le système CVCS empêche l’utilisateur de travailler en mode “brouillon”. En effet, chaque version est forcément placer sur le serveur principal, il est donc impossible de pouvoir travailler sur des versions d’essais en local pour ensuite faire un commit sur le serveur principal.

Subversion(SVN) et CVS sont les CVCSs plus connus.

Schéma d’un CVCS :

DVCS

 Les DVCS (Distributed Version Control System) est un système où le dépôt(le regroupement des différentes sauvegardes des versions) situé sur le serveur est dupliquée sur l’ensemble des développeurs. Ce système offre plusieurs avantage : Il permet aux développeurs de pouvoir continuer à travailler hors-connexion. De plus, le développeur peut ainsi utiliser son dépôt local pour réaliser des brouillons et ainsi éviter de gêner les autres développeurs avec des versions “inutiles”. En cas de perte sur le serveur principal, il suffit de le restaurer en prenant une copie situé sur l’ordinateur d’un des développeurs. L’inconvénient principal de ce système réside dans le fait que l’administrateur du serveur possède moins de contrôle sur les fichiers. Par exemple, il ne pourra pas empêcher la mise à jour de fichier sur le dépôt local d’un développeur. Le second est que ce système consomme plus de mémoire(étant donné qu’on copie le dépôt du serveur sur sa machine local).
Git est le plus connu des DVCSs.
Schéma d’un DVCS :

Vocabulaire

Quelque soit le système de gestion de version que l’on utilise, on rencontre plus au moins le même vocabulaire. Voici les mots que l’on rencontre le plus :
  • Working copy : C’est les fichiers locales sur lesquelles on travaille.
  • Repository : C’est le répertoire de votre projet contenant la version du projet du côté du gestionnaire de versions.
  • Commit : C’est la version que l’on envoie sur votre gestionnaire de versions.
  • Branche : C’est l’axe de développement de votre application, il peut y avoir un axe développement et un axe production par exemple.
  • Merge : c’est l’action de fusionner de deux branches.
  • Flag/Tags : c’est un tag que l’on place sur un commit précis. Par exemple : Version 1.0