Dans une migration vers un autre gestionnaire de source, l'aspect humain est je pense beaucoup plus important que l'aspect technique. Je pense que pour réussir sa migration, il faut plusieurs ingrédients :
commencer par mettre en place une solution qui change le moins de chose possible, c'est à dire garder le même workflow (un repository centralisé qui sert à tout le monde)
mettre à disposition des docs très simples à suivre pas à pas pour les actions de base, c'est à dire :
faire un checkout
faire un commit
faire un merge
utiliser le DVCS pendant quelques temps sans changer les habitudes
Avec ce système, on voit déjà l'intérêt de Git ou Hg par une gestion des merges beaucoup plus puissante qui donne beaucoup moins de conflit, on peut aussi commencer à voir qu'on peut faire des commits dans son coin sans impacter personne et ainsi jalonner son travail.
Le changement du workflow peut se faire dans un second temps. Je suis d'accord avec toit qu'un workflow intégrateur est très intéressant mais il est plus facile de le vendre comme un changement d'habitude que comme un changement d'habitude et d'outil.
Si on regarde le projet PostgreSQL, ils ont fait une transition de CVS vers git, mais pour le moment, ils n'utilisent qu'une partie de git, par exemple ils se refusent à faire des merges et font uniquement des rebase pour garder un historique linéaire comme ils en avaient l'habitude avant. Ils ont maintenant les bases techniques pour faire des changement d'organisation plus tard. (voir à ce sujet l'article sur l'indispensable lwn : Lessons from PostgreSQL's Git transition
Pour terminer, il est intéressant de bien vendre sa migration. C'est à dire repérer dans l'outil actuel ce qui pose problème : dans une migration que j'ai eu à faire, on utilisait svn avec des branches et l'équipe était relativement nombreuse (une petit quinzaine). Les merges devenaient vraiment compliqué, malgré l'utilisation de svnmerge (plus tard intégré à la version 1.6 de svn si mes souvenirs sont bons). J'ai commencé à faire des essais avec git-svn, puis sur un développement que j'avais à faire avec quelqu'un d'autre nous avons travaillé à 2 avec git. L'opération étant concluante, il a fallu bien préparer la migration et convertissant tous les outils (divers scripts, intégration continue, génération des fiches de version logiciel, etc.) et préparer des docs hyper directives. La migration a pu être vendue sur la facilité des merges par rapport à l'outil précédent et le fait que tout soit prêt à l'avance a permit de limiter les problèmes techniques rencontrés et grandement facilité l'adoption.
[^] # Re: Indétrônable en entreprise
Posté par Étienne . En réponse à la dépêche Subversion 1.7. Évalué à 10.
Dans une migration vers un autre gestionnaire de source, l'aspect humain est je pense beaucoup plus important que l'aspect technique. Je pense que pour réussir sa migration, il faut plusieurs ingrédients :
Avec ce système, on voit déjà l'intérêt de Git ou Hg par une gestion des merges beaucoup plus puissante qui donne beaucoup moins de conflit, on peut aussi commencer à voir qu'on peut faire des commits dans son coin sans impacter personne et ainsi jalonner son travail.
Le changement du workflow peut se faire dans un second temps. Je suis d'accord avec toit qu'un workflow intégrateur est très intéressant mais il est plus facile de le vendre comme un changement d'habitude que comme un changement d'habitude et d'outil.
Si on regarde le projet PostgreSQL, ils ont fait une transition de CVS vers git, mais pour le moment, ils n'utilisent qu'une partie de git, par exemple ils se refusent à faire des merges et font uniquement des rebase pour garder un historique linéaire comme ils en avaient l'habitude avant. Ils ont maintenant les bases techniques pour faire des changement d'organisation plus tard. (voir à ce sujet l'article sur l'indispensable lwn : Lessons from PostgreSQL's Git transition
Pour terminer, il est intéressant de bien vendre sa migration. C'est à dire repérer dans l'outil actuel ce qui pose problème : dans une migration que j'ai eu à faire, on utilisait svn avec des branches et l'équipe était relativement nombreuse (une petit quinzaine). Les merges devenaient vraiment compliqué, malgré l'utilisation de svnmerge (plus tard intégré à la version 1.6 de svn si mes souvenirs sont bons). J'ai commencé à faire des essais avec git-svn, puis sur un développement que j'avais à faire avec quelqu'un d'autre nous avons travaillé à 2 avec git. L'opération étant concluante, il a fallu bien préparer la migration et convertissant tous les outils (divers scripts, intégration continue, génération des fiches de version logiciel, etc.) et préparer des docs hyper directives. La migration a pu être vendue sur la facilité des merges par rapport à l'outil précédent et le fait que tout soit prêt à l'avance a permit de limiter les problèmes techniques rencontrés et grandement facilité l'adoption.
Étienne