Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

J’ai installé TFS 2010, et après ? Horreur malheur! ma build a planté!

Ce qui devait arriver arriva. La build a échouée à la compilation. Que fait-on maintenant? L’erreur serait d’ouvrir la solution qui est compilé par la build sans regarder d’où vient le problème. Erreur car:

  • La version que l’on a sur son poste marche peut-être: c’est surement pas la même version que la build
  • Il y plus rapide pour trouver l’erreur que de récupérer le code du label de la build (même si au final il faudra y venir)

 

Une build qui marche, cela ressemble à cela:

image

La partie la plus intéressente lorsque l’on suit une build est la liste des changesets associés. Pour chaque build, TFS pose un label sur le code. Ce label sert à récupérer le code si tout va bien pour définir une version à livrer et tirer une branche, et si tout va mal pour corriger la build. TFS garde pour chaque définition de  build le label de la dernière build réussie. A partir de ce label, on en déduit les changesets et donc on sait ce qui a changé depuis la dernière build réussie:

image

Regardons maintenant la build qui a échouée:

image

Ici c’est assez clair, mais souvent il faut creuser un peu pour trouver le problème. Et généralement on commence à creuser en regardant les changesets associés, car si la build a planté et que celle d’avant marchait, c’est forcément là que l’on va trouver le problème, et surtout si la correction est complexe, la personne qui va corriger tout cela (et oui corriger la build c’est l’affaire de tous!)

Lorsque l’on clique sur le nom du changeset, on arrive sur son détail:

image

Ensuite il suffit de comparer avec la version précédente:

image

Et on tombe sur l’erreur:

image

Cet exemple est un peu caricatural sur plusieurs points:

  • Il n’y a généralement pas qu’une erreur, mais un généralement un grand nombre d’erreurs “leurres” qui découlent d’une ou plusieurs erreurs: un using de namespace manques et dont le code compile plus mais l’erreur c’est que le “using” a disparu et cela aucun compilateur vous le dira.
  • Il y a souvent beaucoup de changesets: il faut alors les parcourir, mais si les développeurs ont l’habitude de mettre des commentaires sur les changesets et cela aide beaucoup.

Dans tous les cas, la build est le meilleur allié pour voir comment évolue le logiciel et identifier les problèmes. La build est capable de plein d’autres choses, mais ça c’est pour un autre billet.

 

@+

Publié lundi 31 janvier 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

Pas de commentaires
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- SharePoint 2013: Préparation de la migration - Création des site Templates dans 2010 et 2013 par Blog Technique de Romelard Fabrice le il y a 23 heures et 19 minutes

- [ #Yammer ] How to change interface language ? Comment changer la langue de l’interface ? par Le blog de Patrick [MVP SharePoint] le 08-20-2014, 14:21

- Onedrive Sync Engine Host : CPU à 100% par Le petit blog de Pierre / Pierre's little blog le 08-06-2014, 22:22

- 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