Behörigheter och krav för åtkomst till Analys i Azure DevOps

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

För att kunna arbeta med Analys och skapa rapporter måste flera krav uppfyllas enligt sammanfattningen i den här artikeln.

Som standard får alla projektmedlemmar åtkomst till Analysdata för de projekt som de är medlemmar i, inklusive medlemmar som läggs till i gruppen Läsare för projektet. Användare med intressentåtkomst har inte åtkomst till att visa eller redigera Analytics-vyer.

Tjänst- och funktionsaktivering

I allmänhet är Analytics alltid aktiverat och tillgängligt för medlemmar i en organisation eller samling för att visa data och skapa rapporter.

Analystjänst

För Azure DevOps Services är Analytics alltid aktiverat. Du kan inte inaktivera den eller pausa den.

Azure DevOps-tjänster

Om du vill använda en Azure DevOps-tjänst måste den vara aktiverad. Inga data kan samlas in för en tjänst som har inaktiverats. Tjänster kan aktiveras eller inaktiveras på projektbasis.

Information om hur du kontrollerar att alla tjänster är aktiverade finns i Aktivera eller inaktivera en tjänst.

Analysvyer

Analysvyer, en hubb i webbportalen, är ett förenklat sätt att ange filtervillkoren för en Power BI-rapport baserat på Analysdata. Mer information finns i Vad är analystjänsten?

Om du vill komma åt Analytics-vyer måste du ha det aktiverat. Organisationsägaren eller medlemmen i gruppen Projektsamlingsadministratörer kan aktivera den för alla i organisationen. Eller så kan varje projektmedlem aktivera det själva.

Mer information finns i Hantera eller aktivera funktioner.

Behörigheter

Du anger behörigheter för tjänsten på projektnivå och för delade analysvyer på objektnivå.

I följande tabell sammanfattas de behörigheter som är tillgängliga för att ställas in och standardtilldelningarna för projektsäkerhetsgrupperna.

Behörighet	Läsare	Deltagare	Projektadministratörer
Visa analys	✔️	✔️	✔️
Visa en delad analysvy		✔️	✔️
Lägga till en privat eller delad analysvy		✔️	✔️
Redigera och ta bort delade Analytics-vyer			✔️

Krav för dataspårning

Programvaruteamen måste utföra meningsfulla åtgärder för att samla in meningsfulla data. Följande avsnitt innehåller allmänna rekommendationer baserat på vilken typ av data du vill rapportera om.

Anteckning

Entitetsuppsättningar för gren, pipeline och test stöds med Analytics v3.0-förhandsversioner och senare versioner. Entitetsuppsättningar för ögonblicksbilder för att stödja pipelinejobb, begäranden från uppgiftsagenten och storleken på aktivitetsagentpoolen har lagts till med analytics v4.0-förhandsversionen . Se till att du anger den Analytics-version som stöder entitetsuppsättningen av intresse.

Utforska Analytics-metadata för motsvarande entitetstyp för att förstå vilka egenskaper och uppräknade listvärden du kan filtrera eller gruppera data efter.

Azure Boards och arbetsspårning

En granskning av tillgängliga entitetsuppsättningar som du kan köra frågor mot finns i Metadatareferens för Azure Boards Analytics.

För att rapportera om arbetsspårning måste teamen utföra flera uppgifter för att säkerställa att meningsfulla data är tillgängliga. Granska följande uppgifter innan du definierar dina Analytics-frågor och -rapporter.

• Om du vill rapportera om aktiva buggar eller buggtrender definierar du buggar och uppdaterar buggtillståndet när det är åtgärdat, verifierat och sedan stängt.
• Om du vill rapportera om kvarvarande arbetsuppgifter eller andra typer av arbetsobjekt måste du definiera dessa arbetsobjekt och uppdatera deras tillstånd när de flyttas från ny till stängd. Överväg vilka fält eller taggar du ska använda för att filtrera eller gruppera data i en rapport och se till att de är väldefinierade och konsekventa.
• Om du vill ha stöd för sammanslagningsrapporter kontrollerar du att det finns överordnade-underordnade länkar mellan produktuppgifter och uppgifter/buggar, eller att det finns länkar mellan funktioner eller arbetsobjekt för portföljeftersläpning och deras underordnade objekt. Mer information finns i Organisera kvarvarande uppgifter och mappa underordnade arbetsobjekt till föräldrar.
• Om du vill skapa burndown- eller burnup-rapporter, till exempel Sprint burndown eller Release burndown, kontrollerar du att du har tänkt igenom hur du vill filtrera och gruppera data i rapporten. Burndown/burnup-rapporter refererar till entitetsuppsättningen WorkItemsSnapshot . Entitetsuppsättningar för ögonblicksbilder modelleras som dagliga ögonblicksbilder. Data aggregeras baserat på tilldelningar som görs från och med det datum då de tilldelas. Det innebär att för att filtrera en burndown/burnup-rapport baserat på fält- eller taggtilldelningar måste du tilldela fälten eller taggarna före den period som du vill rapportera om. Annars registreras inte fälten/taggarna av rapporten förrän det datum då de tillämpas.
• För att stödja kravspårning definierar du testfall och skapar en testad av-länk från varje testfall till en användarberättelse, artikel med kvarvarande uppgifter eller krav. Definiera testfall och länka testfall till deras överordnade PBI:er med hjälp av länken Testad av. Se Skapa dina tester.
• (Rekommenderas) Om du vill ha stöd för filtrering och gruppering i en rapport tilldelar du Områdessökväg och Iterationssökväg till alla arbetsobjekt. Information om hur du definierar iteration och områdessökvägar finns i Definiera områdessökvägar och tilldela till ett team eller Definiera iterationssökvägar (sprintar) och konfigurera teamiterationer.

Anteckning

Alla anpassade fält som läggs till i en arbetsobjektstyp är tillgängliga för användning i rapporter. Anpassade fält är märkta med Custom_DisplayNameOfField, där alla blanksteg har tagits bort från visningsnamnet.

Testplaner

För att granska testplanens förlopp och beredskapen för testfall måste teamen utföra följande aktiviteter.

• Definiera testfall, testplaner och testpaket och ange deras aktuella tillstånd. Mer information finns i Skapa testplaner och testpaket och Skapa testfall.
• Uppdatera tillståndet för testobjekt när de går från Design till Klar till Stängd.
• För manuella tester markerar du resultatet av varje valideringssteg i testfallet som godkänt eller misslyckat.

  Tips

  Testare måste markera ett teststeg med en status om det är ett verifieringsteststeg. Det övergripande resultatet för ett test återspeglar statusen för alla teststeg som har markerats. Därför har testet statusen Failed (Misslyckades) om något teststeg har markerats som misslyckat eller inte markerat.

• För automatiserade tester markeras varje test automatiskt som godkänt eller misslyckat.
• (Rekommenderas) Om du vill ha stöd för filtrering och gruppering i en rapport tilldelar du Områdessökväg och Iterationssökväg till testfall, testpaket och testplaner.

Pipelines

För att kunna rapportera om pipelines måste teamen definiera pipelines med YAML och köra pipelines regelbundet. Mer information finns i Viktiga begrepp för nya Azure Pipelines-användare.

Tänk också på följande åtgärder:

• Överväg vilka data du vill rapportera om och välj rätt entitetsuppsättning. En granskning av tillgängliga entitetsuppsättningar för frågor finns i Metadatareferens för Azure Pipelines Analytics.
• Överväg vilka pipelines du vill rapportera om och datumintervallet för rapporten. Du vill filtrera dina data så att de uppfyller bästa praxis för frågor och minimerar eventuella prestandaproblem.

Pipelines och test

Om du vill rapportera om pipelines och testresultat kontrollerar du att du lägger till testuppgifter i pipelinedefinitionen. Mer information finns i Skapa och släppa uppgifter–Testa.

Om du precis har börjat kan du granska den här Learn-modulen , Köra kvalitetstester i din byggpipeline med hjälp av Azure Pipelines.

Relaterade artiklar

• Vad är Analytics-tjänsten?
• Snabbreferens för standardbehörigheter i Azure DevOps
• Metodtips att använda när du frågar Analytics-tjänsten