Comme je vous le disais en introduction de la première partie de mon article (« J’étais cons-Git car je suis pro-agile… (1/2)« ), j’ai commencé il y a plus d’un an maintnant un article en deux partie sur mon irritation envers ceux qui me semblaient aveuglèment pro-git.
Voici donc la seconde partie de cet article.
Encore une fois j’en appelle à votre clémence : cela remonte à plus d’un an… N’hésitez pas à me faire part de vos remarques.
A la suite de ma première réflexion (« J’étais cons-Git car je suis pro-agile… (1/2)« ), Stephane a eu la bonne idée de m’aiguiller vers cet article de Schott Chacon : « Why You Should Switch from Subversion to Git« . Cela m’a permis d’affiner mon idée sur les conseils même d’un des auteurs du livre et acteur de Github.
J’en ai profité pour préciser le titre du post !
Je constate une montée en puissance de Git sur Subversion (migrations des repositories) dans les projets Open Source… Comme Subversion l’a fait il y a quelques années avec CVS…
Je suis critique non pas par obsession ou fétichisme envers SVN, mais je cherche à comprendre l’intérêt avant d’y passer éventuellement. De plus, je tiens à dire explicitement que j’aborde Git sous un angle d’équipe XP, avec les principes qui guide le fonctionnement d’une telle équipe…
Git : anti-XP ?
1) Tout est local donc super rapide…
Ok, cela est un argument recevable dans un environnement XP qui doit être optimisé. Mais si je rajoute les étapes de synchronisation entre le repo local et le repo distant, je pense que l’on ré-quilibre les durées.
2) Des repo partout si ca coupe.
La redondance du serveur est une problématique qu’il ne faut pas résoudre en faisant des copies sur chaque poste !… Et de toute facon, si ça plante laquelle on prend ? Lequel a synchronisé son repo local en dernier ?
Si le serveur plante avec Subversion, la copie locale permet de continuer à travailler : ce qui est impossible est la synchronisation avec le repo distant, ce qui correspond à un commit (précédé d’un update/merge). Ce qui arrive toute les 2 heures environ pour les équipes extrêmement XP, et tous les quelques jours pour la majorité des équipes. Bref, cela laisse le temps de remonter le serveur.
3) Un workflow “incroyable”.
Là, pour le coup, je suis d’accord ! C’est incroyable. C’est le seul point sur lequel j’avais encore un doute, mais il a fini de me convaincre.
Il cite deux exemples de workflow qui font la force de Git… Deux exemples qui ne correspondent absolument pas au fonctionnement d’une équipe XP.
Le premier est celui de l’écriture de son livre (avec les 34 merges) : si j’ai bien compris, lui, “responsable de la branche main”, du contenu du livre, pioche et intègre selon son bon vouloir les ajouts, remarques, modifications et autres corrections des autres contributeurs, sous la forme de merge de branche. Ce fonctionnement décisionnel est l’inverse de celui d’une équipe de développement, et pas seulement XP : ce n’est pas un responsable du tronc qui décide de l’intégration, mais bien le réalisateur de la correction/évolution, de la branche, qui décide ou non d’intégrer quand il a fini.
Quand au second exemple avec un QA guru master qui a les pleins pouvoir d’intégration… Le schema pourrait figurer sans aucune honte dans une brochure IBM… Le prochain stade est la création d’un rôle d’administrateur/expert workflow Git facturer très cher la journée pour administrer le workflow chez le client… A mais je suis bête, cela existe déjà… Si si : ClearCase !
Il dit qu’on peut imaginer tous les workflow possibles. Ok, voici le mien, voici mon besoin : un repository dont je récupère le contenu, je fais ma micro-tâche, je la teste, si c’est ok je l’injecte dans le repo pour que tout le monde en bénificie dés maintenant… Ah mais cela existe aussi : SVN ;o)
4) Le déploiement sur Heroku.
Là, pour le coup, je suis vraiment intrigué. Cette fonctionnalité semble vraiment très séduisante sur le papier, car c’est un manque récurant chez de nombreux client pour lesquels j’ai travaillé : le déploiement des livrables dans l’environnement de production.
Le fait de pouvoir faire un ‘push’ sur un repo distant heroku (“repo de production”) pour délivrer.
Je vais creuser cette fonctionnalité avec intérêt.
5) Lightweight Branches: Frictionless Context Switching
Wouaouh ! J’ai l’impression qu’on mélange plusieurs choses…
a- le temps d’exécution : c’est bon, on a compris que c’est en local et que c’est plus rapide, mais on ne va pas tout le temps y revenir. Et puis quand on merge, le plus comsommateur en temps n’est vraiment pas la durée des traitements de l’outil, mais bien le temps qu’on passe à vérifier la cohérence du merge.
b- pourquoi autant de branches dans tous les sens ??? Je ne cache que d’experience j’ai développé une allergie vicérale aux branches et aux merges… Mais, cette peur mise de côté, je ne vois pas de raison objective pour un développeur de créer volontairement des branches à foison ! Un développeur qui travaille sur une tâche, va réaliser sa tâche, éventuellement dans une nouvelle branche. Admettons qu’il ait besoin de faire un refactoring en cours de tâche : il crée éventuellement une seconde branche, et c’est tout ! il va alors terminer son refactoring et merger sa 2nde branche avant de revenir à sa première branche : là, il va certainement commencer par synchroniser cette 1ere branche, car je pense qu’il a besoin de son refactoring pour continuer ?!… Puis il continue sur cette première et unique branche. Encore une fois, l’exemple qu’il donne avec son livre et les 34 merge (donc 34 branches) n’est pas celui d’une équipe de développement.
6) staging area
Là, je pense avoir mal compris… D’après l’auteur, Git permettrait de faire des commit “sémantiques”, par lot, mais pas SVN ?!… Dans SVN, il ne serait pas possible de faire des commits par groupe de fichiers choisis ?!… Biensûre que si ! Et là encore, cela est un “bad smell”. Les fois (trop nombreuses hélas) où j’ai du faire cela (commiter une partie seulement des fichiers que j’avais modifiés pour faire ressortir le fait que ces fichiers étaient liés), correspond à des fois où il s’est passé du temps, braucoup trop de temps (plus d’une journée), entre mes 2 commits successifs. De plus, si on considère que l’on ne doit commiter qu’une configuration testée, la configuration qui correspond au repo avec les quelques fichiers commités n’as pas été testée sur le poste du développeur (puisque d’autre fichiers modifiés y sont aussi). Au final, comment peut on faire un commit en toute tranquilité autrement qu’en recherchant tous les fichiers modifiés sur le poste et de les commiter d’un seul bloc ? La bonne pratique consiste donc à mettre en place des mécanismes qui favorisent le fait qu’on ait peu de fichiers à commiter à chaque fois !
7) stage parts of files
Je me suis effectivement retrouvé sur des projets où après avoir fait un CTRL+SHIFT+F dans mon IDE préféré pour reformater automatiquement le code, 96% du fichier était considéré comme modifié, alors que je n’avais modifié que deux lignes. Cela m’est vraiment arrivé dans ces proportions ! Dans ce cas, ma technique est de commiter une première fois le fichier avec aucune modification sauf le reformatage, et un message de commit dans ce sens. Puis dans un 2nd commit, il n’y avait cette fois que les 2 lignes modifiées. Mais là encore, c’est un bad smell XP. En XP, une des pratiques est la propriété collective du code. Hors, comment peut on se promener partout dans le code comme si c’était le nôtre alors que chacun à sa propre façon d’écrire le code et de le formater ? La bonne pratique consiste à mettre en place consensuellement des conventions de codage.
8) craft your commits
Là, je n’ai as encore compris, sans ironie aucune.
9) Not Just for Teams of Coders
Alors là, je veux bien parier une bière ;o) Moi qui suis technicien depuis 10 ans, il m’a fallu plusieurs heures de lecture, d’utilisation, de réaction à des posts de blog pour sentir la philosophie de la gestion de version décentralisée, et l’auteur voudrait me faire croire que des non codeurs accèptent aiséement le schmilblicks et rentrent facilement dedans ?!… Mon estime de moi en prend un sacré coup 😉
10) In closing
“a number of really good free resources online to help you learn and use Git” : c’est pas bon signe si il y a besoin d’un aussi grand nombre de ressources pour utiliser Git ;o)
“you have to use a typewriter instead of a computer”… Là je suis d’accord !… Et XP prône l’utilisation de la fiche cartonnée (SVN ?) ;o)
11) Essayer une idée chez soi le week end
En quoi svn avec ses traditionnelles copies de travail locales freinent ce papillonage ??? Effectivement, ces copies locales ne permettent pas de travailler durablement coupé du repo distant. Par contre je ne suis pas sure qu’il y ait beaucoup d’environnements de développements qui permettent d’être coupé de cet environnement, de travailler chez soi (serveur d’application, base de données, gestionnaire de bug…). Remarque je ne suis pas sure que cela soit une bonne chose en soi. Par contre, là encore je crie au bad smell. Si c’est occasionnel de travailler chez soi le week end (une fois par millenaire), le développeur n’a peut être pas besoin d’être branché au repo distant. Et dans le cas contraire, cela n’est pas compatible avec le binômage et les autres mécanismes de propriété collective du code, et de connaissance diffuse dans l’équipe (réunions de conception improvisées…).
Je pourrais par contre voir un intérêt de travail à distance dans le cadre d’une session chez le client, par exemple une phase de prototypage ou d’écriture de tests d’acceptation avec lui en Cucumber… Mais en XP le client est sur site (en tout cas on essaye ;o)
Soyons agile : revenons un peu au besoin !
Qu’est ce que je demande à mon gestionnaire de version ?
Centraliser une version cohérente de l’ensemble de mes fichiers
…
Avec le recul, cet engouement pour Git, au lieu de faire penser à celui de Subversion à l’époque, me fait plutôt penser à celui pour J2EE et les EJB…
Au final, toutes ces nouvelles fonctionnalités, branching facilité (dans tous les sens ?), staging area (commit au bon vouloir… au hasard ?), stage parts of files (je code comme je veux !), la notion même de décentralisation (peu/pas compatible avec le binômage et la connaissance diffuse dans l’équipe) semble être la porte ouverte à des pratiques anti-XP voire destructrices sur un projet XP. S’ajoute à cela le temps de compréhension de la notion de décentralisation et le temps que l’on passe à merger et synchroniser. Je suis définitivement convaincu qu’il n’y a aucun intérêt et aucune raison à brancher et merger à foison, ce qui est l’argument de vente no de Git.
Sinon ok, on peut utiliser Git, mais alors de la même manière que SVN ;o)
Au final, la critique de cet article m’a fait passé du stade de curieux interrogatif à celui de réfractaire effrayé pour ce qui est de l’utilisation de Git dans une équipe XP (donc centralisée). La seule interrogation ouverte, est l’utilisation dans le cadre du pull sur un repo de production pour déployer les livrables en environnement de production : à creuser.
Je me pose la question uniquement du repo qui contient tous les documents de la société (si on ne souhaite pas de GED) : brochures et propositions commerciales, CV des collaborateurs, originaux des cartes de visite, du logo… Dans ce cadre, les éditeurs/commiteurs d’un même fichier ne sont pas légion et surtout la plupart de ces fichiers sont au format binaire : quid des branches et des merges ?
Par contre, je suis définitivement convaincu de l’intérêt de la gestion de version décentralisée pour le versioning de mes fichiers personnels afin de pouvoir facilement les editer en déplacement. Mais là on est plus dans un environnement d’équipe, mais bien individuel, et donc peu voir aucun intérêt pour les branches et les merges. Et là, je préfère utiliser SVK, car en tant qu’extension de SVN, il peut être branché sur n’importe quel repository SVN existant.
Enfin, je n’ose émettre aucune critique quand à l’utilisation de Git dans une équipe de développement “traditionnelle” (non XP), ou sur un projet open source et/ou une équipe décentralisée.
