REX - Passage de CVS à Git
Pierre Templier
@ptemplier
Ippon Technologies © 2015
Sommaire
● Contexte
● Migration technique
● Choix workflow(s) de travail
● Accompagnement et mis...
Ippon Technologies © 2015
Contexte
● Client utilisant CVS au sein d'une petite équipe : ~10 personnes.
● Volonté de change...
Ippon Technologies © 2015
Migration technique (1)
● Utilisation de cvs2svn qui dispose d’un module cvs2git : http://cvs2sv...
Ippon Technologies © 2015
Migration technique (2)
● 4 repositories CVS
○ ~200 projets
○ Chaque repo CVS contient beaucoup ...
Ippon Technologies © 2015
Utilisation
● Repositories exposés via GitBlit
○ Webapp java
○ Gestion des Droits
○ Recherche
○ ...
Ippon Technologies © 2015
Impact hors développement
● Faibles impacts sur l’usine logicielle
● Changement de l’url scm dan...
Ippon Technologies © 2015
Workflows utilisés
Centralisé
Feature Branches
Gitflow
Ippon Technologies © 2015
Configuration commune
// renseignements sur l'utilisateur présents dans les commits
git config -...
Ippon Technologies © 2015
Mise en oeuvre
● Volonté de l'équipe d'utiliser le client graphique Git intégré à Eclipse
● Habi...
Ippon Technologies © 2015
Problèmes - Eclipse
● Impossible de comparer un fichier lors d'un merge
● Présente des fichiers ...
Ippon Technologies © 2015
Problèmes - Habitudes
● Volonté de récupérer uniquement les changements sur certains fichiers
● ...
Ippon Technologies © 2015
Leçons tirées
● Il ne faut pas sous estimer le travail d'accompagnement pour passer à Git et oub...
Ippon Technologies © 2015
Bénéfices
Ce qu’en tirent les développeurs
○ Un certain confort à travailler en local (plus de c...
Questions ?
Contact : @ptemplier
Prochain SlideShare
Chargement dans…5
×

REX - Passage de CVS à Git

1 445 vues

Publié le

Passer à Git pour une équipe qui travaille tous les jours avec CVS.
De la migration technique au choix du workflow de travail en passant par l'accompagnement nécessaire.
Nous dresserons le bilan des problèmes rencontrés ainsi que des bénéfices retirés lors de cette migration.

Publié dans : Technologie
3 commentaires
2 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
1 445
Sur SlideShare
0
Issues des intégrations
0
Intégrations
374
Actions
Partages
0
Téléchargements
25
Commentaires
3
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

REX - Passage de CVS à Git

  1. 1. REX - Passage de CVS à Git Pierre Templier @ptemplier
  2. 2. Ippon Technologies © 2015 Sommaire ● Contexte ● Migration technique ● Choix workflow(s) de travail ● Accompagnement et mise en oeuvre ● Bilan : problèmes et bénéfices CVS
  3. 3. Ippon Technologies © 2015 Contexte ● Client utilisant CVS au sein d'une petite équipe : ~10 personnes. ● Volonté de changer pour quelque chose de plus récent. ● 2 solutions envisagées : SVN et Git ○ Client d'abord tenté par SVN car peu de changement dans l'utilisation par rapport à CVS. ○ Mais un projet a été réalisé par une société externe sur un repo privé GitHub, le choix de Git s'est donc fait sur la facilité de récupérer l'historique de ce projet.
  4. 4. Ippon Technologies © 2015 Migration technique (1) ● Utilisation de cvs2svn qui dispose d’un module cvs2git : http://cvs2svn.tigris. org/cvs2git.html ● Besoin d’accéder physiquement à une copie du repo CVS ● Fichier de config permettant ○ De transcoder les utilisateurs (trigramme => “Prénom Nom” + Email) ○ D’exclure des fichiers/dossiers inutiles ■ ‘target' ou ‘src/webapp/WEB-INF/lib’ ● En sortie, 2 fichiers au format fast-import ○ git --bare init . ○ cat git-{blob,dump}.dat | git fast-import
  5. 5. Ippon Technologies © 2015 Migration technique (2) ● 4 repositories CVS ○ ~200 projets ○ Chaque repo CVS contient beaucoup de projets qui n'ont rien à voir entre eux ● 1 répertoire du repo CVS deviendra un repository Git ● Création d'un script bash pour automatiser les exports vers des repositories Git ● Avant la migration on verrouille en écriture chaque repository CVS ○ touch writers
  6. 6. Ippon Technologies © 2015 Utilisation ● Repositories exposés via GitBlit ○ Webapp java ○ Gestion des Droits ○ Recherche ○ Navigation dans le code ○ Statistiques ○ Historique des commits
  7. 7. Ippon Technologies © 2015 Impact hors développement ● Faibles impacts sur l’usine logicielle ● Changement de l’url scm dans le pom : utilisé par le plugin maven release ● Ajout du plugin Git dans Jenkins ● Création d’un utilisateur Jenkins dans Gitblit et renseignement des credentials dans le settings.xml maven utilisé par jenkins
  8. 8. Ippon Technologies © 2015 Workflows utilisés Centralisé Feature Branches Gitflow
  9. 9. Ippon Technologies © 2015 Configuration commune // renseignements sur l'utilisateur présents dans les commits git config --global user.name "John Doe" git config --global user.email johndoe@mycorp.com // sauts de lignes Linux dans les sources git config --global core.autocrlf true // pull --rebase par défaut pour éviter de polluer l'historique git config --global branch.master.rebase true git config --global branch.autosetuprebase always // stocke le mdp en clair pour ne pas le retaper git config --global credential.helper store Utilisation de rebase lors des pull
  10. 10. Ippon Technologies © 2015 Mise en oeuvre ● Volonté de l'équipe d'utiliser le client graphique Git intégré à Eclipse ● Habitude de fonctionner avec le client CVS d’Eclipse ● Habitude de rester dans l’IDE pour les interactions SCM ● Migration des projets un par un plutôt que tout d'un coup ● Formation initiale sur le poste du développeur ● Différentes zones de travail : Workspace, Index, Repository Local, Repository Distant ● Les commandes à connaître : clone, commit, push, pull, stash, reset ● Explication du paramétrage pull --rebase ● Savoir où on en est : `git status` / vue historique Eclipse ● Incitation à créer des branches dès que le besoin s’en fait sentir (feature branch) ● Puis aide au fur et à mesure des besoins/problèmes. ● Dans l'équipe 2 autres personnes avaient déjà travaillé avec git, cela a facilité la monté en compétence car plusieurs personnes pouvaient aider. ● Pas de modification de commits déjà publiés (i.e. pas de push --force ) ● Interdit au niveau de Gitblit
  11. 11. Ippon Technologies © 2015 Problèmes - Eclipse ● Impossible de comparer un fichier lors d'un merge ● Présente des fichiers comme modifiés alors qu'il ne sont pas modifiés ○ info différente de git status ● Impossible de comprendre ce que fait le "mark as merged" ● Résoudre un conflit en faisant add n'est pas intuitif sous eclipse ○ git status nous donne directement cette information ● Lorsqu'un push échoue, message d’échec que l'on prend pour un succès ● Obligation de jongler entre les vues Eclipse ○ Vue Projet ○ Vue Git Repositories ○ Vue Historique ○ Vue Staging
  12. 12. Ippon Technologies © 2015 Problèmes - Habitudes ● Volonté de récupérer uniquement les changements sur certains fichiers ● plutôt que tous ceux ramenés par un pull ● Pull implique de commiter ou stasher ses changements au préalable ● Tendance à garder 1 projet par branche dans son workspace ● 1 branche sur master ● 1 branche sur develop ● Nouveau vocabulaire, nouveaux concepts ● Commit a un sens différent en CVS et en Git ● Stash est une pile si on sauve plusieurs fois ses fichiers temporaires ils ne sont plus sur le dessus de la pile et 'git stash pop' ne les ramène pas
  13. 13. Ippon Technologies © 2015 Leçons tirées ● Il ne faut pas sous estimer le travail d'accompagnement pour passer à Git et oublier ses habitudes CVS. Il est important que personne ne reste bloqué à cause de l’outil, il faut donc qu’il y ait toujours une personne capable de dépanner sur Git. ● Mieux vaut passer petit à petit les projets sous Git : cela permet de monter sereinement en compétence sur Git et d'abord sur des petits projets ● Le client en ligne de commande donne souvent des informations plus pertinentes qu'Eclipse et est plus prédictible ● Changement d’habitude dans le workflow de travail : commits réguliers en local puis push après revue de ces commits, le fait d’avoir 2 étapes permet plus de vérification et de réorganiser ses commits avant de pusher (squash ou rebase interactif).
  14. 14. Ippon Technologies © 2015 Bénéfices Ce qu’en tirent les développeurs ○ Un certain confort à travailler en local (plus de commits régulièrement) ○ Une préparation plus fine des commits avant de les publier ○ Un facilité à travailler sur des branches dès que le besoin s’en fait sentir ○ Renommages de fichiers bien suivis ○ Commits comme un ensemble cohérent de changements sur différents fichiers ○ Historique complet notamment lors du merge de branche (pas d’info sur les branches mergées en CVS) ○ Graphe historique/branches permet de bien se repérer dans les sources ○ Rapidité générale du système ○ Facilité de report d’un hotfix via cherry-pick Dans le futur On pourrait envisager d’utiliser des workflow de type Pull Request, notamment à des fins de code review systématisé
  15. 15. Questions ? Contact : @ptemplier

×