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

- « 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

- Windows Server Technical Preview disponible via MSDN par Blog de Jérémy Jeanson le 10-02-2014, 19:05

- Focus Sauvegardes SharePoint par Le blog de Patrick [MVP Office 365] le 10-02-2014, 13:11

- Technofolies, votre évènement numérique de l'année par Le Blog (Vert) d'Arnaud JUND le 09-26-2014, 18:40

- Xamarin : From Zero to Hero par Fathi Bellahcene le 09-24-2014, 17:35