Share via

Autorisations et prérequis pour accéder à Analytics dans Azure DevOps

  • Article

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Pour utiliser Analytics et créer des rapports, plusieurs conditions préalables doivent être remplies, comme indiqué dans cet article.

Par défaut, tous les membres du projet ont accès aux données d’analyse pour les projets dont ils sont membres, y compris les membres ajoutés au groupe Lecteurs du projet. Les utilisateurs disposant d’un accès aux parties prenantes n’ont pas accès à l’affichage ou à la modification des vues Analytics.

Activation du service et des fonctionnalités

En général, Analytics est toujours actif et disponible pour les membres d’un organization ou d’une collection pour afficher les données et créer un rapport.

Service d’analyse

Par Azure DevOps Services, Analytics est toujours actif. Vous ne pouvez pas le désactiver ou le suspendre.

Pour Azure DevOps Server versions locales 2020 et ultérieures, Analytics est automatiquement installé avec chaque collection de projets que vous créez.

Pour Azure DevOps Server 2019, vous devez d’abord installer Analytics sur chaque collection de projets que vous créez.

Vous pouvez suspendre et redémarrer le service. En cas de pause, aucune nouvelle donnée n’est ajoutée à Analytics.

Pour plus d’informations, consultez Installer ou activer le service Analytics.

Azure DevOps Services

Pour exercer un service Azure DevOps, il doit être activé. Aucune donnée ne peut être capturée pour un service qui a été désactivé. Les services peuvent être activés ou désactivés sur un projet par projet.

Pour vérifier que tous les services sont activés, consultez Activer ou désactiver un service.

Vues d’analyse

Les vues d’analyse, un hub dans votre portail web, permettent de spécifier les critères de filtre d’un rapport Power BI en fonction des données Analytics. Pour plus d’informations, consultez Qu’est-ce que le service Analytics ?

Pour accéder aux vues Analytics, vous devez les activer. Le propriétaire d'organisation ou le membre du groupe Administrateurs de collection de projets peut l’activer pour tous les membres du organization. Ou, chaque membre du projet peut l’activer pour lui-même.

Pour savoir comment procéder, consultez Gérer ou activer des fonctionnalités.

Autorisations

Vous définissez des autorisations pour le service au niveau du projet et pour les vues Analytics partagées au niveau de l’objet.

Le tableau suivant récapitule les autorisations disponibles à définir et les affectations par défaut effectuées aux groupes de sécurité du projet.

Autorisation Lecteurs Contributeurs Project Administrators
Afficher l’analytique ✔️ ✔️ ✔️
Afficher une vue Analytique partagée ✔️ ✔️
Ajouter une vue Analytique privée ou partagée ✔️ ✔️
Modifier et supprimer des vues Analytics partagées ✔️

Prérequis pour le suivi des données

Pour capturer des données significatives, les équipes logicielles doivent effectuer des actions significatives. Les sections suivantes fournissent des recommandations générales en fonction du type de données sur lequel vous souhaitez créer des rapports.

Notes

Les ensembles d’entités Branch, Pipeline et Test sont pris en charge avec Analytics v3.0-preview et versions ultérieures. Les jeux d’entités d’instantanés pour prendre en charge les travaux de pipeline, les demandes d’agent de tâche et la taille du pool d’agents de tâches ont été ajoutés avec la version d’analytics v4.0-preview . Veillez à spécifier la version Analytics qui prend en charge l’ensemble d’entités qui vous intéresse.

Pour comprendre les propriétés et les valeurs de liste énumérées par lesquelles vous pouvez filtrer ou regrouper des données, explorez les métadonnées Analytics pour le type d’entité correspondant.

Azure Boards et suivi du travail

Pour passer en revue les jeux d’entités disponibles que vous pouvez interroger, consultez Informations de référence sur les métadonnées pour Azure Boards Analytics.

Pour créer des rapports sur le suivi du travail, les équipes doivent effectuer plusieurs tâches pour s’assurer que des données significatives sont disponibles. Passez en revue les tâches suivantes avant de définir vos requêtes et rapports Analytics.

  • Pour signaler les bogues actifs ou les tendances des bogues, définissez les bogues et mettez à jour l’état du bogue à mesure qu’il est corrigé, vérifié, puis fermé.
  • Pour créer des rapports sur le travail en backlog ou d’autres types d’éléments de travail, veillez à définir ces éléments de travail et à mettre à jour leur état à mesure qu’il passe de nouveau à fermé. Tenez compte des champs ou des étiquettes que vous utiliserez pour filtrer ou regrouper des données dans un rapport, et assurez-vous qu’elles sont bien définies et cohérentes.
  • Pour prendre en charge les rapports cumulatifs, assurez-vous qu’il existe des liens parent-enfant entre les éléments du backlog de produit et les tâches/bogues, ou que des liens parent-enfant existent entre les fonctionnalités ou les éléments de travail du backlog de portefeuille et leurs éléments enfants. Pour plus d’informations, consultez Organiser votre backlog et mapper les éléments de travail enfants aux parents.
  • Pour créer des rapports de burndown ou burnup, tels que Sprint burndown ou Release burndown, assurez-vous d’avoir réfléchi à la façon dont vous souhaitez filtrer et regrouper les données dans votre rapport. Les rapports burndown/burnup référencent le jeu d’entités WorkItemsSnapshot . Les jeux d’entités d’instantané sont modélisés comme des instantanés quotidiens. Les données sont agrégées en fonction des affectations effectuées à la date à laquelle elles sont affectées. Cela signifie que pour filtrer un rapport de burndown/burnup en fonction des affectations de champs ou d’étiquettes, vous devez affecter les champs ou balises avant la période sur laquelle vous souhaitez créer un rapport. Sinon, les champs/balises ne sont pas enregistrés par le rapport avant la date à laquelle ils sont appliqués.
  • Pour prendre en charge le suivi des exigences, définissez des cas de test et créez un lien Tested By à partir de chaque cas de test vers un récit utilisateur, un élément de backlog de produit ou une exigence. Définir des cas de test et lier les cas de test à leurs éléments de journal des travaux en souffrance du produit parents en utilisant le lien Testé par. Consultez Créer vos tests.
  • (Recommandé) Pour prendre en charge le filtrage et le regroupement dans un rapport, affectez le chemin d’accès à la zone et le chemin d’itération à tous les éléments de travail. Pour plus d’informations sur la définition des chemins d’itération et de zone, consultez Définir des chemins d’accès de zone et attribuer à une équipe ou Définir des chemins d’itération (sprints) et configurer des itérations d’équipe.

Notes

Tous les champs personnalisés ajoutés à un type d’élément de travail peuvent être utilisés dans les rapports. Les champs personnalisés sont étiquetés avec Custom_DisplayNameOfField, où tous les espaces ont été supprimés du nom d’affichage.

Plans de test

Pour passer en revue la progression du plan de test et la préparation des cas de test, les équipes doivent effectuer les activités suivantes.

  • Définissez des cas de test, des plans de test et des suites de tests, et spécifiez leur état actuel. Pour plus d’informations, consultez Créer des plans de test et des suites de tests et Créer des cas de test.
  • Mettez à jour l’état des objets de test au fur et à mesure qu’ils passent de Conception à Prêt à Fermé.
  • Pour les tests manuels, marquer les résultats de chaque étape de validation dans le cas de test comme ayant réussi ou échoué.

    Conseil

    Les testeurs doivent marquer une étape de test en précisant un état s’il s’agit d’une étape d’un test de validation. Le résultat général d'un test reflète l'état de toutes les étapes de test ayant été marquées. Par conséquent, le test sera considéré comme ayant échoué si l'une des étapes du test est marquée comme ayant échoué ou n'est pas marquée.

  • Pour les tests automatisés, chaque test est automatiquement marqué comme ayant réussi ou échoué.
  • (Recommandé) Pour prendre en charge le filtrage et le regroupement dans un rapport, affectez le chemin d’accès à la zone et le chemin d’itération aux cas de test, aux suites de tests et aux plans de test.

Pipelines

Pour créer des rapports sur les pipelines, les équipes doivent définir des pipelines à l’aide de YAML et exécuter des pipelines régulièrement. Pour en savoir plus, consultez Concepts clés pour les nouveaux utilisateurs d’Azure Pipelines.

En outre, envisagez les actions suivantes :

  • Réfléchissez aux données sur lesquelles vous souhaitez créer des rapports et choisissez le jeu d’entités approprié. Pour passer en revue les jeux d’entités disponibles à interroger, consultez Informations de référence sur les métadonnées pour Azure Pipelines Analytics.
  • Tenez compte des pipelines sur lesquels vous souhaitez signaler et de la plage de dates de votre rapport. Vous souhaiterez filtrer vos données afin de respecter les meilleures pratiques de requête et de réduire les problèmes de performances.

Pipelines et test

Pour générer des rapports sur les pipelines et les résultats des tests, veillez à ajouter des tâches de test à la définition du pipeline. Pour plus d’informations, consultez Tâches de génération et de mise en production -Test.

Si vous venez de commencer, envisagez de passer en revue ce module Learn, Exécuter des tests de qualité dans votre pipeline de build à l’aide d’Azure Pipelines.