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:
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”.
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:
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:
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
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 :
