Bureautique
C’est la bonne version ?
La problématique se retrouve souvent dans un projet, et ce n’est pas ici spécifique au décisionnel.
Je ne parle pas des versions des logiciels que nous utilisons, mais bien de ceux que nous produisons !
C'est la bonne version ?
L’attention portée à la bonne gestion des versions des sources des projets est pour moi capitale. Une gestion stricte des développements et des livraisons effectuées peut permettre un gain de temps considérable lors d’une évolution ou d’une correction à apporter par la suite.
Beaucoup sont d’accord sur les principes, un peu moins connaissent les fonctionnalités évoluées des outils, et combien s’en servent efficacement ?
Je suis moi-même dans le cas ou j’aimerai gérer les versions de mes fichiers de façon plus fiable et plus efficace.
Mais comment bien gérer les différentes versions d’un projet ?
Des outils sont là pour nous aider, mais il nous reste à bien les utiliser…
Je vais tenter de détailler ma vision de la gestion de version. Certains points seront certainement discutables, n’hésitez pas à partager vos bonnes pratiques et vos astuces !
Subversion
Définition rapide
Subversion est un système de gestion de version distribué sous licence Apache et BSD. Dans le modèle SVN, un projet dont on gère les version est mis sur un dépôt. Ce sont les versions des fichiers du dépôt qui seront gérées.
Vocabulaire :
Les révisions
Une révision correspond à un état du dépôt. Un nouveau numéro de révision est créé à chaque mise à jour du dépôt.
Le trunk
Ce dossier, à la racine du dépôt, doit contenir la version actuellement en production du projet en question. Elle contient dans l’idéal, les sources, mais également la documentation applicative correspondante ainsi que tout fichier pouvant servir au fonctionnement ou aux tests de la version en question.
Pourquoi ne pas travailler directement sur ce dossier ?
Imaginez la situation suivante : Vous répondez à une demande d’évolution de la part de votre client. Vous commencez vos développements et là, une anomalie apparaît en production ! Vous connaissez la suite, il va falloir reproduire l’anomalie mais pour commencer il va falloir obtenir les sources telles qu’elle sont actuellement en production.
C’est tout à fait possible, mais c’est loin d’être pratique, il vous faut remettre votre dossier local à une version antérieure, à supposer que vous sachiez quelle était la révision au moment de la livraison. Bref, pour faire simple, ce n’est pas la bonne solution.
Alors que si ce dossier est à tout moment dans le même état que la dernière mise en production, tout est là, vous pouvez traiter la demande sans interrompre vos développements d’évolution. Dans le pire des cas, des modifications devront être reproduites dans les développements liés à l’évolution que vous traitez.
Les branches
C’est la zone de travail, ou vous pourrez développer au jour le jour, seul ou à plusieurs. Une branche est une des directions que prend votre projet. Il peut y avoir plusieurs branches si vous expérimentez plusieurs solutions.
Tout projet devrait commencer par une branche et toute évolution d’un projet devrait commencer par la copie du trunk dans une nouvelle branche. Dans l’idéal, chaque sous-dossier du dossier branche porte un numéro de version correspondant à la version utilisée si cette branche passe en production.
Les tags
Un tag sert à créer une image du dépôt à un instant donné. C’est une copie du dépôt à un instant t. On peut se servir des tags pour identifier les différentes versions entrées en production. Il est important de noter que rien n’empêche vraiment de modifier le contenu du tag, comme c’est le cas des autres dossiers, il est cependant important de définir des bonnes pratiques, communes (au minimum) à l’ensemble des intervenant du projet.
Ne pas oublier
Un projet se termine ? La recette est terminée, la mise en production aussi, super, c’est la récompense tant attendue ! Mais le projet n’est pas terminé ! Il faut mettre à jour le trunk du dépôt.
Cette manipulation simple permettre de gagner du temps et de l’argent si le projet a le droit à une suite. 3 mois après, quand vous bosserez sur un autre projet, que quelqu’un reprendra votre suite, il gagnera un temps précieux s’il sait de quels fichiers il doit partir.
Les actions à connaître avec Tortoise SVN
Tortoise SVN
Ce logiciel gratuit est un client SVN qui vient très bien s’intégrer à l’explorateur. Il permet en plus de savoir si un fichier est à jour par l’ajout d’une signalétique sur les icônes des fichiers du dépôt.
Menu contextuel de Tortoise SVN
Commit
Cette action consiste à synchroniser vos modifications avec le dépôt et ainsi de créer une nouvelle révision.
Update
Cette action consiste à récupérer sur votre poste les modifications effectuées sur le dépôt par les autres intervenants sur le projet.
Il est important de noter qu’il est possible d’effectuer cette action pour une révision quelconque du projet et ainsi de revenir facilement à une version antérieure.
Export
Il est intéressant de connaître cette fonction. Si vous souhaiter vous servir des fichiers versionnés présents sur votre poste dans un autre contexte, une simple copie dans un autre répertoire n’est pas souhaitable. En copiant un répertoire, vous copiez aussi les informations de version conservées dans ce dossier. Faire un export permet de ne pas copier ces informations.
Parcours du dépôt
Tortoise SVN permet de parcourir le dépôt SVN non seulement à travers son arborescence, mais il ajoute également la dimension des révisions ce qui permet de naviguer dans l’intégralité du projet à ses différents degrés d’avancement.
Comparer les version
Lors de la sélection d’un fichier, le menu contextuel de Tortoise SVN permet de comparer une version de fichier avec la précédente. C’est très pratique pour les projets où plusieurs intervenants sont amenés à modifier les mêmes fichiers. Ce type d’action concerne surtout les fichiers de texte brut. C’est particulièrement adapté pour les fichiers texte.
Voir le log
Lors d’un commit, on peut (on doit !) mettre un commentaire sur l’objet des fichiers mis à jour. Ces commentaires peuvent être visibles pour chaque fichier en cherchant le commentaire associé au dernier commit de ce fichier. Chaque utilisateur possède normalement un compte et est donc identifié lors d’un commit, de cette façon on peut savoir facilement qui a modifié le fichier, quand cela a été fait et un bref résumé des modifications.
De nombreuses autres fonctionnalités sont possibles, mais je pense avoir décrit là celles qui permettent déjà d’avoir une gestion organisée du dépôt.
Voilà qui termine cet article sur la gestion de version. Je rappelle que j’ai voulu ici exprimer ma vision du sujet, et je suis loin de maîtriser parfaitement cet outil pourtant très pratique. Vous êtes tout à fait invités à compléter ou discuter la méthode. Vos trucs et astuces sont également les bienvenus, une fonctionnalité vous est indispensable ? Décrivez la !
Tags: Discussion
3 commentaires pour “C’est la bonne version ?”
Poster un commentaire
C’est en effet une vraie problématique qui est rencontrée dans tous les projets avec plus de 2 ou 3 développeurs. Sinon, on se retrouve vite à galérer avec juste des dossiers, des numéros, …
Il y a un temps incompressible de mise en place de ces solutions mais c’est, au bout de quelques semaines, un vrai gain !
A titre personnel, j’ai utilisé Team System, de Microsoft. C’est un peu plus qu’un « simple » outil de versionning car il y a des fonctions collaboratives.
Il faut prendre le temps de le mettre en place et de s’y habituer mais ensuite, quel bonheur ! Quelques infos sur ce produit ici : http://www.microsoft.com/france/vision/mstechdays08/WebcastMSDN.aspx?EID=0a9f2b3d-bc81-442b-9c55-2549016d9bce
Thomas.
Ah je connais TortoiseSVN je l’utilisais à mon stage. C’est vrai que c’est bien pratique. Et quand tout est sauvegardé sur un serveur régulièrement ça évite quelques frayeurs…
Article instructif ; j’ai appris l’export, et les conventions de gestion d’un SVN (tags, trunk, etc.), très intéressant. Ce genre de choses pourrait être enseigné à Polytech’Nantes…
Comme fonctions primordiales (je n’utilise pas Tortoise, mais ça reste SVN), j’ajouterais aussi « add » et « delete », pour créer ou supprimer des fichiers du projet (attention à ne pas supprimer un fichier qui comporte des modif. locales avec l’explorateur de fichier sinon c’est la galère), et peut-être le « revert » qui permet de « déversionner » un fichier (bien pratique pour rattraper la précédente bourde, par exemple).
Un autre truc vraiment pratique avec subversion, c’est qu’il permet généralement de fusionner des modifications effectuées sur un fichier texte si elles n’entrent pas en collision : gain de temps considérable !
En tout cas, je ne pourrais plus me passer d’SVN, surtout pour les projets à plusieurs !
Merci pour cet article !