Autorisations et conditions préalables pour accéder à Analytics dans Azure DevOps
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Pour utiliser Analytics et créer des rapports, plusieurs prérequis doivent être remplis comme résumé dans cet article.
Par défaut, tous les membres du projet ont accès aux données Analytics 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 activé et disponible pour les membres d’une organisation ou d’une collection pour afficher les données et créer un rapport.
Service d’analyse
Pour Azure DevOps Services, Analytics est toujours activé. Vous ne pouvez pas le désactiver ou le suspendre.
Pour Azure DevOps Server 2020 et versions ultérieures locales, 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. Lorsqu’elles sont suspendues, 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 n’importe quel 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 Analytics
Les vues d’analyse, un hub dans votre portail web, offrent un moyen simplifié de spécifier les critères de filtre d’un rapport Power BI basé sur les données Analytics. Pour plus d’informations, consultez la section Qu’est-ce que le service d’analyse ?
Pour accéder aux vues Analytics, vous devez l’activer. Le propriétaire d’organisation ou membre du groupe Administrateurs de regroupement de projets peut l’activer pour tous les membres de l’organisation. Ou bien, chaque membre de 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 d’analyse partagée au niveau de l’objet.
Le tableau suivant récapitule les autorisations disponibles pour être définies et les affectations par défaut apportées aux groupes de sécurité de projet.
| Autorisation | Lecteurs | Contributeurs | Project Administrators |
|---|---|---|---|
| View Analytics | ✔️ | ✔️ | ✔️ |
| Afficher une vue Analytique partagée | ✔️ | ✔️ | |
| Ajouter une vue Analytique privée ou partagée | ✔️ | ✔️ | |
| Modifier et supprimer des vues d’analyse partagée | ✔️ |
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 basées sur le type de données à signaler.
Remarque
Les ensembles d’entités Branch, Pipeline et Test sont pris en charge avec Analytics v3.0-preview et versions ultérieures. Des jeux d’entités d’instantanés pour prendre en charge les travaux de pipeline, les demandes de l’agent de tâches et la taille du pool d’agents de tâches ont été ajoutés avec la version Analytics v4.0-preview . Veillez à spécifier la version Analytics qui prend en charge l’ensemble d’entités d’intérêt.
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 consulter les ensembles d’entités disponibles que vous pouvez interroger, consultez la référence des métadonnées pour Azure Boards Analytics.
Pour signaler le suivi des travaux, 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 des bogues et mettez à jour l’état du bogue tel qu’il est résolu, vérifié, puis fermé.
- Pour signaler le travail du 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 balises 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, vérifiez que les liens parent-enfant existent entre les éléments de backlog de produit et les tâches/bogues, ou que les 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 burndown ou burnup, tels que Sprint burndown ou Release burndown, vérifiez que vous avez réfléchi à la façon dont vous souhaitez filtrer et regrouper des données dans votre rapport. Les rapports Burndown/burnup référencent l’ensemble d’entités
WorkItemsSnapshot. Les jeux d’entités d’instantanés sont modélisés en tant qu’instantanés quotidiens. Les données sont agrégées en fonction des affectations effectuées à compter de la date à laquelle elles sont affectées. Cela signifie que pour filtrer un rapport 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 signaler. Dans le cas contraire, les champs/balises ne sont pas enregistrés par le rapport tant que la date à laquelle elles sont appliquées. - Pour prendre en charge le suivi des exigences, définissez des cas de test et créez un lien Tested By de chaque cas de test vers un article utilisateur, un élément de backlog de produit ou une exigence. Définissez les cas de test et liez des cas de test à leurs PBIs parents à l’aide du lien Testé par lien. 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 au 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 affecter à une équipe ou Définir des chemins d’itération (sprints) et configurer des itérations d’équipe.
Remarque
Tous les champs personnalisés ajoutés à un type d’élément de travail sont disponibles pour une utilisation dans les rapports. Les champs personnalisés sont étiquetés avec Custom_DisplayNameOfField, où tous les espaces ont été supprimés du nom complet.
Plans de test
Pour examiner la progression du plan de test et la préparation des cas de test, les équipes doivent effectuer les activités suivantes.
- Définissez les cas de test, les plans de test et les 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 La conception à Prêt à fermer.
- Pour les tests manuels, marquez 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 avec un état s’il s’agit d’une étape de test de validation. Le résultat global d’un test reflète l’état de toutes les étapes de test marquées. Par conséquent, le test aura un état d’échec si une étape de test est marquée comme ayant échoué ou non 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 au chemin d’itération aux cas de test, aux suites de tests et aux plans de test.
Pipelines
Pour créer des rapports sur des pipelines, les équipes doivent définir des pipelines à l’aide de YAML et exécuter régulièrement des pipelines. Pour plus d’informations, consultez Les concepts clés pour les nouveaux utilisateurs d’Azure Pipelines.
En outre, tenez compte des actions suivantes :
- Tenez compte des données sur lesquelles vous souhaitez créer un rapport et choisissez l’ensemble d’entités approprié. Pour consulter les ensembles d’entités disponibles à interroger, consultez la référence des métadonnées pour Azure Pipelines Analytics.
- Considérez les pipelines sur lesquels vous souhaitez signaler et 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 tests
Pour signaler les résultats des pipelines et des tests, veillez à ajouter des tâches de test à la définition du pipeline. Pour plus d’informations, consultez Build and release tasks-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.