Le contrôle des versions est la gestion des différents changements apportés aux éléments d’un produit ou à sa configuration. Une version, une révision ou une édition d’un produit est l’état dans lequel il se trouve à un moment donné de son développement ou de sa modification.
Bien qu’un système de contrôle des versions puisse être réalisé manuellement, il est fortement conseillé de disposer d’outils facilitant cette gestion, ce qui donne lieu à ce que l’on appelle les systèmes de contrôle des versions ou VCS (Version Control System). Ces systèmes facilitent l’administration des différentes versions de chaque produit développé, ainsi que les éventuelles spécialisations effectuées (par exemple, pour un client spécifique). Parmi ces outils, on peut citer CVS, Subversion, SourceSafe, ClearCase, Darcs, Bazaar, Plastic SCM, Git, SCCS, Mercurial, Perforce, Fossil SCM, Team Foundation Server.
Le contrôle de version est principalement utilisé dans l’industrie informatique pour contrôler les différentes versions du code source, ce qui a donné naissance aux systèmes de gestion du code source (SCM). Cependant, les mêmes concepts sont applicables à d’autres domaines tels que le travail de bureau (documents, images, sites web, etc.).
Caractéristiques
Un système de contrôle des versions doit fournir :
Bien que cela ne soit pas strictement nécessaire, il est souvent très utile de générer des rapports avec les changements introduits entre deux versions, des rapports d’état, le marquage avec un nom identifiant la version d’un ensemble de fichiers, etc.
Terminologie
La terminologie utilisée peut varier d’un système à l’autre, mais certains termes couramment utilisés sont décrits ci-dessous.
Le système n’est pas en mesure de fusionner les modifications. L’utilisateur Y doit résoudre le conflit en fusionnant les modifications ou en choisissant l’une pour rejeter l’autre.
Façons de collaborer
Pour collaborer à un projet à l’aide d’un système de contrôle de version, la première chose à faire est de créer une copie locale en obtenant des informations du référentiel. L’utilisateur peut ensuite modifier cette copie. Il existe deux schémas de fonctionnement de base permettant aux utilisateurs d’apporter leurs modifications :
Le contrôle de version de Team Foundation Server vous permet de choisir l’une des deux méthodes de collaboration.
Architectures de stockage
Les systèmes de contrôle de version peuvent être classés en fonction de l’architecture utilisée pour le stockage du code :
Flux de travail
Le flux de travail d’un système de contrôle de version indique comment les différents utilisateurs sont en relation les uns avec les autres afin de collaborer pour atteindre les objectifs du projet.
Dans les systèmes de contrôle de version centralisés, la conception du système limite la manière dont les différents utilisateurs collaborent les uns avec les autres. En revanche, les systèmes de contrôle de version distribués offrent beaucoup plus de souplesse dans la manière de collaborer, car chaque développeur peut à la fois contribuer et recevoir des contributions. Il existe différents flux de travail, chacun étant mieux adapté à un certain type de projet. Examinons quelques exemples courants qui peuvent également être combinés pour mieux s’adapter à un projet spécifique (par exemple, un flux de travail centralisé pourrait être utilisé en général, et un gestionnaire d’intégration pourrait être utilisé pour certaines parties critiques et importantes).
Dans le flux de travail centralisé, chaque développeur est un nœud de travail. D’autre part, il existe un référentiel central à distance qui sert de point de synchronisation. Tous les nœuds de travail fonctionnent sur un pied d’égalité avec le référentiel central distant.
Dans un système de contrôle de version distribué, chaque nœud de travail consiste en un dépôt local privé.
L’inconvénient de cette méthode de travail est que si deux utilisateurs clonent à partir d’un point central et apportent tous deux des modifications, seul le premier à soumettre ses modifications peut le faire proprement. Le second développeur doit fusionner son travail avec le premier avant de le soumettre, afin d’éviter d’écraser les modifications du premier développeur. En d’autres termes, une étape préalable est nécessaire car les modifications non rapides ne peuvent pas être téléchargées.
Dans le flux de travail avec un Integration-Manager Workflow, chaque développeur a un accès en écriture à son propre référentiel public et un accès en lecture aux référentiels publics de tous les autres utilisateurs. D’autre part, il existe un dépôt canonique, le représentant « officiel » du projet.
Pour contribuer à ces projets, chaque développeur crée son propre clone public du dépôt canonique et y soumet ses modifications (effectuées dans un dépôt privé). Pour « télécharger » ses modifications vers le dépôt canonique, chaque développeur doit en faire la demande au gestionnaire du dépôt.
Le principal avantage de cette méthode de travail est que vous pouvez continuer à travailler et que le gestionnaire du dépôt canonique peut récupérer vos modifications à tout moment. Les contributeurs n’ont pas à attendre que leurs modifications soient intégrées au projet, chacun peut travailler à son rythme.
Le flux de travail du dictateur et de ses lieutenants est une extension du flux de travail du gestionnaire d’intégration. Il est utilisé dans de très grands projets comptant des centaines de contributeurs, comme le noyau Linux.
Un certain nombre de gestionnaires d’intégration sont responsables de parties spécifiques du référentiel, appelées lieutenants. Tous les lieutenants rendent compte à un responsable de l’intégration, appelé le dictateur. Le dictateur intègre toutes les contributions des lieutenants en publiant le travail dans un référentiel que tous les contributeurs récupèrent.
Ce système de travail permet au chef de groupe (le dictateur) de déléguer une grande partie du travail aux lieutenants, reléguant leur travail à la collecte des fruits de multiples points de travail.
Utilisation de branches
Le branchement, dans un système de contrôle de version, est un outil puissant qui rend plus flexible la manière dont les collaborateurs coopèrent sur le projet (Branching Workflows). Le branchement n’est qu’un outil parmi d’autres, qui peut être utilisé de différentes manières pour atteindre différents objectifs. Examinons quelques possibilités.
Dans certains projets, plusieurs branches sont toujours ouvertes, ce qui indique divers degrés de stabilité du contenu. Par exemple, dans la branche « master », il est courant de ne conserver que ce qui est totalement stable. Il y a ensuite d’autres branches qui révèlent différents degrés de stabilité. Par exemple, vous pouvez avoir une branche « beta » (version beta) et une branche « alpha » (version alpha), sur lesquelles vous travaillez. Lorsqu’un certain degré de stabilité supérieur à la branche actuelle est atteint, une fusion avec une branche de stabilité supérieure est effectuée.
Les branches ponctuelles, également appelées branches de support, sont des branches créées sur une base ad hoc pour réaliser une fonctionnalité très spécifique. Par exemple, l’ajout d’une nouvelle fonctionnalité (elles sont appelées branches de nouvelle fonctionnalité ou directement branche de sujet ou branche de fonctionnalité) ou la correction d’un bogue spécifique (elles sont appelées branches de correction de bogue ou directement branche de correction à chaud).
Ce type de branche vous permet de travailler exclusivement sur le développement d’une fonctionnalité spécifique et lorsqu’elle est terminée, vous la fusionnez avec l’une des branches de longue durée (normalement avec celle dont le niveau de stabilité est le plus bas, afin qu’elle puisse être testée dans cet environnement). La fusion n’est effectuée que lorsqu’il est « sûr » que la fonctionnalité est correctement mise en œuvre, plutôt que de fusionner dans l’ordre dans lequel les choses sont développées. Cela permet, d’une part, d’avoir un historique des différentes versions qui ont été réalisées jusqu’à ce que la fonctionnalité soit atteinte. D’autre part, cela permet à l’historique des branches à long terme de ne pas être « encombré » de différentes modifications liées à une fonctionnalité particulière.
L’utilisation de ces branches permet une plus grande flexibilité dans l’essai des solutions possibles. Elle ne fusionne avec les branches de longue durée que lorsque l’on est sûr d’avoir choisi la meilleure solution.
Un type particulier de branche qui fonctionne d’une manière spéciale est la branche dite « release ». Ces branches sont créées pour soutenir la préparation d’une nouvelle version de production. Elles vous permettent de contrôler le contenu de la version et d’en assurer la maintenance (ajout de petites améliorations et de corrections de bogues).
Il est courant et de bonne pratique d’utiliser un préfixe dans le nom de la branche pour indiquer le type de branche. Par exemple, vous pouvez utiliser « feature- » pour les branches de nouvelles fonctionnalités, « hotfix- » pour les branches de corrections de bogues, et « release- » pour les branches de versions.