To read the French version of this article click here

Un système de contrôle de versions est responsable de la gestion des modifications des données dans un dépôt. Cela peut inclure du code, des sites Web, des documents ou toute autre collection d'informations. Le logiciel de contrôle de version facilite et, dans une certaine mesure, automatise ce processus.

Il est également appelé système de contrôle de révision, de contrôle de code source ou de gestion de code source.

Plusieurs versions pour un même projet

Différents auteurs travaillant sur le même projet (que ce soit pour du code ou des informations) doivent s'assurer qu'ils ne remplaceront pas la version actuelle et pertinente par quelque chose qui est obsolète ou à un niveau de développement inférieur.

Un exemple particulièrement bon est l'édition collaborative sur des sites comme Wikipédia. A l'origine, n'importe qui pouvait créer ou éditer une page. Evidemment, cela a changé avec le temps. Et si deux personnes publient presque simultanément ? Ou si quelqu'un décide de vandaliser un article ?

Le logiciel Wikipédia permet de revoir toutes les modifications. L’« historique » de chaque page contient des liens vers toutes les révisions. Et les modifications indésirables peuvent être annulées en sélectionnant ces liens. Il s'agit d'une forme (quelque peu désordonnée) de contrôle de version. On peut considérer le site web avec ses informations comme dépôt, et des articles spécifiques et leur historique de modifications comme une forme de contrôle de version.

Les conflits entre différentes versions

Pour les équipes de développement, il est essentiel qu'elles ne rencontrent pas de conflits d'édition.

Les équipes de développement se heurteront régulièrement à ce type de problème si plus d'une personne travaille sur un morceau de code.  Et parfois même, selon le codeur, cela peut arriver à une seule personne qui travaille sur le code.

Le dépôt : le stock de toutes les versions existantes

Le dépôt contiendra chaque version de ce code (et le code des autres projets) avec un horodatage pour chaque version. Ces révisions internes seront enregistrées et attribuées à un numéro de version qui peut être incrémenté plusieurs fois par jour. Une fois le logiciel déployé, un numéro de version de version lui est attribué, qui est soumis à des modifications moins fréquentes.

Si un problème est découvert, cela peut nécessiter une restauration de la version actuelle. Habituellement, elle est remplacés par une version antérieure stable pendant que les bogues sont éliminés.

Un logiciel gère les versions contenues dans le dépôt

Chaque fichier à modifier est extrait du dépôt par une demande de « mise à jour » (update) du fichier et le logiciel de contrôle de version le note. Le développeur travaille sur sa copie locale du fichier (une « copie de travail » ou working copy) et, une fois terminé, le réintégrera dans le dépôt (un « commit »).

Un logiciel de gestion des versions moderne permet la distribution de dépôts locaux avec un dépôt central, en poussant les fichiers mis à jour vers les dépôts locaux et en récupérant les fichiers mis à jour.  Le dépôt central fait de même, comme ceci :

S'il y a plusieurs développeurs travaillant sur le même code, les choses peuvent devenir plus difficiles. Cela conduit aux concepts de troncs (« trunks »), de branches (« branchs ») et de balises (« tags »).

Le tronc est la copie principale du code, une branche est une version où des modifications sont apportées, et une balise est une copie de travail fixe du projet conservée pour la réversion en cas de problèmes. Un tronc est la base du projet : Les développeurs vont bifurquer à partir du tronc, apporter leurs modifications, tester la fonctionnalité et la stabilité, puis fusionner cette branche dans le tronc Ils peuvent alors peut-être créer une balise pour la nouvelle version stable qui a pu être rétablie.

Enfin, une meilleure communication au sein de l'équipe peut réduire considérablement les problèmes.

Comment résoudre les conflits d’édition

Nous avons mentionné les conflits d'édition plus tôt. Comment ces problèmes sont-ils résolus par le logiciel ? Généralement, ces méthodes sont utilisées :

• La validation atomique applique toutes les modifications en une seule opération et annule en cas d'échec
• Le verrouillage limite l'édition du fichier à une personne à la fois
• La fusion vérifie que les modifications se trouvent dans différentes parties du fichier et ne sont pas en conflit. En cas de conflit, le logiciel conservera les fichiers modifiés et enverra une alerte à l'équipe de développement.
• La résolution manuelle est le moment où l'équipe de développement décide de la version à conserver et peut modifier manuellement le fichier pour refléter cela.

Nous avons déjà mentionné les versions. Pour celles-ci, il doit y avoir une norme convenue pour les versions de lancement.

Prenons l’exemple d'IBM pour leur logiciel serveur, AIX 7.2.4. AIX est le nom du système d'exploitation, 7 est la version majeure, 2 est la version mineure et 4 est la build (ou la nouvelle compilation du logiciel).

Il peut y avoir des champs suivants qui étiquettent les révisions de la build, les correctifs, les service packs et autres, mais en général, le format est toujours du plus haut niveau vers le plus bas. Pour la plupart des versions, la modification de la version majeure indique que la rétrocompatibilité a été compromise. Cela permet à quiconque d'identifier rapidement si la nouvelle version fonctionnera différemment de l'ancienne.

Dans le prochain épisode de cet article, je comparerai plusieurs outils de gestion des versions.

Lectures complémentaires :

Continuous Integration: A non-technical introduction by Andrew Clandillon

Photo credit :  yellow2j  via depositphotos.com