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

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? A jak se daří v nových funkcích a řešit váš 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. A chcete spravovat vady kódu způsobem, který je v souladu s vašimi agilními postupy.

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 Sledování práce s uživatelskými příběhy, problémy, chybami, funkcemi a náměty.

Chyby také poskytují následující další 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

• Musíte být přidáni do projektu.
• Chcete-li zobrazit nebo upravit pracovní položky, musíte mít v tomto uzlu pracovní položky Zobrazení a upravit pracovní položky v tomto uzlu nastavena na Povolit. Ve výchozím nastavení má skupina Přispěvatelé tuto sadu oprávnění. Další informace najdete v tématu Nastavení oprávnění a přístupu pro sledování práce.
• Pokud chcete přidat nové značky pro přidání do pracovních položek, musíte mít základní přístup nebo vyšší a mít oprávnění k vytvoření nové definice značky na úrovni projektu nastavená na Povolit. Ve výchozím nastavení má skupina Přispěvatelé tuto sadu oprávnění. I když je oprávnění explicitně nastaveno pro účastníka, nemají oprávnění přidávat nové značky, protože jsou zakázány prostřednictvím úrovně přístupu. Další informace najdete ve stručné referenční příručce k přístupu pro účastníka.
• Všichni členové projektu, i členové skupiny Čtenáři , můžou odesílat e-maily obsahující pracovní položky.

Tip

Aby mohl uživatel nahlásit chybu, musí mít minimálně přístup účastníků a upravit pracovní položky v tomto uzlu nastavené na povolit cestu k oblasti, do které přidá chybu. Další informace najdete v tématu Nastavení oprávnění a přístupu 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 Agile a CMMI sleduje podobné informace. Je navržená tak, aby se zobrazovala 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 jsou výsledkem aktualizací webových aplikací, možností, které jste vy nebo váš správce povolili, a proces, který jste zvolili 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.

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 k reprodukování
(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í.

---

Informace o systému
Nalezeno 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. Týmy by tato kritéria měly používat jako základ pro akceptační testy a vyhodnotit, jestli byla 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é v sestavení , 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 tom, jak definovat čísla sestavení, najdete v tématu možnosti formátu čísla sestavení.

---

Priorita¹

• 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žnost¹

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á zkušenost 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. A 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 však 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.

---

Poznámky:

¹ 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.
• Jak váš tým uspořádá práci. 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ů

• Určení priorit chyb (pořadí zásobníků) spolu s požadavky
• Odhad úsilí o chyby pro prognózování
• Aktualizace stavu chyby na panelu Kanban
• Zahrnutí chyb do grafů rychlosti a kumulativních vývojových diagramů
• Pomocí nástroje Prognózamůžete podporovat plánování sprintů.
• Může přetáhnout chyby do podokna Plánování a přiřadit chyby sprintu.
• Může zobrazit chyby v plánech doručení

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
• Může přetáhnout chyby do podokna Plánování a přiřadit 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 nebudou viditelné ve službě Delivery Plans

---

Chyby se nezobrazují v backlogech ani na panelech

• Správa chyb pomocí dotazů

Poznámka:

• Chyby jsou přidružené k kategorii Chyb a nezobrazí se v backlogech ani na panelech.
• Chyby se nezobrazují v backlogech, panelech, backlogech sprintů, na panelech nebo v plánech doručení.
• Nejde přetáhnout chyby do podokna Plánování a přiřadit 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 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.

Přidání nebo zachycení chyb

Chyby můžete definovat z několika různých nástrojů Azure DevOps. Patří mezi ně 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 rychle přidávat chyby stejným způsobem, jakým přidáváte uživatelské scénáře nebo položky backlogu produktů. Pokud chcete některá pole vyžadovat, udělejte to přidáním podmíněných pravidel na základě změny stavu. Další informace naleznete v tématu Přidání pravidla do typu pracovní položky (proces dědičnosti).

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 produktu nebo z panelu Kanban. Další informace najdete v tématu Vytvoření backlogu produktu nebo použití panelu Kanban.

• Přidání chyby z backlogu produktu

  

• Přidání chyby z backlogu produktu

  

Tip

Když přidáte chybu z backlogu produktu nebo panelu Kanbanu, 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 Kanban, produktového backlogu, backlogu sprintu nebo z taskboardu sprintu. Do pracovní položky backlogu produktu přidáte chybu jako podřízenou položku.

• Přidání propojené podřízené chyby z panelu Kanban
  Chybu přidáte stejným způsobem jako úkol do položky backlogu. Další informace naleznete v tématu Přidání úkolů nebo podřízených položek jako kontrolních seznamů.

  

• Přidání propojené podřízené chyby z backlogu sprintu
  Chybu přidáte stejným způsobem jako úkol do backlogu sprintu. Další informace naleznete v tématu Přidání úkolů do položek backlogu.

  

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ů.

  

• 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í s rozšířením Test &Feedback.

Ž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

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 se po vyřešení nebo zavření chyby zjistilo více práce, můžete ji znovu aktivovat 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 naleznete v tématu Použití pravidel na stavy pracovního postupu, 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

Jakmile se chyba ověří jako opravená, zavřete ji. Můžete ale také zavřít chybu z některého z následujících důvodů. Důvody, proč vybrat, závisí na procesu projektu a na 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

Jakmile dojde k zavření chyby a oprava se aktivně uvolní 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ší. Potom můžete do týmových řídicích panelů 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 – chyby otevřené během posledních tří týdnů (Created Date > @Today-21)

Jakmile budete mít 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, budete chtít pravidelné schůzky se tříděním, abyste mohli 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 rychle přejít nahoru a dolů v seznamu pracovních položek chyb pomocí šipek nahoru a dolů. Při kontrole každé chyby ji můžete přiřadit, přidat podrobnosti nebo nastavit prioritu.

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:

• Uspořádání chyb v backlogu, pořadí zásobníku oproti ostatním položkám (řazení zásobníku je při povoleném filtrování zakázané)
• Přiřazení chyb do sprintu z backlogu pomocí podokna Plánování
• Nadřazené chyby funkcím nebo jiným položkám backlogu portfolia pomocí podokna Mapování
• Umožňuje zobrazit souhrn práce s položkami backlogu portfolia.

Pokud váš tým sleduje chyby jako úkoly, použijte spravované dotazy k výpisu a třídění chyb. Pak v rámci každého sprintu uvidíte chyby přiřazené 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.

K iteraci je možné přiřadit úkoly nebo chyby, ale nejsou propojené 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 nebyly propojeny s nadřazenou položkou backlogu. Na stránce backlogu sprintu se zobrazí jenom chyby a úkoly, které jste propojili s položkou nadřazeného produktového backlogu (Scrum), uživatelským scénářem (Agilní) nebo požadavkem (CMMI) s cestou iterace 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 jste vytvořili 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.
• 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 Kanban přidat testy a ověřit opravy chyb.

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 Kanban, jak je znázorněno na následujícím obrázku. Další informace najdete v tématu Začínáme s panelem Kanban.

  

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

  

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:

• Přidání sloupců na panel Kanban
• Přizpůsobení panelu úkolů sprintu
• Dotazy na změnu panelu Kanbanu

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, že se po vyřešení chyby znovu přiřazuje osobě, která chybu otevřela. 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).

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. V následujícím příkladu nastavíme pracovní položky #300 a #301 na Vyřešeno a #323 a #324 na Uzavřeno.

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.

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

Propojení pracovních položek s vývojem

Ovládací prvek Pro vývoj podporuje propojení a zobrazování odkazů provedených na buildy, potvrzení Gitu a žádosti o přijetí změn. Nebo když se použije ú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.

Propojení pracovních položek s verzemi

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.

Propojení pracovních položek se spuštěním kanálu

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.

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 Možnosti sestavení, Vytvoření pracovní položky při selhání.

Monitorování stavu chyb, přiřazení a trendů

Stav chyby, přiřazení a trendy můžete sledovat pomocí dotazů, které pak 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.

Další informace o dotazech, grafech a řídicích panelech; Viz Informace o spravovaných dotazech a 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 a 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 Co jsou zobrazení Analýzy 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ž jaké můžete získat z dotazu. Další informace najdete v tématu Připojení s Připojení dat Power BI.

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

Související články

• Přesunutí, změna typu nebo odstranění pracovních položek
• Kopírování nebo klonování pracovní položky

Backlog produktu a panel Kanban

• Backlogy, portfolia a agilní řízení projektů
• Vytvoření backlogu
• Definování funkcí a námětů
• Uspořádání backlogu, mapování podřízených pracovních položek na rodiče
• Interaktivní filtrování backlogů, panelů, dotazů a plánů
• Prognózování backlogu produktu

Panel Kanbanu

• Informace o boardsch a Kanbanu
• Rychlý start k panelu Kanban
• Změna pořadí karet
• Přidání úkolů nebo podřízených položek jako kontrolních seznamů

Backlog sprintu a panel úloh

• Scrum a práce s osvědčenými postupy sprintů
• Přiřazení položek backlogu ke sprintu
• Přidání úkolů
• Aktualizace panelu úloh

Integrace v Azure DevOps

• Propojení uživatelských scénářů, problémů, chyb a dalších pracovních položek
• Sledování pracovní položky nebo žádosti o přijetí změn
• Konfigurace čísel spuštění nebo sestavení

Oborové zdroje

• Dobrý a špatný technický dluh (a jak TDD pomáhá) Henrik Kniberg
• Správa technického dluhu zveřejněného SvenEm Johannem & EberhardEm Wolffem