Oprávnění a požadavky pro přístup k Analýzám v Azure DevOps

  • Článek

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

Abyste mohli pracovat s Analýzami a vytvářet sestavy, musí být splněno několik požadavků, jak je shrnuto v tomto článku.

Ve výchozím nastavení mají všichni členové projektu přístup k analytickým datům pro projekty, které jsou členy, včetně členů přidaných do skupiny Čtenáři projektu. Uživatelé s přístupem účastníka nemají přístup k zobrazení nebo úpravám zobrazení analýzy.

Povolení služeb a funkcí

Obecně platí, že analýza je vždy zapnutá a dostupná členům organizace nebo kolekce, aby mohli zobrazit data a vytvořit sestavu.

Analytická služba

Pro Azure DevOps Services je služba Analytics vždy zapnutá. Nemůžete ho zakázat ani pozastavit.

V Azure DevOps Server 2020 a novějších místních verzích se služba Analytics automaticky nainstaluje s každou kolekcí projektů, kterou vytvoříte.

Pro Azure DevOps Server 2019 musíte nejprve nainstalovat Analýzu na každou kolekci projektů, kterou vytvoříte.

Službu můžete pozastavit a restartovat. Po pozastavení se do Analytics nepřidají žádná nová data.

Další informace najdete v tématu Instalace nebo povolení služby Analytics.

Služby Azure DevOps

Pokud chcete službu Azure DevOps používat, musí být povolená. Pro službu, která je zakázaná, se nedají zachytit žádná data. Služby je možné povolit nebo zakázat v projektu podle projektu.

Pokud chcete ověřit, jestli jsou povolené všechny služby, přečtěte si téma Zapnutí nebo vypnutí služby.

Analytická zobrazení

Analytická zobrazení, což je centrum na webovém portálu, poskytuje zjednodušený způsob, jak zadat kritéria filtru pro sestavu Power BI na základě dat Analýzy. Další informace najdete v tématu Co je analytická služba?

Pokud chcete získat přístup k zobrazením Analytics, musíte je mít povolenou. Vlastník organizace nebo člen skupiny Správci kolekcí projektů ho může povolit pro všechny uživatele v organizaci. Nebo si ho může povolit každý člen projektu sám.

Postup najdete v tématu Správa nebo povolení funkcí.

Oprávnění

Oprávnění pro službu nastavíte na úrovni projektu a pro sdílená analytická zobrazení na úrovni objektu.

Následující tabulka shrnuje dostupná oprávnění a výchozí přiřazení ke skupinám zabezpečení projektu.

Oprávnění Čtenáři Přispěvatelé Správci projektu
Zobrazit analýzy ✔️ ✔️ ✔️
Zobrazení sdíleného zobrazení analýzy ✔️ ✔️
Přidání soukromého nebo sdíleného zobrazení analýzy ✔️ ✔️
Úprava a odstranění sdílených analytických zobrazení ✔️

Požadavky na sledování dat

Aby softwarové týmy zachytály smysluplná data, musí provádět smysluplné akce. Následující části poskytují obecná doporučení na základě typu dat, která chcete hlásit.

Poznámka

Sady entit větví, kanálů a testovacích entit se podporují ve verzi Analytics verze 3.0 preview a novějších verzích. Sady entit snímků pro podporu úloh kanálu, požadavků agenta úloh a velikosti fondu agentů úloh byly přidány ve verzi Analytics v4.0-preview . Ujistěte se, že jste zadali verzi Analytics, která podporuje sadu zajímavých entit.

Pokud chcete zjistit, podle jakých vlastností a hodnot výčtu seznamů můžete data filtrovat nebo seskupovat, prozkoumejte metadata Analytics pro odpovídající typ entity.

Azure Boards a sledování práce

Přehled dostupných sad entit, na které se můžete dotazovat, najdete v tématu Referenční informace k metadatám pro Azure Boards Analytics.

Aby týmy ohlásily sledování práce, musí provést několik úkolů, aby zajistily, že jsou k dispozici smysluplná data. Před definováním analytických dotazů a sestav si projděte následující úlohy.

  • Pokud chcete hlásit aktivní chyby nebo trendy chyb, definujte chyby a aktualizujte stav chyby, protože se opraví, ověří a pak zavře.
  • Pokud chcete hlásit práci v backlogu nebo jiné typy pracovních položek, nezapomeňte tyto pracovní položky definovat a aktualizovat jejich stav při přesunu z nového na uzavřený. Zvažte pole nebo značky, které použijete k filtrování nebo seskupení dat v sestavě, a ujistěte se, že jsou dobře definované a konzistentní.
  • Pokud chcete podporovat souhrnné sestavy, ujistěte se, že mezi položkami backlogu produktu a úkoly nebo chybami existují propojení nadřazený-podřízený nebo mezi funkcemi nebo podřízenými pracovními položkami portfolia a jejich podřízenými položkami. Další informace najdete v tématu Uspořádání backlogu a mapování podřízených pracovních položek na nadřazené položky.
  • Pokud chcete vytvořit sestavy burndownu nebo burnupu, jako je burndown sprintu nebo burndown verze, ujistěte se, že jste si promysleli, jak chcete data v sestavě filtrovat a seskupit. Sestavy burndown/burnup odkazují na WorkItemsSnapshot sadu entit. Sady entit snímků se modelují jako denní snímky. Data se agregují na základě přiřazení provedených k datu, kdy jsou přiřazena. To znamená, že pokud chcete filtrovat sestavu burndownu nebo burnup na základě přiřazení polí nebo značek, musíte přiřadit pole nebo značky před obdobím, podle kterého chcete sestavu provést. V opačném případě nejsou pole nebo značky zaregistrovány sestavou až do data, kdy jsou použity.
  • Pokud chcete podporovat sledování požadavků, definujte testovací případy a vytvořte odkaz Testoval z každého testovacího případu na uživatelský scénář, položku backlogu produktu nebo požadavek. Definujte testovací případy a propojte testovací případy s jejich nadřazenými pbi pomocí odkazu Testováno. Viz Vytvoření testů.
  • (Doporučeno) Pokud chcete v sestavě podporovat filtrování a seskupování, přiřaďte všem pracovním položkám cestu k oblasti a cestu iterace . Informace o definování iteračních a plošných cest najdete v tématech Definování cest k oblasti a přiřazení týmu nebo Definování iteračních cest (sprintů) a konfigurace iterací týmu.

Poznámka

Všechna vlastní pole přidaná do typu pracovní položky jsou k dispozici pro použití v sestavách. Vlastní pole jsou označená Custom_DisplayNameOfField, kde byly ze zobrazovaného názvu odebrány všechny mezery.

Testovací plány

Aby týmy chtěly zkontrolovat průběh testovacího plánu a připravenost testovacích případů, musí provést následující aktivity.

  • Definujte testovací případy, testovací plány a testovací sady a určete jejich aktuální stav. Další informace najdete v tématech Vytvoření testovacích plánů a testovacích sad a Vytváření testovacích případů.
  • Aktualizujte stav testovacích objektů v průběhu z návrhu na připraveno až po zavřené.
  • U ručních testů označte výsledky každého kroku ověření v testovacím případě jako úspěšné nebo neúspěšné.

    Tip

    Testeři musí testovací krok označit stavem, pokud se jedná o ověřovací testovací krok. Celkový výsledek testu odráží stav všech označených kroků testu. Proto bude mít test stav neúspěšný, pokud je některý testovací krok označen jako neúspěšný nebo není označený.

  • U automatizovaných testů se každý test automaticky označí jako úspěšný nebo neúspěšný.
  • (Doporučeno) Pokud chcete v sestavě podporovat filtrování a seskupování, přiřaďte testovacím případům, testovacím sadům a testovacím plánům cestu k oblasti a cestu iterace .

Pipelines

Aby týmy hlásily kanály, musí definovat kanály pomocí YAML a kanály spouštět pravidelně. Další informace najdete v tématu Klíčové koncepty pro nové uživatele Azure Pipelines.

Kromě toho zvažte následující akce:

Kanály a testování

Pokud chcete hlásit výsledky kanálů a testů, nezapomeňte do definice kanálu přidat testovací úlohy. Další informace najdete v tématu Úlohy sestavení a vydání verze – testování.

Pokud teprve začínáte, zvažte projděte si tento modul Learn Spouštění testů kvality v kanálu sestavení pomocí Azure Pipelines.