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

- L’application des MiniDrones Parrot est aussi disponible pour Windows 8.1 par Blog de Jérémy Jeanson le 10-28-2014, 15:01

- L’application des MiniDrones Parrot est enfin disponible pour Windows Phone par Blog de Jérémy Jeanson le 10-27-2014, 09:49

- Mise à jour Samsung 840 EVO sur core server par Blog de Jérémy Jeanson le 10-27-2014, 05:59

- MVP Award 2014 ;) par Blog de Jérémy Jeanson le 10-27-2014, 05:42

- « Naviguer vers le haut » dans une librairie SharePoint par Blog de Jérémy Jeanson le 10-07-2014, 13:21

- PowerShell: Comment mixer NAGIOS et PowerShell pour le monitoring applicatif par Blog Technique de Romelard Fabrice le 10-07-2014, 11:43

- ReBUILD 2014 : les présentations par Le blog de Patrick [MVP Office 365] le 10-06-2014, 09:15

- II6 Management Compatibility présente dans Windows Server Technical Preview avec IIS8 par Blog de Jérémy Jeanson le 10-05-2014, 17:37

- Soft Restart sur Windows Server Technical Preview par Blog de Jérémy Jeanson le 10-03-2014, 19:43

- Non, le certificat public du CA n’est pas un certificat client !!! par Blog de Jérémy Jeanson le 10-03-2014, 00:08