1 © Fujitsu Canada On merge !!! Vincent Grondin Architecte de solution.NET MVP C#.NET Montreal User Group Leader Blog:

2 © Fujitsu Canada Disclaimer ! Mes opinions Mes idées Mes expériences Mes trucs La réalité dun projet actuel, le bon et le mauvais …. plus Vos opinions Vos idées Vos expériences Vos trucs

3 © Fujitsu Canada Description du contenu Lexique Un merge cest… Les éléments dun merge réussi Ta branche, tes merges… Ma check list Scénario de merge fréquents Vidéos & Commentaires

4 © Fujitsu Canada Avant de commencer… Qui travail sur un projet comportant des merges? Qui a déjà fait des merges inter-branches (pas locaux)? Qui aime / aime pas faire des merges? Quels outils utilisez-vous pour vous aider? Avez-vous une recette ou vous y allez au pif?

5 © Fujitsu Canada Lexique

6 © Fujitsu Canada Lexique Code Base: Lentière totalité de votre code dans le source control Branch: Un point dans le temps à partir duquel vous « copiez » votre Code Base ou un partir de celui-ci Pull: Lors dun merge, amener le code de la source originale de la branche vers la destination. (typiquement vous intégrez les changements des autres à vos changements) Push: Lors dun merge, amener le code de la destination vers la source originale de la branche. (typiquement vous intégrez vos changements à ceux des autres)

7 © Fujitsu Canada Lexique 3 way diff merge: 3 versions pour refaire lhistoire de ce qui cest passé avec votre fichier La version dans la branche source qui a évolué La version dans la branche de destination qui a évolué La version du fichier au moment de créer la branche (ancêtre commun) Branch, Merge, Edit, Merge-Edit, Deleted

8 © Fujitsu Canada Un merge cest… Quest-ce quun merge? Pourquoi on merge?

9 © Fujitsu Canada Quest-ce quun merge? Cest linverse dun « Branch ». Quand une partie de code se sépare et évolue distinctement dans le temps dans votre source control, elle peut ou non être appelée un jour à être fusionnée en un seul tout de nouveau. Cest une des opérations que vous permet de faire votre outil de visualisation de différence à laide de votre source control. Q: Est-ce quon peut faire un merge sans source control? R: Est-ce quon peut se faire arracher des dents sans anesthésie, oui…

10 © Fujitsu Canada Pourquoi on merge? Vous avez fait un « Feature Branch » et le code est prêt à être ramener avec le reste de la solution. Vous voulez amener des correctif vers une livraison future. Résolution de conflits = micro merge

11 © Fujitsu Canada Les éléments dun merge réussi

12 © Fujitsu Canada Les éléments dun merge réussi Prendre son temps et le faire à tête reposée Faites-le par un DEV expérimenté du projet Ne pas hésiter à demander de laide Avoir les bons outils Avoir une bonne checklist éprouvée Ne pas se faire trop déranger Faites-le souvent et à des moments fixes Avertissez vos collègues avant et après un merge Soyez certain de votre coup avant de prendre action 3 way diff merge ou outil « Code Aware » Ne pas croire que 0 conflit = Go ! Allez-voir le résultat… Roulez vos unit tests (espérons que vous en avez?)

13 © Fujitsu Canada Les éléments dun merge réussi Attention aux éléments suivants: App.Config Text Templates (tt) Generateurs comme EDMX, DBML etc… Service References ou autres fichiers générés Scripts SQL (???) Fichiers de projet Fichiers de solution Noubliez pas de faire votre check-in COMPLET… SURTOUT, SURTOUT PAS DE CHERRY PICKING !!!

14 © Fujitsu Canada Ta branche, tes merges…

15 © Fujitsu Canada Ta branche, tes merges… Si je dois te faire une branche… Tu toccupes de tes merge (pull & push) Tu te crée ton build et tu répares tes builds rouges Tu pull souvent et je vais te faire des rappels Tu ne push pas avant davoir fait faire les tests par les testeurs (build) Tu push juste si tu as le GO Tu continue à faire tes pull régulier tant que tu nas pas le GO (testeurs)

16 © Fujitsu Canada Ma check list

17 © Fujitsu Canada Ma check list Créez-vous un clean TARGET Workspace Lock TARGET en Check-in (si gros merge) On ouvre pas la solution AVANT le merge Get Latest du TARGET branch (pas de la solution) Trouver le Changeset et NOTEZ-LE. Right click sur la SOURCE, faites « merge » Choisir le bon TARGET (même que workspace) Choisir la bonne option (attention à Latest vs Changeset) GO ! Trier conflits par nom en ordre croissant (WTF Vince????) Visionner tous les conflits (Auto Resolve Conscient) Ouvrir toutes les solutions

18 © Fujitsu Canada Ma check list Executez vos.TT ou Regénérez vos EDMX / DBML Refaire les Service Reference (update) Compilez votre solution Débuggez les erreurs de compilation Roulez vos unit tests Check-in avec pattern précis de commentaires (# Changeset) Le lock sera auto released lors du check-in Avertir vos collègues Demander des tests de régression

19 © Fujitsu Canada Scénario de merge fréquents Bug Fixing vs Refactoring Bug Fixing vs Fichier Effacé Config File vs Environnements Fichiers de solution

20 © Fujitsu Canada Bug Fixing vs Refactoring Branche : Iteration1 & Bug Fixing Branche : Iteration2 & Refactoring Classe Employe Méthode TrouverAge Fix 1 Fix 2 Fix 3 Refact 1

21 © Fujitsu Canada Bug Fixing vs Refactoring Avant le fix: Après le fix 3: Fix 3

22 © Fujitsu Canada Bug Fixing vs Refactoring Refactor 1 dans Iteration2 : Tout est beau on prend le target et on Check-in puisque le code nexiste plus? Quelles sont vos options? View Target History Annotate & Parler à la personne qui a fait le changement Refact 1

23 © Fujitsu Canada Bug Fixing vs Fichier Effacé Branche : Iteration1 & Bug Fixing Branche : Iteration2 & Refactoring Classe Employe Fix 1 Fix 2 Fix 3 Del. file

24 © Fujitsu Canada Bug Fixing vs Fichier Effacé TFS vous dit que le target est effacé et vous demande si vous voulez le ressusciter et le merger ou si vous le laissez comme effacé… On ressuscite le fichier et on merge dedans? On keep target et on fait rien? Annotate & Parler à la personne qui a fait le changement ou essayer de répliquer les changements vers la destination manuellement. Del. file

25 © Fujitsu Canada Config File vs Environnements Environnements et leur utilité DEV1 = Toujours le développement courant DEV2 = Toujours le support client et développement itération précédente Branche 1: Iteration1 dans environnement DEV1 Connection Strings pointent sur DEV1 Service references pointent sur DEV1 Infra pointe sur DEV1 (msmq, ADLDS, autre) Arrive litération 2… On crée la branche 2 à partir de la branche 1… La branche 2 devient notre développement courant donc tout est OK… On modifie les app.config de toute la branche 1 pour passer à DEV2…

26 © Fujitsu Canada Config File vs Environnements Au fil des jours… Les fichiers de config dans la branche 2 nont pas changé… Quelques bugs importants dans la branche 1 ont été corrigés… On veut avoir ses bug fix dans la branche 2… On fait nos merges fréquemment et aujourdhui on fait IT1 -> IT2… Le merge commence… Vous faites la commande merge… Vous réglez tous vos conflits… Vous rebuildez, vous faites rouler vos unit tests… Vous faites le check-in Quelques heures plus tard… Les devs ont des erreurs bizzares… ça a commencé par un dev, ensuite 2 et 3 puis maintenant cest toute léquipe qui est arrêtée… Tout semblait bien aller avant quils fassent un GET LATEST VERSION… On dirait que le schéma de DB est revenu à celui de IT1 !!! Ben non…

27 © Fujitsu Canada Fichier de solution Essayez mais… pas trop longtemps Typiquement très difficile à merger sans faire derreur Annotez la source et répliquez dans la destination Si les configurations changent (x86 vs AnyCPU ou autre): Ouvrez la solution source dans VS Faites « Keep target » dans votre conflit Ouvrez la solution target dans VS Répliquez dans le target ce qui est dans le config manager de la source

28 © Fujitsu Canada Vidéos et Commentaires

30 © Fujitsu Canada On merge !!! Vincent Grondin.NET Solution Architect C# MVP.NET Montreal User Group Leader Blog: