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

1 © Fujitsu CanadaINTERNAL USE ONLYINTERNAL USE ONLY

On merge !!!

Vincent GrondinArchitecte de solution .NETMVP C#.NET Montreal User Group LeaderBlog: http://geekswithblogs.net/vincentgrondin


Disclaimer !

Mes opinionsMes idéesMes expériencesMes trucsLa réalité d’un projet actuel, le bon et le mauvais

…. plusVos opinionsVos idéesVos expériencesVos trucs


Description du contenu Lexique

Un merge c’est…

Les éléments d’un merge réussi

Ta branche, tes merges…

Ma check list

Scénario de merge fréquents

Vidéos & Commentaires


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?


Lexique


Lexique

Code Base: L’entiè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 d’un 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 d’un merge, amener le code de la destination vers la source

originale de la branche . (typiquement vous intégrez vos changements à ceux des autres)


Lexique

3 way diff merge: 3 versions pour refaire l’histoire de ce qui c’est 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


Un merge c’est…

Qu’est-ce qu’un merge?Pourquoi on merge?


Qu’est-ce qu’un merge?

C’est l’inverse d’un « 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.

C’est une des opérations que vous permet de faire votre outil de visualisation de différence à l’aide de votre source control. Q: Est-ce qu’on peut faire un merge sans source control? R: Est-ce qu’on peut se faire arracher des dents sans anesthésie, oui…


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





Prendre son temps et le faire à tête reposéeFaites-le par un DEV expérimenté du projetNe pas hésiter à demander de l’aideAvoir les bons outilsAvoir une bonne checklist éprouvéeNe pas se faire trop dérangerFaites-le souvent et à des moments fixesAvertissez vos collègues avant et après un mergeSoyez certain de votre coup avant de prendre action3 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?)



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

N’oubliez pas de faire votre check-in COMPLET…

SURTOUT, SURTOUT PAS DE CHERRY PICKING !!!





Si je dois te faire une branche… Tu t’occupes 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 d’avoir 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 n’as pas le GO (testeurs)


Ma check list


Ma check list

Créez-vous un clean TARGET WorkspaceLock TARGET en Check-in (si gros merge)On ouvre pas la solution AVANT le mergeGet 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


Ma check list

Executez vos .TT ou Regénérez vos EDMX / DBMLRefaire les Service Reference (update)Compilez votre solutionDébuggez les erreurs de compilationRoulez vos unit testsCheck-in avec pattern précis de commentaires (# Changeset)Le lock sera auto released lors du check-inAvertir vos collèguesDemander des tests de régression


Scénario de merge fréquents

Bug Fixing vs RefactoringBug Fixing vs Fichier EffacéConfig File vs EnvironnementsFichiers de solution


Bug Fixing vs Refactoring

Branche : Iteration1 & Bug Fixing

Branche : Iteration2 & Refactoring

Classe Employe Méthode TrouverAge

Fix1

Fix2

Fix3

Refact 1



Avant le fix:

Après le fix 3:

Fix3



Refactor 1 dans Iteration2 :

Tout est beau on prend le target et on Check-in puisque le code n’existe plus?

Quelles sont vos options? View Target History Annotate & Parler à la personne qui a fait le changement

Refact 1


Bug Fixing vs Fichier Effacé

Branche : Iteration1 & Bug Fixing

Branche : Iteration2 & Refactoring

Classe Employe

Fix1

Fix2

Fix3

Del. file


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


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 l’ité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…


Config File vs Environnements

Au fil des jours… Les fichiers de config dans la branche 2 n’ont 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 aujourd’hui 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 c’est toute l’équipe qui est arrêtée… Tout semblait bien aller avant qu’ils fassent un GET LATEST

VERSION… On dirait que le schéma de DB est revenu à celui de IT1 !!! Ben non…


Fichier de solution

Essayez mais… pas trop longtemps Typiquement très difficile à merger sans faire d’erreurAnnotez la source et répliquez dans la destinationSi 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


Vidéos et Commentaires


On merge !!!

Vincent Grondin.NET Solution ArchitectC# MVP.NET Montreal User Group LeaderBlog: http://geekswithblogs.net/vincentgrondin

Documents

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