Michel Perfetti [Miiitch]

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:

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:

Regardons maintenant la build qui a échouée:

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:

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

Et on tombe sur l’erreur:

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.

@+