REX - Passage de CVS à Git
-
Upload
pierre-templier -
Category
Technology
-
view
711 -
download
4
Transcript of REX - Passage de CVS à Git
REX - Passage de CVS à GitPierre Templier
@ptemplier
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
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.
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
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
Ippon Technologies © 2015
Utilisation● Repositories exposés via GitBlit
○ Webapp java
○ Gestion des Droits
○ Recherche
○ Navigation dans le code
○ Statistiques
○ Historique des commits
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
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 --global user.name "John Doe" git config --global user.email [email protected]// 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 truegit 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
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
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
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
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).
Ippon Technologies © 2015
BénéficesCe 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é
Questions ?
Contact : @ptemplier