Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

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.

 

@+

 

Michel

Publié lundi 7 mars 2011 09:00 par Miiitch
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

# re: Le “Check In” sans règles: Highway to #fail!

"Quand il y en a une ça va, mais c’est quand il n’y en a plusieurs que cela pose des problèmes"  lol :)

Sympa cette série d'article autour de TFS. Je dois justement en mettre un en place ! [Bon ça traine un peu vu que ce n'est pas ma priorité]

lundi 7 mars 2011 09:36 by Troborg

# re: Le “Check In” sans règles: Highway to #fail!

tu va avoir des problèmes toi; tu va avoir de GROS problèmes!!!

lundi 7 mars 2011 11:56 by fathi

# re: Le “Check In” sans règles: Highway to #fail!

Ouch, le vieux article que tu pointes sur MSDN :)

lundi 7 mars 2011 17:04 by azra

# re: Le “Check In” sans règles: Highway to #fail!

Oui ça date, à l'époque tu codais ;)

lundi 7 mars 2011 17:15 by Miiitch
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- SharePoint : Bug sur la gestion des permissions et la synchronisation Office par Blog Technique de Romelard Fabrice le 07-10-2014, 11:35

- SharePoint 2007 : La gestion des permissions pour les Workflows par Blog Technique de Romelard Fabrice le 07-08-2014, 11:27

- TypeMock: mock everything! par Fathi Bellahcene le 07-07-2014, 17:06

- Coding is like Read par Aurélien GALTIER le 07-01-2014, 15:30

- Mes vidéos autour des nouveautés VS 2013 par Fathi Bellahcene le 06-30-2014, 20:52

- Recherche un passionné .NET par Tkfé le 06-16-2014, 12:22

- [CodePlex] Projet KISS Workflow Foundation lancé par Blog de Jérémy Jeanson le 06-08-2014, 22:25

- Etes-vous yOS compatible ? (3/3) : la feuille de route par Le blog de Patrick [MVP SharePoint] le 06-06-2014, 00:30

- [MSDN] Utiliser l'approche Contract First avec Workflow Foundation 4.5 par Blog de Jérémy Jeanson le 06-05-2014, 21:19

- [ #ESPC14 ] TH10 Moving mountains with SharePoint ! par Le blog de Patrick [MVP SharePoint] le 06-01-2014, 11:30