tableau de bord Build (Agile)

Vous pouvez utiliser le tableau de bord Build pour obtenir une vue d'ensemble des activités de développement qui affectent la qualité des builds. Les builds nocturnes sont importantes pour les projets de développement de logiciel. Lorsque les builds ne se terminent pas correctement ou ne réussissent pas les tests de vérification de build (BVT), l'équipe doit immédiatement résoudre le problème.

Autorisations requises

Pour afficher le tableau de bord, vous devez avoir été affecté ou appartenir à un groupe disposant des autorisations de Lecture dans produits SharePoint pour le projet d'équipe. Pour modifier, copier ou personnaliser un tableau de bord, vous devez être assigné ou appartenir à un groupe qui dispose des autorisations Membres dans produits SharePoint pour le projet d'équipe. Pour plus d'informations, consultez Ajouter des utilisateurs aux projets d'équipe.

Pour modifier un rapport Excel, vous devez être membre du rôle de sécurité TfsWarehouseDataReaders dans SQL Server Analysis Services, et vous devez avoir été affecté ou appartenir à un groupe auquel a été attribué le rôle Membres dans produits SharePoint pour le projet d'équipe. Pour plus d'informations, consultez Accorder l'accès aux bases de données de l'entrepôt de données pour Visual Studio ALM.

Pour afficher un élément de travail, vous devez être membre du groupe Readers ou disposer de l'autorisation Afficher les éléments de travail dans ce nœud avec la valeur Autoriser. Pour créer ou modifier un élément de travail, vous devez être membre du groupe Contributors ou disposer des autorisations Modifier les éléments de travail dans ce nœud avec la valeur Autoriser. Pour plus d'informations, consultez Gestion des autorisations.

Données affichées dans le tableau de bord.

L'équipe peut utiliser le tableau de bord Build pour surveiller la qualité des builds et déterminer si un membre de l'équipe doit prendre des mesures spécifiques pour corriger les échecs de build. Ce tableau de bord affiche les WebParts décrits dans l'illustration et le tableau suivants.

Composant WebPart	Données affichées	Rubrique connexe
	Graphique en courbes qui indique le pourcentage de code testé par les tests de vérification de build (BVT) et les autres tests au cours des quatre dernières semaines.	Couverture du code, rapport Excel
	Graphique en aires empilées qui indique le nombre de lignes de code que l'équipe a ajoutées, supprimées et modifiées dans les archivages précédant la build au cours des quatre dernières semaines.	Code Churn Excel Report (CMMI)
	Liste des builds récentes et leur état. Vous pouvez afficher davantage de détails en cliquant sur une build spécifique. Cette liste est dérivée d'un composant WebPart Team Web Access. Légende : : build en cours de génération : build non démarrée : build ayant réussi : build ayant échoué : build arrêtée : build partiellement réussie	Gérer et afficher des builds terminées
	Liste d'événements à venir découlant d'un composant WebPart SharePoint.	Non applicable
	Nombre d'éléments de travail actifs, résolus et fermés. Vous pouvez ouvrir la liste d'éléments de travail en cliquant sur chaque nombre. Cette liste est dérivée d'un composant WebPart Team Web Access.	Éléments de travail et workflow (Agile)
	Liste des archivages les plus récents. Vous pouvez afficher davantage de détails en cliquant sur un archivage spécifique. Cette liste est dérivée d'un composant WebPart Team Web Access.	Utilisation des fenêtres Archiver et Modifications en attente

Activités requises pour le suivi des builds

Pour que les rapports s'affichant dans le tableau de bord Build soient utiles et précis, l'équipe doit mettre en œuvre les activités suivantes :

• Configurer un système de génération. Pour utiliser Team Foundation Build, vous devez installer un système de génération.

  Pour plus d'informations, consultez Configurer votre système de génération.

• Créer des définitions de build. Vous pouvez créer plusieurs définitions de build, puis exécuter chacune d'elle afin de produire le code pour une plateforme différente. De plus, vous pouvez exécuter chaque build pour une configuration différente.

  Pour plus d'informations, consultez Définir votre processus de build.

• Définir des tests à exécuter automatiquement dans le cadre de la build : dans le cadre de la définition de build, vous pouvez définir des tests qui doivent s'exécuter avec la build, ou ne pas s'exécuter en cas d'échec de cette dernière.

  Pour plus d'informations, consultez Définir une build à l'aide du modèle par défaut.

• Configurer des tests pour rassembler les données de couverture du code : pour que les données de couverture du code s'affichent dans le rapport, les membres de l'équipe doivent instrumenter des tests pour rassembler ces données.

  Pour plus d'informations, consultez Comment : configurer la couverture du code à l'aide de paramètres de test pour les tests automatisés.

• Exécuter les builds régulièrement Vous pouvez exécuter les builds à des intervalles réguliers ou après chaque archivage. Vous pouvez créer des builds normales lorsque vous utilisez le déclencheur de planification.

  Pour plus d'informations, consultez Créer une définition de build de base et Exécuter et surveiller des builds.

  Notes

  Même si un membre de l'équipe peut évaluer manuellement une build à l'aide de l'Build Explorer, cette évaluation n'est pas reportée dans le rapport Indicateurs de qualité de build. L'évaluation de la build s'affiche dans le rapport Résumé de la build. Pour plus d'informations, consultez Évaluer la qualité d'une build terminée et Résumé de la build, rapport.

Surveillance des builds

L'équipe peut utiliser le tableau de bord Build pour surveiller la qualité des builds et le niveau de couverture du code. Dans l'idéal, la couverture du code est élevée et l'évolution du code est faible ou en baisse. En fonction de vos objectifs d'équipe, la couverture du code doit être comprise entre 80 % et 100 %.

Vous pouvez utiliser les rapports Couverture du code et Évolution du code pour répondre aux questions répertoriées dans le tableau suivant.

• Quelles sont les builds ayant réussi ?

• Quelles sont les builds contenant un nombre important de modifications du code ?

• Quelle est la fréquence de réussite des builds ?

• Quelle est la volatilité de la base de code ?

• Quel volume de code l'équipe est-elle en train de tester ?

• Quelle est la qualité des builds ?

• La qualité est-elle en augmentation, en baisse ou constante ?

Pour plus d'informations, consultez Couverture du code, rapport Excel et Évolution du code, rapport Excel.

Personnalisation du tableau de bord Build

Vous pouvez personnaliser le tableau de bord Build de différentes façons :

• Modifiez les filtres de chaque rapport dans Office Excel pour vous concentrer sur des zones de produit ou des itérations spécifiques.

• Ajoutez des rapports Excel existants, tels que État de la build ou Progression des bogues, au tableau de bord.

Pour plus d'informations sur l'utilisation et la personnalisation des rapports Excel, consultez les pages suivantes sur le site Web Microsoft :

• Méthodes de personnalisation des rapports de tableau croisé dynamique

• Modifier ou supprimer un classeur d'Excel Services

• Publier un classeur dans Excel Services

• Enregistrer un fichier dans une bibliothèque SharePoint ou un autre emplacement Web

Voir aussi

Concepts

Scrum

Tableaux de bord (Agile)

Artefacts (Agile)

Autres ressources

Rapports (Agile)