Sdílet prostřednictvím

Definování, zachytávání, třídění a správa chyb softwaru v Azure Boards

  • Článek

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

Jak sledujete a spravujete vady v kódu? Jak zajistíte, aby se problémy se softwarem a zpětná vazba zákazníků rychle řešila podporu vysoce kvalitních nasazení softwaru? Jak děláte dobrý pokrok v nových funkcích a řešit svůj technický dluh?

Minimálně potřebujete způsob, jak zachytit problémy se softwarem, určit jejich prioritu, přiřadit je členu týmu a sledovat průběh. Chyby kódu chcete spravovat způsoby, které odpovídají vašim agilním postupům.

Pro podporu těchto scénářů poskytuje Azure Boards konkrétní typ pracovní položky pro sledování vad kódu s názvem Chyba. Pracovní položky chyb sdílejí všechny standardní funkce jiných typů pracovních položek s několika dalšími. Přehled standardních funkcí najdete v tématu O pracovních položkách a typech pracovních položek.

Chyby také poskytují následující funkce:

  • Možnosti pro každý tým, aby si zvolili, jak chtějí sledovat chyby
  • Testovací nástroje pro zachycení chyb
  • Integrovaná integrace v Azure DevOps ke sledování chyb propojených s buildy, verzemi a testy

Poznámka:

Typy pracovních položek chyb nejsou v procesu Basic k dispozici. Základní proces sleduje chyby jako Problémy a je k dispozici při vytváření nového projektu ze služeb Azure DevOps Services nebo Azure DevOps Serveru 2019.1 nebo novějších verzí.

Požadavky

  • Přístup k projektu: Buďte členem projektu.

  • Oprávnění:

    • Chcete-li zobrazit, sledovat a upravovat pracovní položky, mají v tomto uzlu pracovní položky a upravit pracovní položky v tomto uzlu nastavena na povolit. Ve výchozím nastavení má skupina Přispěvatelé tato oprávnění. Další informace naleznete v tématu Nastavení oprávnění ke sledování práce.

  • Pokud chcete přidat značky do pracovních položek, na úrovni projektu nastavte oprávnění Vytvořit novou definici značky na hodnotu Povolit. Ve výchozím nastavení má skupina Přispěvatelé toto oprávnění.

  • Úrovně přístupu:

    • Pokud chcete přidat nové značky do pracovních položek nebo zobrazit nebo sledovat žádosti o přijetí změn, musíte mít alespoň základní přístup.
    • Pokud chcete zobrazit nebo sledovat pracovní položky, musíte mít alespoň přístup účastníka . Další informace najdete v tématu O úrovních přístupu.
    • Všichni členové projektu, včetně členů skupiny Čtenáři , můžou odesílat e-maily obsahující pracovní položky.

    Poznámka:

    • Poskytněte účastníkům přístup k členům, kteří chtějí přispívat k diskuzi a kontrolovat průběh. Obvykle se jedná o členy, kteří do kódu nepřispívají, ale chtějí zobrazit pracovní položky, backlogy, panely a řídicí panely.
    • Zúčastněné strany nemůžou přidávat nové značky, ani když je oprávnění explicitně nastaveno kvůli jejich úrovni přístupu. Další informace najdete ve stručné referenční příručce k přístupu pro účastníka.

Tip

Pokud chce uživatel nahlásit chybu, musí mít minimálně přístup účastníka . Uživatel musí mít v tomto uzlu nastavená oprávnění Upravit pracovní položky tak, aby umožňovala cestu k oblasti, do které přidá chybu. Další informace najdete v tématu Nastavení oprávnění pro sledování práce.

Typ pracovní položky chyby

Následující obrázek ukazuje typ pracovní položky chyby pro proces Scrum. Typ pracovní položky chyby pro procesy Agilní a schopností integrace modelu vyspělosti (CMMI) sleduje podobné informace. Zobrazuje se v backlogu produktu spolu s požadavky nebo na Taskboardu spolu s úkoly.

Poznámka:

Obrázky, které vidíte na webovém portálu, se můžou lišit od obrázků, které vidíte v tomto článku. Tyto rozdíly vyplývají z aktualizací webových aplikací, možností, které jste vy nebo správce povolili a který proces byl zvolen při vytváření projektu: Agile, Basic, Scrum nebo CMMI. Základní proces je k dispozici s Azure DevOps Serverem 2019 Update 1 a novějšími verzemi.

Snímek obrazovky znázorňující formulář typu pracovní položky chyby pro proces Scrum v Azure DevOps Serveru 2020 a cloudové službě

Snímek obrazovky znázorňující formulář typu pracovní položky chyby pro proces Scrum v Azure DevOps Serveru 2019

Pole specifická pro chyby

Typ pracovní položky Chyby používá některá pole specifická pro chyby. Pokud chcete zachytit počáteční i probíhající zjišťování, použijte pole popsaná v následující tabulce. Informace opolích Informace o všech ostatních polích naleznete v tématu Index polí pracovní položky.

Pole, skupina nebo karta

Využití

Kroky pro reprodukci (popisný název=Kroky pro reprodukci)

Umožňuje zachytit dostatek informací, aby ostatní členové týmu plně porozuměli vadě kódu. Zahrňte akce prováděné k vyhledání nebo reprodukci chyby a očekávaného chování.

Systémové informacenalezené v buildu

Informace o konfiguraci softwaru a systému, které jsou relevantní pro chybu a testy, které se mají použít. Při vytváření chyby pomocí testovacího nástroje se automaticky vyplní systémové informace a pole Nalezené v sestavení . Tato pole určují informace o softwarovém prostředí a sestavte, kde došlo k chybě. Další informace naleznete v tématu Testování různých konfigurací.

Kritéria přijetí

Zadejte kritéria, která mají být splněna před uzavřením chyby. Než začne práce, popište co nejjasnější kritéria přijetí zákazníka. Teams by tato kritéria měla používat jako základ pro akceptační testy a vyhodnotit, jestli je položka uspokojivě dokončena.

Integrováno do sestavení

Určuje název sestavení, který obsahuje kód, který chybu opravuje. Toto pole by mělo být zadáno při řešení chyby.

Pokud chcete získat přístup k rozevírací nabídce všech spuštěných sestavení v místním Prostředí Azure DevOps, můžete aktualizovat FIELD definice nalezené v sestavení a integrovaném sestavení tak, aby odkazovaly na globální seznam. Globální seznam se automaticky aktualizuje o každé spuštěné sestavení. Další informace najdete v tématu Dotaz na základě polí integrace sestavení a testování.

Informace o definování čísel sestavení najdete v tématu Konfigurace klasických kanálů.

Priorita1

  • 1: Produkt vyžaduje úspěšné řešení pracovní položky před odesláním a brzy vyřešeno.
  • 2: Produkt vyžaduje úspěšné řešení pracovní položky před odesláním, ale není nutné ji okamžitě řešit.
  • 3: Řešení pracovní položky je volitelné na základě zdrojů, času a rizika.

Závažnost1

Subjektivní hodnocení dopadu chyby nebo pracovní položky na projekt nebo softwarový systém. Příklad: Pokud vzdálené propojení v rámci uživatelského rozhraní (vzácná událost) způsobí chybové ukončení aplikace nebo webové stránky (závažné prostředí zákazníka), můžete zadat závažnost = 2 – vysoká a priorita = 3. Povolené hodnoty a navrhované pokyny jsou:

  • 1 – Kritické: Musí se opravit. Chyba, která způsobuje ukončení jedné nebo více systémových komponent nebo kompletního systému nebo způsobuje rozsáhlé poškození dat. Neexistují žádné přijatelné alternativní metody pro dosažení požadovaných výsledků.
  • 2 - Vysoká: Zvažte opravu. Chyba, která způsobuje ukončení jedné nebo více systémových komponent nebo kompletního systému nebo způsobuje rozsáhlé poškození dat. Existuje přijatelná alternativní metoda pro dosažení požadovaných výsledků.
  • 3 – Střední: (Výchozí) Chyba, která způsobí, že systém vytvoří nesprávné, neúplné nebo nekonzistentní výsledky.
  • 4 - Nízká: Menší nebo kosmetická vada, která má přijatelné alternativní řešení pro dosažení požadovaných výsledků.

Nasazení

Ovládací prvek Nasazení podporuje odkazy na verze obsahující pracovní položky a jejich zobrazení. Pokud chcete ovládací prvek použít, musíte povolit nastavení vydané verze. Další informace najdete v tématu Propojení pracovních položek s verzemi dále v tomto článku.

Vývoj

Ovládací prvek Vývoj podporuje odkazy na a zobrazení odkazů provedených s vývojovými objekty. Mezi tyto objekty patří potvrzení Gitu a žádosti o přijetí změn nebo sady změn TFVC a položky s verzí. Můžete definovat odkazy z pracovní položky nebo z potvrzení, žádostí o přijetí změn nebo jiných vývojových objektů. Další informace najdete v tématu Propojení pracovních položek s vývojem dále v tomto článku.

Notes

1 Chcete-li změnit výběr nabídky nebo rozevírací seznam, viz Přizpůsobení prostředí sledování práce. Metoda přizpůsobení závisí na modelu procesu používaném vaším projektem.

Volba způsobu, jakým váš tým sleduje chyby

Váš tým může sledovat chyby jako požadavky nebo úkoly. Pokud chcete podporovat výběr týmu, zvažte následující faktory.

  • Velikost vašeho týmu. Menší týmy můžou udržovat jednoduchou stopu sledováním chyb jako požadavků.
  • Požadavky organizace na sledování práce Pokud je váš tým nutný ke sledování hodin, zvolte, jestli chcete sledovat chyby jako úkoly.
  • Organizace práce vašeho týmu Pokud váš tým spoléhá na backlog produktu, aby upřednostněl práci a přidal chyby, sledujte chyby jako požadavky.
  • Nástroje, které váš tým chce použít, jako je podokno Plánování, graf rychlosti, prognóza, souhrn a plány doručení. Sledování chyb jako úkolů zabraňuje použití několika z těchto nástrojů.

Následující tabulka shrnuje tři týmy možností, které musí sledovat chyby. Další informace a nastavení možnosti pro váš tým najdete v tématu Zobrazení chyb v backlogech a panelech.

Možnost

Zvolte, kdy chcete...

Sledování chyb jako požadavků

Poznámka:

  • Chyby se přiřazují kategorii Požadavky.

Sledování chyb jako úkolů

  • Odhad práce u chyb podobných úkolům
  • Aktualizace stavu chyby na panelech úloh sprintu
  • Propojení chyb s požadavky jako podřízených položek
  • Přetažením chyb do podokna Plánování přiřadíte chyby sprintu.

Poznámka:

  • Chyby se přiřazují kategorii úkolů.
  • Uživatelské scénáře (agilní), položky backlogu produktu (Scrum) nebo požadavky (CMMI) jsou přirozeným nadřazeným typem pracovní položky pro chyby.
  • Chyby se nezobrazují v plánech doručení

Chyby se nezobrazují v backlogech ani na panelech

  • Správa chyb pomocí dotazů

Poznámka:

  • Chyby jsou přidružené k kategorii Chyb a nezobrazují se v backlogech ani na panelech.
  • Chyby se nezobrazují v backlogech, panelech, backlogech sprintů, na panelech nebo v plánech doručení
  • Nemůžete přetáhnout chyby do podokna Plánování, abyste přiřadili chyby sprintu.

Přizpůsobení typu pracovní položky

Můžete přizpůsobit typ Chyby a další typy pracovních položek. Nebo můžete vytvořit vlastní typy pro sledování problémů se softwarem nebo zpětné vazby zákazníků. U všech typů pracovních položek můžete přizpůsobit následující prvky:

  • Přidání nebo odebrání vlastních polí
  • Přidání vlastních ovládacích prvků nebo vlastních karet ve formuláři pracovní položky
  • Přizpůsobení stavů pracovního postupu
  • Přidání podmíněných pravidel
  • Zvolte úroveň backlogu, ve které se zobrazují pracovní položky.

Před přizpůsobením procesu doporučujeme zkontrolovat informace o konfiguraci a přizpůsobení Azure Boards.

Pokud chcete přizpůsobit konkrétní proces, přečtěte si téma Přizpůsobení procesu dědičnosti.

Pokud chcete přizpůsobit konkrétní proces, přečtěte si téma Přizpůsobení procesu dědičnosti nebo Přizpůsobení místního modelu procesu XML.

Přidání nebo zachycení chyb

Chyby můžete definovat z několika různých nástrojů Azure DevOps. Mezi tyto nástroje patří backlogy a panely a testovací nástroje.

Tip

Ve výchozím nastavení je pole Název jediným povinným polem při vytváření chyby. Pomocí Azure Boards můžete přidávat chyby stejným způsobem, jakým přidáváte uživatelské scénáře nebo položky backlogu produktů. Některá pole můžete vyžadovat přidáním podmíněných pravidel na základě změny stavu. Další informace najdete v tématu Přidání pravidla do typu pracovní položky.

Přidání chyby z backlogu nebo panelu

Pokud se váš tým rozhodl spravovat chyby s požadavky, můžete definovat chyby z backlogu nebo panelu produktu. Další informace najdete v tématu Vytvoření backlogu produktu nebo použití panelu.

  • Přidání chyby z backlogu produktu

    Snímek obrazovky ukazuje přidání chyby z backlogu produktu.

  • Přidání chyby z panelu

    Snímek obrazovky znázorňující přidání chyby z panelu

Tip

Když přidáte chybu z backlogu nebo panelu produktu, přiřadí se automaticky výchozí cesta k oblasti a cesta iterace definovaná pro tým. Další informace najdete v tématu Výchozí hodnoty týmu, na které odkazují backlogy a panely.

Přidání chyby z backlogu sprintu nebo z taskboardu

Pokud se váš tým rozhodl spravovat chyby pomocí úkolů, můžete definovat chyby z panelu, backlogu produktu, backlogu sprintu nebo z taskboardu sprintu. Do pracovní položky backlogu produktu přidáte chybu jako podřízenou položku.

Vytvoření chyby z testovacího nástroje

Dva testovací nástroje, které můžete použít k přidání chyb při testování, zahrnují Test Runner webového portálu a rozšíření Test &Feedback.

  • Test Runner: Při spouštění ručních testů se můžete rozhodnout vytvořit chybu. Další informace naleznete v tématu Spouštění ručních testů.

    Snímek obrazovky ukazuje Test Runner, kde můžete přidat chybu.

  • Rozšíření Test &Feedback: Při spouštění průzkumných testů můžete vytvořit chybu nebo vytvořit úlohu. Další informace najdete v tématu Průzkumné testování pomocí rozšíření Test &Feedback.

    Snímek obrazovky ukazuje rozšíření Test &Feedback, kde můžete přidat funkci chyby nebo úkolu.

Životní cyklus chyb a stavy pracovního postupu

Stejně jako u všech ostatních typů pracovních položek má typ pracovní položky chyby dobře definovaný pracovní postup. Každý pracovní postup se skládá ze tří nebo více stavů a důvodu. Důvody určují, proč položka přešla z jednoho státu na jiný. Následující obrázky znázorňují výchozí pracovní postup chyby definovaný pro procesy Agile, Scrum a CMMI .

Agilita Scrum CMMI
Diagram znázorňuje stavy pracovního postupu chyb v šabloně agilního procesu. Diagram znázorňuje stavy pracovního postupu chyby v šabloně procesu Scrum. Diagram znázorňuje stavy pracovního postupu chyby v šabloně procesu CMMI.

U chyb Scrum změníte stav ze stavu Potvrzeno (podobně jako Aktivní) na Hotovo. U Agilních a CMMI nejprve chybu vyřešíte a vyberete důvod, který indikuje, že je chyba opravená. Obvykle osoba, která chybu vytvořila, pak ověří opravu a aktualizuje stav z Vyřešeno na Uzavřeno. Pokud po vyřešení nebo zavření chyby zjistíte další práci, znovu ji aktivujte nastavením stavu na Potvrzeno nebo Aktivní.

Poznámka:

Typ pracovní položky procesu agilního procesu měl dříve pravidlo, které tuto chybu znovu přiřadilo osobě, která ji vytvořila. Toto pravidlo bylo odebráno z výchozího systémového procesu. Tuto automatizaci můžete obnovit přidáním pravidla. Informace o procesu dědičnosti najdete v tématu Automatizace opětovného přiřazení na základě změny stavu.

Ověření opravy

Pokud chcete ověřit opravu, vývojář nebo tester se pokusí chybu reprodukovat a vyhledat neočekávanější chování. V případě potřeby by měli chybu znovu aktivovat.

Při ověřování opravy chyb můžete zjistit, že chyba nebyla opravena, nebo můžete nesouhlasit s řešením. V tomto případě proberte chybu s osobou, která ji vyřešila, přišla ke smlouvě a případně znovu aktivovala chybu. Pokud chybu znovu aktivujete, uveďte důvody opětovné aktivace chyby v popisu chyby.

Zavření chyby

Chybu zavřete, když ji člen týmu ověří jako opravenou. Můžete ale také zavřít chybu z některého z následujících důvodů. Dostupné důvody závisí na procesu projektu a stavu přechodu chyb.

Agilní proces:

  • Deferred: Odložení opravy chyb až do příští verze produktu.
  • Opraveno: Chyba je ověřena jako opravená.
  • Duplicitní: Chyba sleduje jinou aktuálně definovanou chybu. Každou chybu můžete propojit s typem duplicitního nebo duplicitního odkazu a zavřít jednu z chyb.
  • Jak je navrženo: Funkce funguje tak, jak je navržena.
  • Nelze reprodukovat: Testy ukazují, že chybu nelze reprodukovat.
  • Zastaralé: Funkce chyby už není v produktu.
  • Zkopírováno do backlogu: Byl otevřen scénář uživatele ke sledování chyby.

Proces Scrum:

  • Ne chyba: Chyba je ověřena, že se nejedná o chybu.
  • Duplicitní: Chyba sleduje jinou aktuálně definovanou chybu. Každou chybu můžete propojit s typem duplicitního nebo duplicitního odkazu a zavřít jednu z chyb.
  • Odebráno z backlogu: Chyba je ověřena, že se nejedná o chybu. Odeberte chybu z backlogu.
  • Práce byla dokončena: Chyba byla ověřena jako opravená.

Proces CMMI:

  • Deferred: Odložení opravy chyb až do příští verze produktu.
  • Duplicitní: Chyba sleduje jinou aktuálně definovanou chybu. Každou chybu můžete propojit s typem duplicitního nebo duplicitního odkazu a zavřít jednu z chyb.
  • Odmítnuto: Chyba je ověřena, že se nejedná o chybu.
  • Ověřeno: Chyba se ověřuje jako opravená.

Tip

Po zavření chyby a oprava je aktivně vydána v nasazeních, doporučeným postupem je nikdy ji neotevřet kvůli regresi. Místo toho byste měli zvážit otevření nové chyby a odkaz na starší, uzavřenou chybu.

Vždy je vhodné popsat jakékoli další podrobnosti o zavření chyby v poli Diskuze , abyste se vyhnuli budoucím nejasnostem ohledně toho, proč byla chyba uzavřena.

Automatizace uzavření chyb při slučování žádostí o přijetí změn

Pokud váš tým používá úložiště Git, můžete nastavit stav v propojených chybách a dalších pracovních položkách, aby se zavřel po úspěšném sloučení žádostí o přijetí změn. Další informace najdete v tématu Nastavení stavu pracovní položky v žádosti o přijetí změn dále v tomto článku.

Vypisování a třídění chyb

Většina týmů bez ohledu na to, jestli se rozhodli sledovat chyby, definovat jeden nebo více dotazů na chyby. Pomocí dotazů můžete vypsat aktivní chyby, nepřiřazené chyby, zastaralé chyby, trendy chyb a další. Do týmových řídicích panelů můžete přidat dotazy a grafy dotazů, abyste mohli monitorovat stav a průběh chyb.

Dotazy na chyby

Otevřete sdílený dotaz nebo pomocí editoru dotazů vytvořte užitečné dotazy na chyby, například následující možnosti:

  • Aktivní chyby podle priority (State <> Done nebo State <> Closed)
  • Probíhající chyby (State = Committed nebo State = Active)
  • Chyby, které je potřeba opravit pro cílovou verzi (Tags Contains RTM)
  • Nedávné chyby, například chyby otevřené za poslední tři týdny (Created Date > @Today-21)

Pokud máte dotazy, které vás zajímají, můžete vytvořit grafy stavu nebo trendu. Graf, který vytvoříte, můžete také přidat na řídicí panel.

Režim třídění ve výsledcích dotazu

Jakmile začnete programovat a testovat, můžete pravidelně kontrolovat a hodnotit chyby. Vlastník projektu obvykle spouští schůzky pro třídění chyb. Vedoucí týmu, obchodní analytici a další účastníci, kteří můžou mluvit o konkrétních rizicích projektu, se účastní schůzek se tříděním.

Vlastník projektu může definovat sdílený dotaz pro nové a znovu otevřené chyby a vypsat chyby, které se mají určit jako třídění.

Na stránce s výsledky dotazu můžete pomocí šipek nahoru a dolů přejít nahoru a dolů v seznamu pracovních položek chyb. Při kontrole každé chyby ji můžete přiřadit, přidat podrobnosti nebo nastavit prioritu.

Snímek obrazovky s podoknem výsledky dotazu, aktivními chybami a režimem třídění vpravo

Uspořádání a přiřazování chyb sprintu

Pokud váš tým sleduje chyby jako požadavky, podívejte se na seznam aktivních chyb z backlogu. Pomocí funkce filtru se můžete soustředit výhradně na chyby. Z backlogu produktu můžete také provádět následující úlohy:

Pokud váš tým sleduje chyby jako úkoly, použijte spravované dotazy k výpisu a třídění chyb. V každém sprintu uvidíte chyby přiřazené k sprintu z backlogu sprintu nebo z taskboardu.

Položky panelu úkolů versus položky seznamu dotazů

Možná si všimnete a zajímá vás, proč se položky zobrazené na panelu úkolů sprintu můžou lišit od seznamu dotazů vytvořeného v odpovídajícím backlogu sprintu.

Úkoly nebo chyby je možné přiřadit iteraci, ale není možné je propojit s nadřazenou položkou backlogu. Tyto položky se zobrazí v vytvořeném dotazu, ale nemusí se zobrazit na samotném panelu úloh. Systém spustí dotaz a před zobrazením položek panelu úloh použije několik procesů na pozadí.

Tyto důvody můžou způsobit, že pracovní položky, které patří do kategorie úkolů, se nezobrazují v backlogu sprintu nebo na panelu úkolů:

  • Úkol nebo chyba nejsou propojené s nadřazenou položkou backlogu. Na stránce backlogu sprintu se zobrazí pouze chyby a úkoly s nadřazenou položkou backlogu produktu (Scrum), uživatelským scénářem (Agilní) nebo požadavkem (CMMI) s iterační cestou nastavenou na sprint.
  • Úkol nebo chyba je nadřazený jiným úkolem nebo chybou nebo je uživatelský scénář nadřazený jinému uživatelskému scénáři. Pokud vytvoříte hierarchii úkolů, chyb nebo uživatelských scénářů, zobrazí se v dolní části hierarchie pouze podřízené úkoly nebo podřízené scénáře. Další informace najdete v tématu Řešení potíží s změna pořadím a vnořením.
  • Propojený nadřazený objekt úkolu nebo chyba odpovídá položce backlogu definované pro jiný tým. Nebo se cesta oblasti nadřazené položky backlogu úkolu nebo chyby liší od cesty oblasti úkolu nebo chyby.

Vytváření vložených testů propojených s chybami

Když váš tým sleduje chyby jako požadavky, můžete pomocí panelu přidat testy a ověřit opravy chyb.

Snímek obrazovky panelu se třemi sloupci zobrazující vložené testy přidané a propojené s chybami

Aktualizace stavu chyby

Stav chyby můžete aktualizovat přetažením chyb do nového sloupce na panelu.

  • Pokud váš tým sleduje chyby jako požadavky, použijete panel, jak je znázorněno na následujícím obrázku. Další informace naleznete v tématu Aktualizace stavu pracovní položky.

    Snímek obrazovky panelu, kde můžete přetažením chyby aktualizovat stav

  • Pokud váš tým sleduje chyby jako úkoly, použijete Taskboard. Další informace najdete v tématu Aktualizace a monitorování panelu úloh.

    Snímek obrazovky s panelem úloh, kde můžete přetažením chyby aktualizovat stav

Přizpůsobení panelu pro sledování přechodných stavů

Na panelu můžete přidat přechodné sloupce pro sledování stavu chyby. Můžete také definovat dotazy, které filtrují na základě stavu sloupce panelu. Další informace najdete v následujících článcích:

Automatizace opětovného přiřazení chyb na základě stavu pracovního postupu

Pokud chcete automatizovat výběrové akce, přidejte do typu pracovní položky chyby vlastní pravidla. Přidejte například pravidlo, jak je znázorněno na následujícím obrázku. Toto pravidlo určuje opětovné přiřazení chyby osobě, která chybu otevřela, když ji člen týmu vyřeší. Tato osoba obvykle ověří, že je chyba opravená a zavře ji. Další informace naleznete v tématu Použití pravidel na stavy pracovního postupu (proces dědičnosti).

Snímek obrazovky s pravidlem definovaným pro opětovné přiřazení chyby na základě vyřešeného stavu

Nastavení stavu pracovní položky v žádosti o přijetí změn

Při vytváření žádosti o přijetí změn můžete v popisu nastavit hodnotu stavu propojených pracovních položek. Postupujte podle syntaxe: {state value}: #ID.

Při sloučení žádosti o přijetí změn systém přečte popis a aktualizuje stav pracovní položky. Následující příklad nastaví pracovní položky #300 a #301 na Vyřešeno a #323 a #324 na Uzavřeno.

Snímek obrazovky s nastavením stavu pracovní položky v rámci žádosti o přijetí změn

Poznámka:

Tato funkce vyžaduje instalaci aktualizace Azure DevOps Serveru 2020.1. Další informace najdete v tématu Poznámky k verzi pro Azure DevOps Server 2020 Update 1 RC1, Boards.

Integrace napříč Azure DevOps

Jednou z metod, které Azure DevOps používá k podpoře integrace, je propojení objektů s jinými objekty. Kromě propojení pracovních položek s pracovními položkami můžete také propojit pracovní položky s jinými objekty. Odkaz na objekty, jako jsou buildy, verze, větve, potvrzení a žádosti o přijetí změn, jak je znázorněno na následujícím obrázku.

Diagram znázorňující typy propojení používané k propojení pracovních položek s objekty sestavení a vydání

Můžete přidat odkaz z pracovní položky nebo z objektů sestavení a vydané verze.

Ovládací prvek Vývoj podporuje propojení a zobrazování odkazů provedených na buildy, potvrzení Gitu a žádosti o přijetí změn. Při použití úložiště TFVC podporuje odkazy na sady změn a položky s verzí. Když vyberete odkaz, otevře se odpovídající položka na nové kartě prohlížeče. Další informace najdete v tématu Vývoj gitu z pracovní položky.

Snímek obrazovky znázorňující řízení vývoje ve formuláři pracovní položky s ukázkovými odkazy na sestavení, žádosti o přijetí změn a potvrzení

Ovládací prvek Nasazení podporuje odkazy na verze obsahující pracovní položky a jejich zobrazení. Následující obrázek například ukazuje několik verzí, které obsahují odkazy na aktuální pracovní položku. Jednotlivé verze můžete rozbalit a zobrazit podrobnosti o jednotlivých fázích. Můžete zvolit odkaz pro každou verzi a fázi a otevřít odpovídající verzi nebo fázi. Další informace najdete v tématu Propojení pracovních položek s nasazeními.

Snímek obrazovky znázorňující ovládací prvek Nasazení ve formuláři pracovní položky s ukázkovými verzemi

Kanály se často definují tak, aby se automaticky spouštěly, když dojde k novému potvrzení do úložiště Git. Pracovní položky přidružené ke kanálům potvrzení se zobrazí jako součást spuštění kanálu, pokud přizpůsobíte nastavení kanálu. Další informace najdete v tématu Přizpůsobení kanálu.

Snímek obrazovky nastavení kanálu se zvýrazněnou možností Automaticky propojit pracovní položky v tomto spuštění z vybrané větve

Vytvoření nebo úprava pracovní položky při selhání sestavení

Pokud používáte klasické kanály (ne YAML), můžete vytvořit pracovní položky při selhání sestavení. Další informace najdete v tématu Vytvoření pracovní položky při selhání.

Stav chyby, přiřazení a trendy můžete sledovat pomocí dotazů, které můžete grafovat a přidávat na řídicí panel. Tady jsou například dva příklady ukazující aktivní trendy chyb podle stavu a aktivních chyb podle priority v průběhu času.

Snímek obrazovky se dvěma grafy aktivních dotazů na chyby, trendy chyb podle stavu a podle priority

Další informace o dotazech, grafech a řídicích panelech najdete ve spravovaných dotazech, grafech a řídicích panelech.

Vytváření sestav chyb pomocí zobrazení Analytics a služby Analytics

Služba Analytics je platforma pro vytváření sestav pro Azure DevOps. Nahrazuje předchozí platformu založenou na službě SQL Server Reporting Services.

Zobrazení analýzy poskytují předem připravené filtry pro zobrazení pracovních položek. Pro hlášení chyb se podporují čtyři analytická zobrazení. Tato zobrazení můžete použít jako definovaná nebo dále upravit k vytvoření vlastního filtrovaného zobrazení.

  • Chyby – historie po měsících
  • Chyby – posledních 26 týdnů
  • Chyby – posledních 30 dní
  • Chyby – dnes

Další informace o používání analytických zobrazení najdete v tématu o zobrazeních Analýza a vytvoření aktivní sestavy chyb v Power BI na základě vlastního zobrazení Analýzy.

Pomocí Power BI můžete vytvářet složitější sestavy než dotaz. Další informace najdete v tématu Připojení pomocí datového konektoru Power BI.

Předdefinované zprávy o chybách SQL Serveru

Následující sestavy jsou podporovány pro procesy Agile a CMMI.

Tyto sestavy vyžadují, abyste pro svůj projekt nakonfigurovali Služba Analysis Services serveru SQL a službu SQL Server Reporting Services. Informace o tom, jak přidat sestavy SQL Serveru pro projekt, najdete v tématu Přidání sestav do projektu.

Rozšíření Marketplace

Existuje několik rozšíření Marketplace souvisejících s chybami. Podívejte se na Marketplace pro Azure DevOps.

Další informace o rozšířeních najdete v tématu Rozšíření Azure Boards vyvinutá Microsoftem.

Další kroky

Přidání a aktualizace pracovních položek pomocí šablon

Backlog produktu a panel

Prkno

Backlog sprintu a panel úloh

Integrace v Azure DevOps

Oborové zdroje