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

- Compte rendu : SharePoint / O365 : des pratiques pour une meilleure productivité par The Mit's Blog le 12-12-2014, 18:11

- [TFS] Suppression des feature SQL Entreprise en masse par Blog de Jérémy Jeanson le 12-06-2014, 09:18

- [Clean Code] règles de nommage par Fathi Bellahcene le 12-04-2014, 22:59

- Windows To Go 10 et Upgrades impossibles par Blog de Jérémy Jeanson le 12-04-2014, 21:38

- SharePoint OnPremise: Statistiques d’utilisation pour traquer les sites fantomes par Blog Technique de Romelard Fabrice le 12-03-2014, 10:28

- SharePoint 2007: Script PowerShell permettant le backup de toutes les collections de sites d’une application Web par Blog Technique de Romelard Fabrice le 12-02-2014, 10:00

- Xamarin : un choix précieux par .net is good... C# is better ;) le 12-01-2014, 15:10

- Office 365: Comparaison des composants pour préparer votre migration de SharePoint 2007 vers Office 365 par Blog Technique de Romelard Fabrice le 11-28-2014, 16:20

- Créer un périphérique Windows To Go 10 ! par Blog de Jérémy Jeanson le 11-21-2014, 04:54

- RDV à Genève le 12 décembre pour l’évènement “SharePoint–Office 365 : des pratiques pour une meilleure productivité !” par Le blog de Patrick [MVP Office 365] le 11-19-2014, 10:40