Category Archives: Visual Studio

[EN] Sql Server Data Tools a.k.a “SSDT” is released

You can find the announcement on the SSDT blog. SSDT is an evolution of the database projects on VS 2010. I use VS database tools since Datadude in VS2005 and  SSDT is a step forward in database programming with Visual Studio.

My top features:

  • LocalDB: you don’t need an sql instance to test your base

image

  • Designers: you can now write directly the code in an editor or modify the structure in the designer: They are synced to each other

image

@+

[EN] Links of the week (Nov 6th, 2011)

Some stuff I’ve seen this week and I’d like to share:

.Net/Langages

ALM:

@+

[FR] Ne restez pas dans l’ignorance: affichez les fichiers supprimés sur Team Foundation Server

Ce n’est pas vraiment une astuce, mais plutôt un conseil. Afficher dans l’explorateur de source les fichiers supprimés  vous permettra la plupart du temps de retrouver ces fichiers et donc de pouvoir consulter leurs historiques.

L’option se cache dans les options de Visual Studio:

image

Et les fichiers se présentent sous cette forme:

image

@+

[FR] Quels outils sur une machine de build?

On ne devrait jamais avoir à se connecter à une machine de build. Mais cela n’est vrai que lorsque le processus de build tourne rond. Mais des fois, tout déraille et il se peut que cela ne compile pas sur la machine de build, mais que cela compile sur les postes des utilisateurs (le fameux “ça marche sur ma machine”). Il y a plusieurs causes à cela:

Cause n°1. Certains développeurs “oublient” d’archiver des fichiers. Cela arrive bien trop souvent! Dans ce cas on est bien content d’avoir Visual Studio sur la machine de build pour pouvoir ouvrir le projet. Je conseille donc vivement d’avoir Visual Studio  sur chaque machine de build. Surtout que cette installation est souvent nécessaire pour certaines opérations. Des fois c’est plus tordu que cela: des références projets peuvent être remplacées par des références binaires vers des composants de la solution et cela change l’ordre de compilation. Cela ne se voit pas dans VS et comportement bizarre assuré! Il arrive aussi de devoir comparer le code à compiler à sa version précédente, dans ce cas, un outil comme KDiff est bien utile.

Cause n°2. Les dépendances des projets ont changé: un nouveau projet a besoin de compiler, ou un composant externe a besoin d’être installé. Dans ce cas, les logs de la build sont une bonne source d’indices. Mais des fois, il faut aller sur la machine, ouvrir le projet – comme pour la première étape – et ajouter le composant nécessaire. Je vous conseille de toujours maintenir une liste avec les composants à installer. Sur cette liste on retrouve généralement:

  • des composants graphiques ou non d’éditeurs tiers
  • des SDK Microsofts (comme par exemple celui de Blend: on l’oublie souvent celui là)
  • des utilitaires, générateurs de code ou autres.

Cause n°3. Rien à changé, mais le code ne compile plus. Il faut alors mettre les mains dans le moteur: voir si il y a un blocage dans le processus de build, analyser les scripts. Pour toutes ces raisons, rien de tel que Notepad++ et des Sysinternals tools pour cela. S’il faut debugger des programmes qui font parti du processus de build, il faut alors sortir les grands moyens. Quelques fois le remote debugger de Visual Studio suffit, mais lorsqu’il faut attacher un debugger au départ d’un projet, les Debuggings Tools sont nécessaires (Plus de détail ici).

Tous ces programmes n’ont pas besoin d’être installés, il suffit de copier les binaires. Pour être sûr d’avoir une machine de build à jour, il suffit de synchroniser un dossier contenant ces outils via le contrôleur de source de TFS. Un simple “get latest version” permet ensuite de mettre à jour la machine.

@+

[FR] Le “Check In” sans règles: Highway to #fail!

Un changeset répond à plusieurs questions:
  • le “Qui”: l’auteur du checkin,
  • le “Quand”: la date,
  • le “Comment”: le code qui est ajouté au controleur de source,
  • le “Où”: l’emplacement dans le controleur de source,
  • le “Pourquoi”: le commentaire et les work-items associés.

 

Les 4 premières sont systématiquement connues car elles sont les éléments essentiels d’un changeset. Par contre le “Pourquoi” dépend du bon vouloir du développeur. Et souvent après plusieurs heures de code, le développeur, n’est pas très bavard: mais nous avons les moyens de les faire parler!

 

Plus globalement, nous allons nous servir du moment du check-in pour valider certaines choses relatives au futur code. Pour cela nous sommes aidés des politiques de check-in. Elles se configurent au niveau du paramétrage du controleur de source d’un projet. Certaines sont installées avec les power tools de TFS dont je recommande vivement l’installation:

image

 

Pourquoi ce “check in”?

Première utilité: améliorer la traçabilité du code. Si l’on ne sait pas pourquoi du code a été ajouté, il devient difficile de déterminer vers quoi évolue le logiciel. Il est donc important d’avoir au moins un commentaire lors du check-in et aussi un work item. Pour cela nous alons utiliser le “Changeset comments policy” et soit le “Work Items” policy ou “Work Item Query Policy”.

image

La “Work Items” policy oblige le développeur à définir au moyen un work item tandis que la “Work Item Query Policy” oblige le développeur à en choisir au moyen 1 dans une requète (généralement quelque chose dans le genre de “Mes tâches”). Dans les 2 cas il est toujours possible de corriger le changeset a posteriori en mettant à jour le commentaire via la fenètre d’historique et via un workitem de le lier au changeset.

Amélioration de la qualité du code

Il est aussi possible de valider l’analyse statique du code sur certaines règles (cela a l’effet de bord intéressant de vérifier que le code compile)  ou que certains tests passent (même si théoriquement cela a été validé avant). On peut voir ces politiques de “check in” comme des pense-bêtes pour les développeurs.

 

Et si on ne joue pas le jeu?

Si l’on suit les règles tout ce passe bien, mais que ce passe-t-il si on ne les respecte pas ? Dans la fenètre des fichiers en attente d’archivage, des erreurs apparaissent:

image

Il suffit de les corriger ensuite pour que tout rentre dans l’ordre. Mais quelque fois ce n’est pas possible de toujours respecter les règles (à part le commentaire de check-in bien sur!), et il n’est pas concevable d’empécher un développeur d’archiver du code. Par contre si cela est obligatoire, le changeset sera marqué comme violant les politiques de check-in.

Voila ce qu’il se passe au moment du check-in avec des règles en echec:

image

Et là pas le choix, il faut mettre un commentaire pour pouvoir archiver.

Conclusion

Ces règles sont d’une grande utilitée mais il ne faut pas en abuser. Quand il y en a une ça va, mais c’est quand il n’y en a plusieurs que cela pose des problèmes:

  • par exemple il faut toujours que le développeur ait  un workitem à ajouter et, dans certains cas, ce n’est pas lui qui les créent: même si il sait quoi faire, il faut qu’il puisse le signifier dans le code!
  • si la validation prend trop de temps: analyse statique trop longue ou tests trop longs, le développeur aura tendance à contourner les poliques de check-in.

Il faut donc trouver un compromis pour que tout le monde sorte gagnant!  Pour terminer je précise que je n’ai pas parlé ici de toutes les politiques de check-in que fournit Microsoft. Il y en a bien évidemment d’autres: ce sont de simples dll à créer en C# ou VB.Net mais il faut qu’elles soient déployées sur tous les postes.

 

@+

[FR] Un contrôleur de source, ce n’est pas un simple système de fichiers!

Cela peut sembler évident, mais tout le monde n’est pas sensibilisé à cela: toute opération sur une branche va se répercuter sur les branches parentes lors des merges. Il faut donc, lorsque l’on réalise une opération dans une branche, penser que cela aura des répercutions bien plus tard!

Il n’oublie jamais! Smile

Voici un exemple (vécu):

Gérard est un développeur de l’équipe, on lui a assigné un bug le #567 sur l’application App_X qui est dans la release R3 du soft. Jusque là: rien d’anormal. Gérard tire une branche de toute la release pour réaliser sa correction, y compris App_Y qui n’a rien à voir avec le bug.

image

Gérard ce dit que c’est idiot de voir pour la correction les 2 projets. On va alors croire que la correction est à la fois dans App_X et App_Y. Gérard décide alors de supprimer App_Y dans sa branche: simple “nettoyage”. Gérard choisit donc d’effectuer un “delete” sur App_Y:

image

Cela donne alors cet état:

image

Tout a l’air OK comme cela. Gérard corrige le bug et merge dans la release. Et là, c’est le drame:

image

Comme je le disais au début: TFS (comme toute contrôleur de source) n’oublie rien. Le delete n’était pas la solution (le “delete” n’est généralement pas la bonne décision!). Qu’aurait du faire Gérard?

Déjà Gérard aurait du avoir l’option suivante activée:

image

Il aurait alors vu que le dossier était marqué comme supprimé dans TFS. Cela lui aurait surement mis la puce à l’oreille:

image

Gérard avait en fait 2 options:

  • ne rien faire (des fois c’est la meilleur des options): pour une branche le plus important ce ne sont pas les fichiers que l’on a branché, mais ce qu’il y a dans l’historique.
  • demander une destruction du projet dans sa branche: contrairement au “delete” qui crée une opération pour supprimer des fichiers. La destruction de fichiers fait comme si les fichiers détruits n’avaient jamais existé, donc aucun historique!

Cela ce passe en ligne de commande:

image

Et donc au moment du “merge”: aucune opération d’effacement est crée:

image

Contrairement à un “delete”, le “destroy” est irréversible et est réservé que dans ces cas exceptionnels. De même un “delete” doit rester rare: supprimer un fichier revient à supprimer du code, donc supprimer de la valeur et surtout perdre l’historique. Cela est d’autant plus vrai pour un projet complet. Il est plus interessant de créer un dossier spécifique qui recevra l’ensemble des projets décommissionnés plutot que de les détruire et de marquer ce dossier en lecture seule.

Alors comment identifier ces changesets qui peuvent contenir ce genre d’opérations. Généralement je les retrouve avec les commentaires suivants: “cleaning”, “refactoring”…  et tout ce qui peut induire des changements dans la structure du code.

Bonne chasse!

 

End of line

[FR] Branches, bugs, et chef de projet! Ou comment faire voyager les changesets dans le contrôleur de source sans faire de “baseless merge”.

Voici la situation: Bob bosse sur un bug de la version R1 du soft, la correction est prète mais le chef de projet décide que ce bug ne sera pas corrigé dans la V1: la V2 est déjà sorti, et  il ne veux plus que des corrections de sécurité sur la V1. Par contre le bug existe dans la version en cours de développement, il faut donc corriger cette version.

 

Voici une image du contrôleur de source:

image

Si c’était possible, il faudrait faire un merge entre la branche R1-BUG_345 et la Main. Mais ce n’est possible qu’en mode baseless (Let me google that for you Smile ). Mais cette opération n’est pas forcément la plus simple car elle n’utilise pas les informations que TFS possède sur l’origine des fichiers: il est tout à fait possible qu’entre la R1 et la Main actuelle, les fichiers qu’il faut fusionner aient été renommés ou déplacés, et là, le baseless merge ne vas pas trop nous aider. Autre possibilité: utiliser le merge de TFS tout en compensant: nous allons effectuer 2 merges jusqu’à la main et ensuite faire en sorte d’annuler nos modifications dans R1 et surtout acter cette modification dans la Main. Pour cela nous allons utiliser la ligne de commande de TFS 2010 (la fonction était dans les powertools dans les versions précédèntes).

Dans Visual Studio j’effecture les opérations suivantes:

  • merge R1-BUG_345 –> R1: changeset 22
  • merge R1 –> Main du changeset 22 : changeset 23

Maintenant nous avons notre correction dans la main. Il ne reste plus qu’à la supprimer de la branche R1. Pour cela nous allons donc utiliser la commande “tf rollback”:

tf rollback /changeset:C22~C22 /recursive /keepmergehistory

image

Voici l’état des pending changes:

image

On remarque bien que l’état est “Rollback”! Regardons l’historique du fichier en question:

image

 

J’ai ajouté l’option /keekmergehistory pour indiquer à TFS que je ne veux plus que le changeset 22 soit appliqué si je remerge la branche R1-BUG_345 dans R1.

On pourrait penser que tout est bon maintenant, mais il manque une étape: si je merge la branche R1 dans la Main, le code va être annulé comme dans R1! Il y a maintenant 2 possibilités pour corriger cela:

  • Solution 1: faire le merge dans la main et refaire un rollback avec l’option /keepmergehistory: 2 opérations
  • Solution 2: faire croire que le merge de R1  vers Main est effectué via un /discard dans le merge: 1 opération.

Prenons la solution 2: tf merge /recursive /discard /version:C24 “$/MSF Agile Test/Release/R1” “$/MSF Agile Test/Main”

image

Historique devient comme suit:

image

Les commentaires sont importants pour bien comprendre ce qui s’est passé.

Nous avons donc réussi notre mission: Rien dans R1 et le bug corrigé dans la Main. Un conseil pour ces opérations: travailler si possible sur un seul changeset à la fois ou un groupe de changetset assez proche de la latest d’une branche: cela vous évitera les conflits pour la résolution du code.

J’ai utilisé l’option /keekmergehistory, mais sans cette option le rollback est très utile pour:

  • un développeur:  pour annuler un changeset un peut trop rapidement fait,
  • pour un gestionnaire de l’usine: pour annuler un changeset qui fait planter la build si le développeur ne peux pas corriger de suite: c’est un peu notre arme anti-plantage de build Smile.

@+