VCS

Version Control System

Un VCS (ou système de contrôle de version) est un outil de suivi de l'évolution d'un projet.

L'objectif d'un VCS est de faciliter le travail collaboratif sur un projet, et de maintenir un excellent suivi de l'historique du projet.

Exemples de VCS

Il existe de nombreux VCS, le BR a utilisé ou utilise encore les suivants :

• CVS, assez vieux et peu performant
• SVN, très répandu, basé sur une architecture client/serveur
• Git, qui gagne en importance ; basé sur une architecture très distribuée, il est utilisé pour Frankiz.

Concepts

Bases

Un VCS se compose :

• D'un dépôt : l'endroit où est stocké l'ensemble de l'historique du projet (il peut y en avoir plusieurs dans le cas de Git )
• De copies de travail (ou checkouts) : En général une par développeur, il s'agit grosso modo d'un export du dépôt, qui stocke notamment (dans un dossier caché) la version dépôt des fichiers

Commits

Lorsque l'on développe, on va récupérer une copie du dépôt, puis effectuer ses modifications et les tester. Une fois que les changements sont corrects, on va réaliser ce que l'on appelle un commit : il s'agit d'envoyer au dépôt les modifications que l'on a effectuées, sous forme de différences par rapport au fichier d'origine. On accompagne la chose d'un message décrivant ce qui a été fait (par exemple, fix bug in XXX, add link for YYY, ...).

Cela permet de disposer de l'historique des modifications effectuées sur le projet, et de savoir qui a fait quoi :)

En général, lors d'un commit, un mail résumant les modifications effectuées est envoyé à l'ensemble des développeurs du projet.

Avant d'effectuer des modifications, il convient de mettre à jour sa copie locale : ceci limite le risque de conflit à résoudre a posteriori.

Merge

Si l'on a effectué des modifications et qu'un autre utilisateur a committé en parallèle, deux situations peuvent se produire :

• Les modifications locales et celles de l'autre développeur concernent des fichiers différents : dans ce cas, le VCS va automatiquement fusionner les modifications (i.e appliquer les modifications de l'autre développeur)
• Les deux développeurs ont modifié les mêmes lignes d'un même fichier : on parle de conflit. Dans ce cas, le VCS le signale et laisse au développeur le soin de fusionner correctement les modifications (on parle de merge).

Branches

Lorsque les changements à effectuer sont importants et occupent une place certaine, on crée une branche : on part de l'état du projet à l'instant t0, et on diverge du développement standard en ajoutant des modifications variées (généralement pour ajouter une fonctionnalité innovante mais qui impose de lours remaniements du code).

Une fois cette fonctionnalité achevée, on va merger la branche divergente avec la branche principale : il s'agit d'appliquer les changements de la branche divergente à la branche principale. En général, dans le procédé, le VCS commence par appliquer le plus grand nombre possible de commits de la branche divergente à la branche principale ; à chaque fois qu'un conflit se présente, on demande à l'utilisateur de résoudre. Une fois le merge terminé, on commite les modifications effectuées.

En général, un projet contient les branches suivantes :

• master (ou trunk) : là où s'effectue le développement actif,
• prod : la version de production, sur laquelle on reportera les commits importants (en général, ceux qui résolvent des failles de sécurité)

Tags

Lorsque l'on considère qu'il est temps de sortir une nouvelle version, on réalise un tag : il s'agit d'une capture de l'état du dépôt lors de cette version. Cela permet facilement de suivre l'évolution depuis la dernière release, par exemple.

Processus de travail

Le processus est souvent le suivant :

1. Le développeur récupère une copie de travail
2. Il fait des modifications, et les teste
3. Il envoie un commit
4. Un autre développeur fait des modifications
5. Le développeur met à jour sa copie de travail (y propageant ainsi les modifications effectuées par les autres développeurs)
6. Il fait à nouveau des modifications, les teste, puis committe.

Et ainsi de suite.

Règles de bon usage

Quelques règles sont à respecter dans un processus de développement collaboratif :

• Les commits doivent être atomiques : un commit résoud un bug, ajoute une seule fonctionnalité, ... (pas de fix typo, fix bug, add XXX)
• Les branches doivent rester opérationnelles : sauf cas exceptionnels, pas de régression dans un commit (si ça marchait avant, ça doit marcher après)
• On doit accompagner chaque commit d'un message décrivant son effet (pas de fix bug mais Fix problem in module XXX : ...).
• Si un commit résoud un bug indiqué dans le gestionnaire de bugs (Bugzilla, Flyspray, Trac), l'indiquer dans le message : Fix bug #42666 ; en effet, il arrive souvent que ce genre de message ferme automatiquement la tâche en la reliant au commit