"Comment vois-tu l'adoption de Git en entreprise".
C'est clair que Git est pénalisé par l'image de Geek qui lui colle à la peau : construit par Linus Torvald, utilisant la ligne de commande avec des options tortueuses, ...
FlashBack :
Quand j'ai commencé à bosser, on attaquait tous en telnet un serveur de dev, sur lequel code source et résultat de compilation était allègrement mélangés dans des répertoire ou tout le monde tapait son code sous vi/emacs, sans plus de gestion de version en dehors de la sauvegarde hebdomadaire sur bande.
Quelques années plus tard, première révolution avec Visual Age et son gestionnaire de version centralisé, basé sur la prise de verrous sur les fichiers. On entre dans un mode de concurrence et de gestion collaborative, où chacun dispose d'une copie de travail dédiée sur son poste de développement.
Plus tard, seconde révolution avec CVS puis SVN : l'absence de verrous permet de travailler sans "subir" les actions en cours des autres développeurs. La problématique des merge apparaît, mais l'outil est tout de même assez efficace pour les gérer, en particulier sous Eclipse qui devient notre environnement quotidien.
Aujourd'hui, les DVCS portent une nouvelle révolution : la séparation du workflow projet et de celui du développeur. Le travail local, basé sur des tentatives multiples, des retours arrière, des recherches dans l'historique, bénéficie pleinement d'un gestionnaire de version. Pour autant, le reste de l'équipe ne subit pas vos diverses branches et commits en tout genre. Le merge de branche devient étonnement efficace, le mot "branche" n'est plus synonyme de "galère".
Il ne fait aucun doute pour moi que les DVCS vont s'imposer, alors to Git or not to Git ?
D'une part, Git est nativement supporté dans Eclipse (bien que ce soit encore améliorable) ce qui devrait faciliter les choses. Les outils graphiques comme TortoiseGit facilitent aussi son utilisation. La ligne de commande reste le plus efficace, mais avec le temps et le murissement de ces outils, on devrait pouvoir s'en passer progressivement (enfin, pour ceux qui veulent).
Reste que les concepts sont encore neufs et qu'il va falloir ses les approprier. Pour ça il faut des précurseurs, qui porteront ainsi le reste de l'équipe et assureront le support de niveau 1 - et Git-svn va nous y aider.
Git-svn permet d'utiliser Git en local avec tous les avantages que cela implique, sans que la référence svn soit impactée. Ceux qui doivent effectuer des opérations non triviales (refacotring), ou bien passer souvent d'une tâche à l'autre (corrections de bugs), ou encore qui ont une culture geek pourront le tester, l'apprivoiser, puis l'adopter. Contrairement aux autres "révolutions" que j'ai évoqué, celle-ci va se faire en douceur. Une fois que l'équipe aura utilisé au moins une fois Git sur son poste, le remplacement de SVN sera naturel.
Après tout, il y a 13 ans (putain, 13 ans !) si j'avais parlé de faire une branche alors qu'on avait besoin d'éditer avec vi un même fichier depuis notre telnet, je serais passé pour un geek (en fait, c'était déjà le cas pour d'autres raisons). Je me rappelle aussi une discussion interminable avec un I.Q. lors du passage à CVS, lorsque j'expliquais qu'on travaillait à plusieurs sur le même fichier, sans mécanisme de verrou ...
Aucun DSI n'imposera Git à ses équipes, par contre les équipes qui y ont goûté le réclameront rapidement. Il y aura donc, comme toujours, les boîtes qui savent suivre le mouvement à temps et celles qui courent derrière le train. C'est aussi à toi, fidèle lecteur, de faire du lobbying, selon la catégorie dans laquelle tu veut entrer. Fais toi la main, parles en et montre le à tes collègues, râle un bon coup sur SVN, et le projet "pilote" pointera le bout de son nez.
0 commentaires:
Enregistrer un commentaire