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

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

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.

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

5 réflexions au sujet de « J’étais cons-Git car je suis pro-agile… (2/2) »

  1. Il me semble pas que Git “oblige” à avoir une personne dédié au merge sur le “trunk” au sens svn.
    Je pense qu’il faut se “débarrasser” de la branche SVN pour appréhender la branche SVN, les deux branches se ressemblent mais la souplesse de Git permet d’organiser le travail en équipe de differentes façons.

  2. Pas mal de méconnaissance de l’outil tout de même…

    5) il faut bien comprendre que ce n’est pas juste “super rapide” mais *instantané*. et oui, ça change tout au niveau de la gestion des branches. Il faut le pratique pour vraiment s’en rendre compte mais en tant qu’ancien de SVN je peux te garantir que ta peur vient du fait qu’avec SVN on fait peu de branches (car c’est pénible à gérer), et donc chaque branche contient beaucoup de choses, ce qui rend les merges toujours plus complexes. On améliore le “context-switching” = on est amenés à faire des branches plus nombreuses mais plus petites = les merges sont plus simples.

    6) Je pense que tu n’as effectivement pas bien compris, la staging area permet de visualiser clairement le travail en cours. Il n’y a aucun équivalent dans SVN. Ce qui s’en approche le plus serait la changelist mais ça reste tellement éloigné… Évidemment qu’avec trouzemille outils on doit pouvoir obtenir le même résultat avec SVN, ou approchant, mais là on l’a tout le temps, avec ou sans outils.

    7) Le staging partiel est une killer feature, vraiment. Le cas que tu as donné est totalement hors de propos pour illustrer cette fonctionnalité d’ailleurs, elle ne le traite pas et n’est pas faite pour ça (rien ne peut traiter le reformatage massif efficacement dans un CVS). Elle est fait pour te permettre de redécouper ton travail, qu’il soit sur plusieurs ou un seul fichier, en plusieurs petits commits. Il arrive très souvent, à moins d’être un être venu du futur, d’arriver au stade où on est prêt à commiter mais on se rend bien compte qu’on a passé 2 ou 3 “étapes” sans commiter mais qui mériteraient d’être distinguées dans l’historique (genre j’ai ajouté 2 options dans mon fichier de config, je voudrais commiter d’abord le premier ajout, puis le second). Et bien on peut, tout simplement. Pas besoin de revenir dans le passé à coups de Ctrl+Z en se flageallant de ne pas avoir été plus prévoyant.

    8.) L’idée de “construire” son historique est intéressante, mais pour être appréhendée elle nécessite d’avouer qu’on fait des erreurs. Souvent. Par exemple il existe le “rebase interactif” qui permet de reprendre une série de commits et de les réordonner, de changer leur message, voir de les rééditer (pour les diviser en commits plus petit, ou au contraire les regrouper). Ça veut dire concrètement qu’on peut avancer en ne se préoccupant vraiment que de son dév: je développe, je commite souvent, avec des messages qui peuvent contenir des fautes je m’en fous pour l’instant l’important c’est que ma fonctionnalité soient développées et que mes commits soient unitaires. Quand j’ai fini, je vais revoir ma liste de commits et “faire le ménage” pour réorganiser mon historique, pour qu’il soit plus propre, mieux organisé, plus lisible pour les autres développeurs.

    9 & 10) je suis absolument d’accord avec toi. Git manipule des concepts qui peuvent sembler complexes. Pour une utilisation simple ce n’est pas plus compliqué que SVN, mais pour utiliser sereinement “git add -p” et “git rebase -i” il faut comprendre ce qui se passe derrière et c’est une autre paire de manches. À ne pas sous-estimer, beaucoup trop de pro-git survendent et mentent en disant que c’est simplissime.

    11) OK alors comparons le même scénario avec les deux outils ;)
    * j’ai une idée sympa dans le train, je démarre en local.
    → Git: “git init monprojet”
    → Svn: “svnadmin create /path/to/monprojet.repo && svn checkout file:///path/to/monprojet.repo monprojet”
    * pendant le dév, aucune différence
    * 2 jours plus tard je me rends compte que mon idée est bonne, je vais la mettre sur le serveur d’un copain qui me propose de me faire une place gratos:
    → Git (une fois avoir installé ma clé SSH sur le serveur du copain): “git remote add copain git+ssh://moi@serveur-du-copain && git push copain master”
    → Svn: je dois accéder au serveur avec un client ssh (easy) faire un dump de mon dépot local, et le réimporter sur le dépot distant, puis “svn switch http://nouvelle-url“. Je peux jeter mon dépôt local :(
    * 1 semaine plus tard le serveur de mon copain a brûlé.
    → Git: OK OSEF, je commite en local et j’investis sur un serveur dédié ou un hébergement github.
    → Svn: OK, historique perdu. Tant pis j’investis, je checkout, copie les fichiers, et commit avec un message triste genre “état initial du projet J+7″

    Dans aucun des deux cas ça n’a été dramatique, mais avec Git ça a carrément été sans aucune conséquence. Tu répondras “mais pourquoi n’as tu pas pris un serveur distant tout de suite ?”, ce à quoi je répondrai “parce que les bonnes décisions d’aujourd’hui sont les mauvaises de demain”.

    On ne prend pas toujours la bonne direction. Et même parfois on avait pris la meilleure compte tenu de de la situation d’alors, mais les situations changent.
    En fait, toutes ces commandes compliquées, tous ces concepts, ça n’a qu’un but et définit la seule vraie différence entre Git et Svn: Git offre le droit à l’erreur, tout simplement.

  3. Tout d’abord un grand merci Nicolas d’avoir pris le temps d’écrire un commentaire aussi détaillé. Je vais essayer de lui faire honneur ;)

    Pour info, j’avais aussi écrit ce post quelques temps après : http://inagua.ch/2011/04/12/git-puisque-tu-tacharnes-contre-moi-reveeeenge/

    5) J’attache également de l’importance à réduire le context-switching. Je n’ai effectivement jamais fait de branche, toutes ces années où j’ai travaillé avec SVN. J’ai beaucoup de chance.

    6) Je commence à mieux comprendre la staging area, qui effectivement offre un confort certain, mais… J’y reviens dans le point suivant et après…

    7 et 8) J’aime bien la théorie du staging partiel, vraiment. Cependant, dans la pratique, je suis contre. J’ai 9 fichiers dans la staging area, dont 3 qui correspondent à une issue… a) il y avait aussi un 4e mais je l’oublis dans le commit intermédiaire… Ou alors b) je pense bien à jouter ce 4e fichier, mais ce dernier a également été modifié dans le cadre de l’autre issue (avec les 6 autres fichiers)… Bref, si tu fait au final plusieurs commits pour découper ta staging area rien ne te garanti qu’ils sont bien chacun d’entre eux fonctionnels. Pour luter contre cela, la règle est de commiter le plus souvent possible, et tu commit (en une seule fois) tout ce que tu as en édition, car c’est cela que tu peux valider. De plus, nous traçons chaque commit avec le no de l’issue github associée (#issue_id dans le message du commit)… Il est donc important que ton commit soit juste sinon quel intérêt de le tracer ?

    9 et 10) Cool, ça me rassure !

    11) Sans rentrer dans le détail de ton scénario, ce qui pourrait vraiment faire un article intéressant, je regrette que bien trop souvent on prenne comme cas d’utilisation des “cas individuels”. Pour ma part, mon soucis et ma crainte portent sur des cas d’équipe (travaillant ensemble sur un même projet). Une personne seule, qu’elle travaille sur SVN ou Git, arrivera toujours à s’en sortir sans trop faire de bêtises. Mais je pense revenir la dessus sur mon prochain post…

    “As-tu changé d’avis depuis ?”… Voilà une bien bonne question… Voilà tout trouvé le sujet de mon prochain post.

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>