Les DVCS sont-ils adaptés au développement en entreprise ?
Par Clochix le samedi 30 août 2008, 12:52 - Technoweb - Lien permanent
Une des tendances lourdes des projets de logiciels libres depuis quelques mois est de migrer leur code source vers des gestionnaires décentralisés (DVCS). Mais au delà du phénomène de mode, cette migration a-t-elle un intérêt dans un contexte de développement professionnel de sites et d'applications web ?
Après quelques jours passés à lire des articles un peu partout, je commence à en douter. Le développement en entreprise ressemble peu à celui des logiciels libres, et dans ce contexte, pour ce que j'en ai lu, les DVCS ne semblent pas apporter grand chose.
Leurs deux principales caractéristiques généralement mises en avant sont:
- ils s'adaptent parfaitement au bazar, la méthode de développement qui a fait le succès de nombreux projets libres comme le noyau Linux. Chaque développeur a son propre dépôt local, sur lequel il effectue ses commits. Il possède ainsi l'équivalent d'une branche personnelle avec laquelle il peut jouer sans être limité par des restrictions d'accès par exemple. Les développeurs synchronisent ensuite leurs dépôts entre eux, échangent leurs patchs comme des cartes dans la cours de récréation, etc. Les logiciels fournissent des outils pour simplifier les fusions et les résolutions de conflits. Il n'y a pas de dépôt central faisant foi (du moins le modèle n'en impose pas, on peut ensuite décider d'utiliser un dépôt comme référence). Mais le développement en entreprise s'apparente lui plus souvent à la réalisation d'une cathédrale, avec un architecte qui donne des tâches précises à différentes équipes et a besoin de centralisation, d'avoir une vue claire sur l'avancée des développements. Il n'y a pas vraiment de place pour l'expérimentation.
- les DVCS permettent une utilisation sans être connecté au réseau, ce qui augmente leur rapidité et minimise le trafic: dans un contexte professionnel, cela a peu d'intérêt. Même si dans les boîtes modernes, les développeurs ont tous des portables, l'essentiel du développement s'effectue (ou en tout cas devrait s'effectuer) pendant les heures ouvrés, donc avec une bonne connexion.
Certes, les DVCS offrent toutes les fonctionnalités de Subversion, et il est tout à fait possible de migrer sans pratiquement rien changer à son mode de fonctionnement, et en utilisant ensuite les nouvelles fonctionnalités de l'outil au fil des besoins. Mais dans ce cas comment justifier le coût de la migration (car hélas dans le système stupidement capitaliste qui est le nôtre, les entreprises basent souvent leurs choix sur des critères bassement économiques et non sur les envies de leurs grouillots de découvrir de nouvelles technos hype). Je me pose d'ailleurs la même question pour une migration de Trac à Redmine, lui aussi très en vogue en ce moment, mais dont je n'ai pas encore trouvé d'avantage décisif par rapport à Trac.
Est-ce que dans le cadre de développements impliquant plusieurs acteurs (maquettage et intégration finale en France, intégration HTML et développement dans des pays où les travailleurs sont encore plus mal payés), l'utilisation d'un système décentralisé a plus d'intérêt ? Peut-être, et dans ce cas le travail sans être connecté à un dépôt central prend tout son intérêt. Encore faut-il trouver des prestataires utilisant les mêmes mêmes outils que vous[1] et surtout se mettre d'accord sur la méthode de travail, les processus et les workflows pour réussir à organiser le bazar.
Bref, pour l'instant je ne suis pas convaincu. Je vais sans doute tester un DVCS pour un projet perso[2], mais dans ma boîte, je pense que je vais continuer à préconiser Subversion.
Et toi, Googlebot, fidèle lecteur, t'en penses quoi ??? As-tu des retours d'expérience d'utilisation d'un DVCS dans un contexte de développement web professionnel ? Tout avis sera le bienvenu.
Notes
[1] et autant Subversion fait aujourd'hui à peu près l'unanimité, autant dans le monde des gestionnaires décentralisés il n'est pas simple de choisir entre au moins 4 logiciels aux fonctionnalités assez similaires
[2] enfin non, puisqu'il faudrait que j'arrive à me décider entre Git, Mercurial et Bazaar, et c'est pas demain la veille que j'arriverai à trancher une pareille question. Pour l'instant je penche plutôt pour Mercurial à cause de la disponibilité de plus d'outils sous windows, cette £$%ùµ*§!erie que quelques développeurs inconscients s'acharnent encore à utiliser, mais j'hésite, j'hésite.
Commentaires
Effectivement, à ce jour, il n'y a peut être pas encore d'intérêt en entreprise (sauf si le développeur est très mobile et du cout, avoir un dépot local a son sens..).
Perso, c'est ce qui m'avait fait retenir un DVCS (mercurial) à l'époque sur Subversion, le fait de pouvoir gérer un dépot local sur mon portable et ainsi commiter dans le RER... Aujourd'hui, ne codant plus qu'à la maison, je pourrais très bien repasser sur un subversion (et profiter des svn:externals) car tous les projets que j'utlise sont massivement en svn...
Le problème des DVCS à ce jour est à mon sens l'interopérabilité avec les autres (D)VCS. Si perso j'utilise mercurial, alors c'est la misère si je dois récupérer du code du projet X qui utilise SVN et du projet Y qui utilise git. Les svn:externals n'existent pas encore dans les DVCS (sauf peut être git) et c'est une grosse lacune à mon sens. Le must serait un (d)vcs:externals compatible avec tous les (D)VCS pour faciliter l'intégration de code dans un projet quelque soit le type de dépot utilisé.
Sur le choix bzr / hg / git, j'avais pris mercurial (hg) car c'était en python (et donc même socle techno que mes projets en django) et aussi parce que comme je l'ai lu je ne sais plus ou, "hg", sur le clavier, c'est vachement plus pratique à taper que git ou bzr...
Pour le Trac vs Redmine, je dirais qu'en natif tu as sous Redmine plus de choses que sous Trac. Tu as aussi et surtout le multiprojet en natif et ça c'est pas rien je trouve de pouvoir tout centraliser sur une instance (pour la maintenance du socle notamment).
Cf aussi : http://www.unelectronlibre.info/jou...
++
Nico
Merci Nico, je ne m'étais pas aperçu de l'absence d'un équivalent à
externals, et c'est l'argument qui me convainc de rester sous Subversion (d'autant qu'externalsa été encore amélioré dans la 1.5, je vais essayer d'en dire 2 mots rapidement).Pour ce qui est de commiter dans le RER, ça m'intéresse peu, pendant les trajets je suis plus en mode conception que développement (j'ai pas encore trouvé d'astuce pour poser un portable sur le guidon de mon vélo).
Sinon, il me semble que Bazaar est aussi en Python. Mais ton argument en faveur de hg est convainquant ! (accessoirement, Mercurial est le logiciel qui a été choisi par la fondation Mozilla, et comme j'ai de plus en plus envie de plonger dans les entrailles de la bête, je pense que c'est vers lui que je vais me tourner).