J'étais cons-Git car je suis pro-agile… (1/2)

L'URL courte de cet article est : http://inagua.ch/Q0ifT

Une des gue-guerres internes au royaume inagua, est la confrontation fratricide entre Stephane GIT et Jacques SUBVERSION…

J’avais donc écrit il y a un peu plus d’un an maintenant un draft de pamphlet à l’encontre de Git, et m’étais promis de le publier avant que je change d’avis…

Or, comme je sens que je suis en train de changer d’avis, il est urgent que je publie ce premier article !…

… Merci Bobo pour tes arguments qui me permettent d’évoluer !

Remarque : Etant donné que j’ai virament du mal avec cette philosophie Git (comme vous allez pouvoir le lire ;), je me suis fait un aide mémoire des principales commandes sur mon wiki. Le fait même qu’on ait besoin de ce genre d’aide mémoire signifie soit que je suis atteint de déficience mentale, soit que cet outil est d’une complexité nuisible… J’aime à croire que la première hypothèse n’est pas la bonne ;)

Le 09/09/09, quelque part au bord de la Méditerranée…

Depuis que j’ai découvert Git, je suis resté dubitatif sur l’intérêt des Gestionnaires de Version Distribués (GVD). C’est pour cette raison que j’ai décidé de l’utiliser pour gérer un projet personnel pendant plus d’un mois.

Au final, je n’étais toujours pas convaincu. Je n’y ai pas trouvé d’intérêt, mais par contre des aspects bloquants.

  • Par exemple, je n’ai pas trouvé comment obtenir du repository qu’une partie du projet sur lequel je travaillais. Si j’ai une partie serveur et une partie IHM, ou une partie Rails et une partie Flex, je n’ai pas besoin de récupérer l’intégralité du projet pour travailler.
  • Autre problème : j’ai par mégarde mis sous gestion de version le fichier de log des développement qui existe lorsque l’on développe en Rails. Ce fichier grossit rapidement. A la fin, il m’était impossible d’obtenir une copie locale sur un nouvel environnement, car la recopie échouait en raison du fichier trop volumineux ! J’ai commencé à partir sur une mise à jour de mon environnement de développement sous Mac OSX… Voire à une recompilation de mon client Git… Bref, des considérations bien loin de mon projet.

Je veux bien reconnaître que ces problèmes puissent être du à ma méconnaissance du logiciel, Git, et aussi de la philosophie, la gestion de version décentralisée.

Mais je pense que la principale raison au fait que je sois réfractaire, tient au fait que je ne vois aucune limitation actuelle, aucune lacune, imputables à mon chouchou : Subversion (SVN pour les intimes).

En effet, SVN a de tout temps répondu à mes attentes, sur des projets “tout-seul” comme des projets à plusieurs développeurs pendant plusieurs années.

La seule situation, selon moi, où SVN était en défaut est celle qui m’a poussé à persévérer dans mon utilisation des GVD. J’ai souvent eu des temps de transport assez long pour aller travailler. Ce temps était propice à travailler. Or, impossible de pouvoir faire un commit dans le train : je n’avais pas l’Internet Mondial ! J’en étais arrivé au point de m’installer un serveur SVN sur mon portable, mais la synchronisation n’était pas aisée quand les véritables repositories étaient multiples (projets différents). Lorsque j’ai entendu parlé des GVD, j’y ai vu la lumière !
Etant donné que je maîtrise et apprécie SVN pour mes besoins quotidiens, j’ai donc persévéré sur une extension à SVN qui en fait un GVD : SVK.

Le premier, voire principal, intérêt de SVK est justement que c’est une extension à SVN. Vous pouvez donc installer SVK sur votre portable et vous “brancher” sur un repository SVN quelconque : vous pourrez travailler à votre rythme avec SVK sur le projet, alors que les autres continuent de travailler avec Subversion sans même avoir entendu parlé de GVD !
Le principe de SVK est de créer un miroir du repository central/distant sur votre poste, miroir qui sera pour vous le “nouveau” repository de référence. Vous pouvez donc travailler avec ce miroir sans contrainte (en déplacement par exemple). Et lorsque que votre connexion internet préférée redevient accessible, vous synchronisez alors votre miroir au repository distant. Seule ombre au tableau, le “merge” peut s’avérer “conflictuel” si vous êtes parti longtemps ou si vous êtes nombreux sur le projet.
Donc, SVK en particulier, et les GVD en général, répondent parfaitement au besoin du geek solitaire que je suis, qui souhaite versionner ses projets et ses documents.
Mais devant cet engouement croissant pour Git notamment, je ne peux m’empêcher de m’interroger sur l’intérêt de ces outils sur des projets professionnels traditionnels où l’équipe est regroupée.

Quel est l’intérêt d’avoir un miroir sur son poste ?

Le principal argument que j’ai entendu est “si tu n’as plus de réseau !”. La copie locale d’un SVN traditionnel, permet quand même de travailler librement… Jusqu’au prochain commit ou update il est vrai. Mais c’est déjà une étape par rapport aux vues dynamiques sous Clear Case, où la copie de travail est un disque monté, les sources étant distantes… Soit disant pour protéger le développeur d’un crash de sa machine. En 2 ans d’utilisation, ma machine n’a pas crashé, par contre le serveur Clear Case lui oui, et par deux fois, paralysant tout le plateau immédiatement ! Mais cela sera certainement l’objet d’un autre post ;o) Un miroir local permet donc de se prémunir d’une coupure réseau, mais au prix de quel complexité supplémentaire (synchronisation du miroir) !… Et puis, si le réseau tombe, de nos jours, je ne connais pas beaucoup de développeurs qui peut encore continuer à travailler (besoin d’internet, d’un serveur d’application, d’un serveur de librairie (Maven), du gestionnaire de bug, du mail…).

L’autre intérêt que j’y vois éventuellement, est lors d’un développement en parallèle. Le seul type de cas qui me vient à l’esprit est ceux que j’ai rencontrés : un refactoring. Je suis en train de réaliser ma tâche, et je me rend compte qu’il faut que je fasse un refactoring pour cela. Je pars donc sur une autre branche, une autre copie locale, réalise mon refactoring, commit ma seconde branche, puis revient sur ma première copie locale que je synchronise avant de continuer (pour récupérer le refactoring). Mais cela peut se faire avec SVN : SVN n’empêche en rien d’avoir plusieurs copies de travail sur son poste. SVK et les GVD facilitent peut être le merge des branches.

Quel est le danger d’avoir un miroir sur son poste ?

Je ne vois donc pas vraiment d’intérêt inestimable dans les GVD, par contre j’y vois un risque majeur. Autre argument que j’ai entendu : “avec Git, je commit le soir avant de partir sur mon miroir sans polluer les autres”. Argh ! L’eXtrême Programmeur que je suis ne peut s’empêcher de grincer des dents à l’entente de ces mots ! Un des points sur lequel on discute en XP est que chaque soir, avant de partir, soit tu commites sur le référentiel distant car tous tes tests sont ok, soit tu jettes ton code. Cela peut faire hurler, mais cette pratique ne vient pas seule. Il est liée au fait que l’on est censé commiter plusieurs fois par jour, voire de l’ordre de l’heure. Cela force à découper son travail en micro-itération, et donc à limiter l’effet tunnel même sur l’ordre de grandeur de la journée. Je vous rassure, au risque de faire hurler mon premier coach XP, je ne l’ai pas toujours (souvent ;o) fait. Et c’est pour cela que je monte inagua, pour me donner les moyens de le faire et voir si cela fonctionne avec du sens.

Donc, si l’on permet aux développeurs de faire des commits n’importe quand, cela risque de perturber cette habitude au commit propre et fréquent.

Donc, si les intérêts sont minimes, mais les risques possibles, pourquoi rajouter une couche, de la complexité, la synchronisation, à des outils qui répondent déjà à notre besoin ?

Je parle bien ici des projets traditionnels, avec une équipe regroupée et des besoins provenant d’un même pôle. Je ne parle pas des projets Open Source par exemple.
Je n’adresse pas non plus ici la dimension au delà de Git : Github. Ce site sort en effet du simple cadre de la GVD. N’ayant pas d’expérience ni de recule sur Github, je reste curieux sur le sujet.

J’espère vous avoir transmis mon sentiment que le gestionnaire de version est suffisamment structurant dans la façon de travailler qu’il faut le manier avec précaution. Son utilisation est directement liée à votre méthode de développement : une aiguille peut soit vous servir à recoudre les chaussettes en laine préférées de votre grand mère, soit à faire du vaudou sur le totem de votre supérieur despotique…

En relisant cet article avant de le publier, je me rend compte que j’ai une vision différente sur certains aspects : de l’eau à coulé sous les ponts depuis, tant mon esprit que les outils ont évolués. Mais je publie quand même cet article tant pour voir le cheminement de mes pensées que pour appeler à la discussion…

L'URL courte de cet article est : http://inagua.ch/Q0ifT

Une réflexion au sujet de « J'étais cons-Git car je suis pro-agile… (1/2) »

  1. Svn au bureau depuis plusieurs saisons , git à la maison depuis peu. Dans un premier temps, les actions simples se passent des deux cotés de la même façon. simplement. Par contre, un plaisir git en plus. aucune “infrastructure” donc simple à déployer dans une structure ; les fichiers , ont une une réf unique, donc renommés et / ou déplacés, ils conservent bien leurs historiques ; et si il y a un “fix” à faire sur une version antérieure du dev en cours, sous git pas de checkout dans un autre rep, config de l’ide préféré , etc…. pour faire cohabiter le dév en cours et le “fix. il y a aussi quelques fonctions puissantes que je n’ai pas encore utilisée : git grep :) et git bisect qui semble redoutable.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*


*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>