Šablona dat pro životní cyklus vývoje softwaru

ServiceNow DevOps
Šablona dat pro životní cyklus vývoje softwaru

Šablona dat pro životní cyklus vývoje softwaru

Tato šablona vám pomůže shromáždit data potřebná k optimalizaci životního cyklu vývoje softwaru. Uvádí, které atributy máte sbírat a které důležité aktivity sledovat, a nabízí praktický návod, jak data získat ze ServiceNow DevOps. Využijte ji k vytvoření kvalitního záznamu událostí pro smysluplnou analýzu procesů.
  • Doporučené atributy ke sběru
  • Důležité aktivity ke sledování
  • Návod na získání dat ze ServiceNow DevOps
Pracujete se záznamy událostí poprvé? Přečtěte si, jak vytvořit záznam událostí pro process mining.

Atributy životního cyklu vývoje softwaru

Jde o doporučená datová pole, která zahrňte do záznamu událostí pro důkladnou analýzu životního cyklu vývoje softwaru.
5 Povinné 8 Doporučené 5 Volitelné
Název Popis
Čas zahájení
EventTime
Přesné časové razítko udávající, kdy došlo ke konkrétní činnosti nebo události.
Popis

Tento atribut uvádí datum a čas zaznamenání každé činnosti v životním cyklu vývoje. Je nezbytný pro chronologické seřazení událostí i pro veškeré časové analýzy.

V process mining se čas zahájení používá k výpočtu doby mezi činnostmi, určení čekání a měření celkové doby cyklu procesu. Je důležitý pro dashboardy, které sledují výkonnost, například analýzu celkové doby cyklu SDLC, i pro výpočet ukazatelů výkonnosti, jako je doba od zahájení kontroly kódu.

Proč je to důležité

Toto časové razítko je nezbytné pro správné seřazení událostí a výpočet všech ukazatelů výkonnosti, včetně doby cyklu, trvání činností a čekání.

Kde data získat

Obvykle se nachází v systémových polích s časovým razítkem, jako jsou „sys_updated_on“ nebo „sys_created_on“ v auditní stopě nebo tabulkách úkolů.

Příklady
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z
Název činnosti
ActivityName
Název konkrétní události v životním cyklu vývoje, například „Zahájení vývoje“ nebo „Provedení kontroly kódu“.
Popis

Tento atribut zaznamenává název každého milníku nebo úkolu dokončeného v životním cyklu vývoje softwaru. Tyto činnosti tvoří jednotlivé kroky procesu od vytvoření až po nasazení.

Analýza pořadí a četnosti těchto činností je hlavním účelem process mining. Umožňuje sestavit mapu procesu, pomáhá odhalit úzká místa mezi kroky a upozorňuje na odchylky od pravidel nebo neefektivní varianty procesu. Definovaná sada činností zahrnuje důležité fáze, jako jsou návrh, vývoj, testování a nasazení.

Proč je to důležité

Určuje kroky v mapě procesu a umožňuje analyzovat jeho průběh, odhalovat úzká místa a hledat odchylky od standardního SDLC.

Kde data získat

Obvykle se určuje mapováním změn stavu, záznamů událostí nebo položek auditní stopy na standardizovaný seznam názvů činností. Například změna pole „state“ na „In Progress“ může odpovídat činnosti „Zahájení vývoje“.

Příklady
Zahájení vývojeCommit kóduDokončení testování QANasazení do produkce
Vývojová položka
DevelopmentItem
Jedinečný identifikátor samostatné pracovní položky, například funkce, chyby nebo úkolu, která prochází životním cyklem vývoje.
Popis

Vývojová položka slouží jako hlavní identifikátor případu a představuje samostatnou sledovanou pracovní položku. Propojuje všechny činnosti od prvotního návrhu a plánování přes vývoj a testování až po nasazení konkrétní položky.

Při analýze process mining je tento atribut základem pro rekonstrukci celého průběhu každé pracovní položky. Umožňuje zobrazit průběh procesu, vypočítat celkovou dobu cyklu a určit varianty procesu pro jednotlivé funkce nebo opravy chyb. Každá událost v záznamu událostí musí být přiřazena k vývojové položce, aby bylo možné sestavit souvislou mapu procesu.

Proč je to důležité

Tento hlavní identifikátor propojuje všechny související vývojové činnosti do jedné instance procesu. Díky tomu lze analyzovat celý životní cyklus každé pracovní položky.

Kde data získat

Tento identifikátor bývá primárním klíčem z tabulek, ve kterých se spravují story, chyby nebo úkoly, například z tabulek „rm_story“, „rm_bug“ nebo „task“ v ServiceNow.

Příklady
STRY0010015BUG0034092TASK0050118
Poslední aktualizace dat
LastDataUpdate
Časové razítko poslední aktualizace dat tohoto záznamu událostí ze zdrojového systému.
Popis

Tento atribut zaznamenává, kdy byla data naposledy získána nebo aktualizována ze ServiceNow DevOps. Vztahuje se k celému datovému souboru, nikoli k jednotlivým událostem.

Časové razítko je důležité pro posouzení aktuálnosti analýzy. Uživatelé díky němu vědí, jak aktuální jsou poznatky o procesu, a mohou plánovat obnovu dat. Zobrazení této informace na dashboardech poskytuje kontext ke všem ukazatelům a vizualizacím, takže rozhodnutí vycházejí z aktuálních dat.

Proč je to důležité

Poskytuje důležitý kontext k aktuálnosti dat, aby uživatelé věděli, jak aktuální je analýza procesu.

Kde data získat

Toto časové razítko se vytvoří a přidá při získávání dat. Zaznamenává čas provedení získání dat.

Příklady
2023-11-15T08:00:00Z
Zdrojový systém
SourceSystem
Určuje systém, ze kterého byla data získána. V tomto případě jde o ServiceNow DevOps.
Popis

Tento atribut určuje zdrojový systém dat událostí. V tomto procesu bude jeho hodnota vždy „ServiceNow DevOps“.

I když se může zdát neměnný, uvedení zdrojového systému je důležité pro správu dat i v prostředích, kde se mohou spojovat data z více systémů, například Jira nebo Azure DevOps. Umožňuje určit původ dat a pomáhá při hledání problémů s jejich kvalitou nebo získáváním.

Proč je to důležité

Zajišťuje dohledatelnost dat a pomáhá zachovat jejich integritu, zejména při integraci dat z více vývojových nástrojů.

Kde data získat

Jde o neměnnou hodnotu, kterou je třeba přidat při získávání a transformaci dat.

Příklady
ServiceNow DevOps
Doba cyklu vývojové položky
DevelopmentItemCycleTime
Celková doba od vytvoření vývojové položky do jejího uzavření nebo nasazení.
Popis

Tento atribut je vypočítaná metrika, která udává celkovou dobu zpracování jedné vývojové položky. Pro každý případ se vypočítá rozdíl mezi časovým razítkem první a poslední aktivity.

Jde o hlavní ukazatel výkonnosti celého procesu SDLC, který přímo podporuje KPI „Průměrná doba cyklu SDLC“. Poskytuje celkový přehled o rychlosti a efektivitě procesu. Sledování této metriky v čase a podle různých hledisek, například priority nebo týmu, pomáhá vyhodnotit dopad iniciativ na zlepšování procesů.

Proč je to důležité

Udává celkovou dobu zpracování pracovní položky. Jde o důležitou metriku pro měření celkové efektivity a rychlosti procesu.

Kde data získat

Ve zdrojovém systému toto pole není. V nástroji process mining se vypočítá pro každý CaseId odečtením nejnižší hodnoty StartTime od nejvyšší hodnoty StartTime.

Příklady
15 dní 4 hodiny3 dny 12 hodin32 dní 8 hodin
Dotčený modul nebo komponenta
ModuleComponentAffected
Konkrétní softwarový modul, aplikace nebo komponenta, které se vývojová položka týká.
Popis

Tento atribut zařazuje vývojovou práci podle části systému, na kterou má dopad. Může jít o konkrétní mikroslužbu, komponentu uživatelského rozhraní nebo backendovou aplikaci.

Rozdělení procesu podle modulu nebo komponenty je důležité pro odhalení úzkých míst v konkrétních částech systému. Dashboard „Přehled úzkých míst podle komponent“ a KPI „Průměrná délka fáze podle komponenty“ využívají tento atribut k určení, zda se u některých částí kódu opakovaně objevují delší vývojové cykly, více přepracování nebo častější selhání nasazení. Díky tomu můžete zaměřit zlepšování procesů tam, kde je nejvíce potřeba.

Proč je to důležité

Umožňuje rozdělit analýzu podle aplikace nebo komponenty a odhalit úzká místa či problémy s kvalitou v konkrétních částech systému.

Kde data získat

Často jde o vlastní pole nebo odkaz na Configuration Management Database (CMDB), který propojuje pracovní položku se záznamem „cmdb_ci“. Podrobnosti najdete v dokumentaci ServiceNow DevOps.

Příklady
Fakturační službaUživatelské rozhraní ověřování uživatelůDatabáze pro reportingAPI Gateway
Jde o přepracování
IsRework
Logická hodnota, která je pravdivá, pokud je aktivita součástí opakovaného cyklu práce, například když se položka po testování vrátí do vývoje.
Popis

Tento odvozený atribut označuje aktivity, které nastaly poté, co se proces vrátil do dřívější fáze. Pokud například u stejné položky následuje aktivita „Zahájení vývoje“ po aktivitě „Dokončení QA testování“, označí se jako přepracování.

Tento příznak je důležitý pro měření a znázornění přepracování. Přímo podporuje dashboard „Analýza toku přepracování a zamítnutí“ a slouží k výpočtu KPI „Míra přepracování po testování“. Analytici mohou události s tímto příznakem snadno filtrovat a zkoumat četnost, příčiny i dopad přepracování na celkovou dobu cyklu.

Proč je to důležité

Příznak usnadňuje měření a analýzu přepracování. Pomáhá hodnotit kvalitu procesu a hledat příčiny opakované práce.

Kde data získat

Tento atribut se vypočítává v nástroji process mining analýzou pořadí aktivit v každém případu, která odhalí návraty v toku procesu.

Příklady
truefalse
Priorita
DevelopmentItemPriority
Úroveň priority vývojové položky, například „High“, „Medium“ nebo „Low“.
Popis

Tento atribut rozděluje vývojové položky podle naléhavosti z obchodního hlediska. Úrovně priority pomáhají týmům zaměřit se na nejdůležitější úkoly a často se používají při řízení SLA a očekávání zainteresovaných stran.

V process mining je priorita důležitým rozměrem pro srovnávací analýzu. Umožňuje filtrovat mapu procesu a zjistit, zda položky s vysokou prioritou postupují rychleji nebo jinou cestou. Je nezbytná pro dashboard a KPI „Doba dodání funkcí s vysokou prioritou“, které pomáhají ověřit, zda se kritické položky skutečně vyřizují přednostně.

Proč je to důležité

Umožňuje filtrovat a porovnávat procesy podle úrovně priority a ověřit, zda se položky s vysokou prioritou zpracovávají rychleji a efektivněji.

Kde data získat

Jde o standardní pole, které se v tabulkách úkolů v ServiceNow často nazývá „priority“.

Příklady
1 - Kritická2 - Vysoká3 - Střední4 - Nízká
Přiřazený vývojář
AssignedDeveloper
Jméno nebo ID vývojáře či uživatele přiřazeného k vývojové položce v době dané činnosti.
Popis

Tento atribut určuje osobu odpovědnou za provedení konkrétního úkolu nebo činnosti. Je proměnlivý a může se měnit při přechodu vývojové položky mezi různými fázemi a týmy.

Atribut je důležitý pro analýzu přidělování zdrojů, pracovního vytížení a předávání práce. Podporuje dashboard „Pracovní vytížení vývojářů a předávání práce“ a KPI „Objem činností na vývojáře“. Sledováním změn tohoto pole lze měřit dobu předávání práce a odhalovat úzká místa ve spolupráci mezi vývojáři nebo mezi týmy vývoje a QA.

Proč je to důležité

Je nezbytný pro analýzu podle zdrojů, včetně rozložení pracovního vytížení, efektivity předávání práce a výkonnosti jednotlivých týmů.

Kde data získat

Tyto informace se obvykle ukládají do pole „assigned_to“ v tabulkách úkolů v ServiceNow.

Příklady
David MillerAnna WilliamsJames Brown
Skupina přiřazení
AssignmentGroup
Tým nebo skupina odpovědná za vývojovou položku v době dané aktivity.
Popis

Tento atribut určuje tým, kterému je pracovní položka přiřazena, například „Vývojáři frontendu“, „Backendové služby“ nebo „Tým QA“. Při postupu práce se položka často předává mezi různými skupinami přiřazení.

Sledování skupiny přiřazení je důležité pro pochopení spolupráce mezi týmy a předávání práce. Pomáhá odhalit systémová zpoždění, ke kterým dochází při přesunu práce z jednoho týmu do druhého. Atribut podporuje analýzu výkonnosti a vytížení jednotlivých týmů i určení týmů, které představují úzké místo v celkovém toku práce.

Proč je to důležité

Sleduje, který tým za práci odpovídá. Umožňuje analyzovat výkonnost a vytížení týmů, vyvažovat pracovní zátěž a posoudit efektivitu předávání práce mezi týmy.

Kde data získat

Tyto údaje jsou uloženy ve standardním poli „assignment_group“ v tabulkách úloh v ServiceNow.

Příklady
Platformové inženýrstvíTým mobilní aplikaceZajištění kvalityDevOps
Stav vývojové položky
DevelopmentItemState
Stav vývojové položky v době události, například „Otevřeno“, „Probíhá“ nebo „Uzavřeno“.
Popis

Tento atribut zachycuje oficiální stav vývojové položky v ServiceNow. Aktivity představují odvozené kroky procesu, zatímco stav označuje formální fázi položky ve workflow systému.

Stav často slouží jako zdroj pro odvození aktivit. Lze ho použít k ověření dat i k vytvoření jednoduššího přehledu procesu na vysoké úrovni. Analýza času stráveného v jednotlivých stavech například ukáže úzká místa jinak než analýza času mezi aktivitami. Stav také pomáhá najít položky, na kterých se práce zastavila, nebo které už byly vyřešeny.

Proč je to důležité

Uvádí oficiální stav pracovní položky v systému. Často slouží jako zdroj pro odvození aktivit a lze ho využít k ověření dat i k analýze stavů na vysoké úrovni.

Kde data získat

Jde o standardní pole, obvykle nazvané „state“ nebo „stage“, v tabulkách úloh v ServiceNow.

Příklady
Čeká na vyřízeníProbíháPřipraveno k testováníUzavřeno, dokončeno
Typ vývojové položky
DevelopmentItemType
Zařazení pracovní položky, například „Funkce“, „Chyba“, „Technický dluh“ nebo „Úkol“.
Popis

Tento atribut rozlišuje různé druhy práce v procesu SDLC. Postup při opravě kritické chyby může být například jiný a rychlejší než při vývoji nové funkce.

Analýza procesu podle typu pracovní položky přináší podrobnější pohled na výkonnost. Pomáhá odpovědět na otázky jako: „Vyžadují chyby více přepracování než nové funkce?“ nebo „Je doba cyklu při snižování technického dluhu přijatelná?“ Toto rozdělení poskytuje přesnější přehled než jednotný pohled na celý proces.

Proč je to důležité

Rozlišuje různé druhy práce, například funkce a chyby, které mohou mít odlišný průběh, priority i očekávanou dobu trvání.

Kde data získat

Typ lze určit podle zdrojové tabulky záznamu (například „rm_story“ nebo „rm_bug“) nebo z pole „type“ v obecné tabulce úloh.

Příklady
FunkceChybaÚkolPrůzkumný úkol
Čas dokončení
EventEndTime
Přesné časové razítko udávající, kdy byla činnost dokončena. U okamžitých událostí se shoduje s časem zahájení.
Popis

Tento atribut uvádí datum a čas dokončení každé činnosti v životním cyklu vývoje. Hodí se zejména u činností s měřitelnou délkou, například „Provedení kontroly kódu“ nebo „Testování QA“.

V process mining umožňuje čas zahájení i dokončení přesně vypočítat dobu zpracování činnosti a odlišit ji od čekání mezi činnostmi. Díky tomu lze určit, zda prodlevy způsobují dlouhé úkoly, nebo čekání na zdroje. U událostí považovaných za okamžité, například „Spuštění buildu“, může být čas dokončení stejný jako čas zahájení.

Proč je to důležité

Umožňuje přesně vypočítat dobu zpracování činnosti a odlišit čas strávený prací od čekání.

Kde data získat

Tuto hodnotu může být nutné odvodit. Může jít o čas zahájení následující činnosti nebo o hodnotu ze samostatného pole „end date“, pokud je ve zdrojovém systému k dispozici.

Příklady
2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z
Důvod přepracování
ReworkReason
Zařazení nebo popis důvodu, proč bylo nutné vývojovou položku po testování přepracovat.
Popis

Pokud položka neprojde QA nebo UAT, tento atribut zaznamená důvod. Může jít o konkrétní kategorii chyby, nesprávné pochopení požadavků nebo problém s prostředím.

Tyto údaje poskytují důležitý kontext pro dashboard „Analýza toku přepracování a zamítnutí“. Analytici tak zjistí nejen to, že k přepracování došlo, ale také proč. Mohou pak cíleně zlepšit například definici požadavků, jednotkové testování nebo stabilitu testovacích prostředí a snížit celkovou míru přepracování.

Proč je to důležité

Ukazuje, proč k přepracování dochází, a umožňuje cíleně zlepšovat proces, zvyšovat kvalitu a omezovat opakované cykly práce.

Kde data získat

Důvod může být zaznamenán v poli „close_notes“ při neúspěšném testu nebo ve vlastním poli „rework_reason“. Podrobnosti najdete v dokumentaci ServiceNow DevOps.

Příklady
Nesprávně pochopený požadavekRegresní chybaNeúspěšný výkonnostní testProblém s UI/UX
ID commitu
CommitId
Jedinečný identifikátor commitu zdrojového kódu souvisejícího s vývojovou prací.
Popis

Tento atribut přímo propojuje vývojovou položku s konkrétní změnou kódu v úložišti zdrojového kódu, například v Gitu. Zaznamenává se při aktivitě „Commit kódu“.

V process mining obohacuje ID commitu analýzu propojením procesních a vývojových dat. Analytici mohou dohledat, která změna kódu vedla k problematickému nasazení, nebo porovnat složitost kódu s délkou vývojových cyklů. Tím získají podrobnější technický pohled na příčiny problémů.

Proč je to důležité

Propojuje událost procesu s konkrétní změnou kódu. Umožňuje podrobněji hledat příčiny problémů porovnáním procesních metrik s údaji o kódu.

Kde data získat

Údaj zaznamenávají integrace ServiceNow DevOps se systémy pro správu zdrojového kódu, například Git nebo SVN. Data jsou uložena v souvisejících tabulkách propojených s vývojovou položkou.

Příklady
a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f
Plánovaná verze vydání
PlannedReleaseVersion
Cílové vydání nebo verze softwaru, ve které má být vývojová položka dodána.
Popis

Tento atribut propojuje vývojovou položku s konkrétním plánovaným vydáním, například „Verze 2.3“ nebo „Vydání Q4 2023“. Je důležitý pro řízení projektů a plánování vydání.

V process mining je tento atribut nezbytný pro dashboard „Sledování dodržení plánu vydání“. Porovnáním skutečných a plánovaných dat dokončení mohou týmy měřit dodržení harmonogramu, určit položky, u kterých hrozí, že se do vydání nestihnou, a analyzovat příčiny zpoždění. Atribut přímo propojuje podrobný vývojový proces s cíli na úrovni celé organizace.

Proč je to důležité

Propojuje vývojovou práci s konkrétními vydáními. Umožňuje analyzovat dodržení harmonogramu a dopad zpoždění procesu na termíny vydání.

Kde data získat

Tyto údaje jsou obvykle uloženy v poli „release“ nebo „planned_release“, které často odkazuje na tabulku správy vydání v ServiceNow. Podrobnosti najdete v dokumentaci ServiceNow DevOps.

Příklady
v3.4.1Vydání Q1 2024Spuštění projektu Phoenix
Stav nasazení
DeploymentStatus
Udává výsledek nasazení, obvykle „Úspěšné“ nebo „Neúspěšné“.
Popis

Tento atribut zaznamenává výsledek nasazení do konkrétního prostředí. Pomáhá posoudit spolehlivost a stabilitu procesu vydávání softwaru.

Atribut je nezbytný pro dashboard „Trendy úspěšných a neúspěšných nasazení“ a KPI „Míra neúspěšných nasazení“. Analýza četnosti a trendů neúspěšných nasazení pomáhá organizacím odhalit příčiny problémů v testování, infrastruktuře nebo koordinaci vydání. Díky tomu mohou zaměřit úsilí na zvýšení kvality a spolehlivosti dodávek softwaru.

Proč je to důležité

Přímo měří úspěšnost nasazení. Je nezbytný pro výpočet míry neúspěšných nasazení a analýzu stability vydávání.

Kde data získat

Tento stav se obvykle zaznamenává v úlohách pro sledování nasazení nebo v záznamech o spuštění CI/CD pipeline integrovaných se ServiceNow DevOps.

Příklady
ÚspěšnéNeúspěšnéDokončeno s upozorněními
Povinné Doporučené Volitelné

Aktivity v životním cyklu vývoje softwaru

Jde o důležité kroky a milníky procesu, které zachyťte v záznamu událostí, abyste mohli proces přesně odhalit a optimalizovat.
7 Doporučené 9 Volitelné
Aktivita Popis
Dokončení testování QA
Označuje, že tým Quality Assurance úspěšně dokončil testování vývojové položky. Obvykle se odvozuje z přechodu položky z testovací fáze do stavu jako „Ready for UAT“ nebo „Done“.
Proč je to důležité

Tento milník označuje dokončení důležité kontrolní fáze kvality. Je podmínkou pro další kroky, například User Acceptance Testing nebo přípravu vydání.

Kde data získat

Odvozuje se z časového razítka změny stavu z testovacího stavu, například „In QA“, na stav po testování, například „Ready for UAT“ nebo „Resolved“.

Zachycení

Vychází z časového razítka změny stavu z „Testing“ na následující stav.

Typ události inferred
Nasazení do produkce
Tato událost označuje úspěšné dokončení nasazení do produkčního prostředí. ServiceNow DevOps ji zaznamenává přímo, když nástroj CI/CD ohlásí úspěšné dokončení pipeline.
Proč je to důležité

Jde o hlavní koncovou událost úspěšného procesu SDLC. Uzavírá tok hodnoty a je nezbytná pro výpočet celkové doby cyklu.

Kde data získat

Zaznamená se z hodnoty „completion_status“ záznamu Pipeline Execution [sn_devops_pipeline_execution] nebo souvisejícího záznamu Stage Execution Run. Událost označuje stav „Success“ v čase dokončení.

Zachycení

Zaznamená se při úspěšném dokončení pipeline pro nasazení do produkce.

Typ události explicit
Neúspěšné nasazení
Označuje neúspěšný pokus o nasazení vývojové položky do produkce. ServiceNow DevOps tuto událost zaznamenává přímo, když pipeline CI/CD ohlásí chybu.
Proč je to důležité

Jde o důležitou koncovou událost označující neúspěch. Analýza její četnosti a příčin pomáhá zvýšit stabilitu vydávání verzí a snížit míru neúspěšných nasazení.

Kde data získat

Zaznamená se z hodnoty „completion_status“ záznamu Pipeline Execution [sn_devops_pipeline_execution]. Událost označuje stav „Failed“ v čase dokončení.

Zachycení

Zaznamená se, když pipeline pro nasazení do produkce ohlásí neúspěch.

Typ události explicit
Provedení kontroly kódu
Tato činnost označuje dokončení vzájemné kontroly kódu, obvykle spojené s pull requestem nebo merge requestem. Událost lze zaznamenat přímo prostřednictvím integrací DevOps nebo odvodit ze změn stavu souvisejících záznamů.
Proč je to důležité

Jde o důležitou kontrolní fázi kvality. Analýza její délky pomáhá odhalit úzká místa při kontrole kódu, která často způsobují prodlevy v SDLC.

Kde data získat

Událost lze zaznamenat při stavu „Merged“ nebo „Completed“ záznamu Pull Request v integraci Git v ServiceNow. Lze ji také odvodit ze změny stavu vývojové položky na „Code Review Complete“.

Zachycení

Zaznamená se při sloučení Pull Request propojeného s pracovní položkou.

Typ události explicit
Schválení UAT
Označuje formální schválení vývojové položky zástupci firmy po User Acceptance Testing. Jde o důležitý milník, který se odvozuje ze změny stavu, například z „In UAT“ na „Ready for Release“ nebo „Approved“.
Proč je to důležité

Jde o poslední schválení ze strany firmy před uvolněním položky k nasazení do produkce. Je to důležitý kontrolní bod pro kvalitu a řízení.

Kde data získat

Odvozuje se ze změny stavu záznamu vývojové položky, která označuje úspěšné dokončení UAT. Zaznamenává se v historii činností položky.

Zachycení

Odvozuje se ze změny stavu z „UAT“ na schválený stav nebo stav připravený k vydání.

Typ události inferred
Vytvoření vývojové položky
Tato činnost označuje vytvoření nové vývojové položky, například story, chyby nebo epiku, v ServiceNow. Událost se obvykle zaznamená při vložení nového záznamu do příslušné tabulky, například Story [rm_story].
Proč je to důležité

Jde o hlavní počáteční událost procesu SDLC. Umožňuje měřit celkovou dobu cyklu od začátku do konce a sledovat příjem nových požadavků.

Kde data získat

Událost se zaznamenává do tabulky sys_audit nebo sys_history_line při vytvoření záznamu v tabulce související s vývojem, například Story [rm_story], Epic [rm_epic] nebo Defect [rm_defect]. Čas vytvoření bývá uložen přímo v záznamu.

Zachycení

Zaznamená se časové razítko vytvoření záznamu vývojové položky.

Typ události explicit
Zahájení vývoje
Tato činnost označuje okamžik, kdy vývojář začne programovat nebo jinak realizovat vývojovou položku. Obvykle se odvozuje ze změny jejího stavu na „In Progress“, „Development“ nebo „Coding“.
Proč je to důležité

Tento důležitý milník označuje začátek tvorby, která přináší hodnotu. Je nezbytný pro měření doby od zahájení práce vývojáře a délky cyklu kontroly kódu.

Kde data získat

Odvozuje se z časového razítka změny pole „State“ v záznamu vývojové položky, například Story [rm_story], na „In Progress“ nebo odpovídající stav.

Zachycení

Vychází z časového razítka změny stavu na „In Progress“ nebo podobnou hodnotu.

Typ události inferred
Commit kódu
Označuje okamžik, kdy vývojář odešle kód do repozitáře systému pro správu verzí propojeného s vývojovou položkou. ServiceNow DevOps tyto události zaznamenává přímo z integrovaných nástrojů SCM, například Git nebo GitHub.
Proč je to důležité

Sledování commitů poskytuje podrobný přehled o postupu vývoje a četnosti činností. Pomáhá propojit konkrétní změny kódu s nadřazenou vývojovou položkou.

Kde data získat

Událost se zaznamenává přímo do tabulky ServiceNow DevOps Commits [sn_devops_commit], kterou plní webhooky z integrovaného systému pro správu zdrojového kódu.

Zachycení

Zaznamená se při přijetí webhooku o commitu z nástroje SCM.

Typ události explicit
Příprava k vydání
Tato činnost označuje, že vývojová položka prošla všemi kontrolními fázemi kvality a je zařazena do konkrétního vydání. Lze ji odvodit z propojení položky se záznamem Release nebo ze změny jejího stavu na „Ready for Deployment“.
Proč je to důležité

Tento krok označuje technické i funkční dokončení položky. Doba strávená v tomto stavu může představovat čekání na plánované okno nasazení.

Kde data získat

Odvozuje se ze změny pole „State“ na „Ready for Release“ nebo ze sledování vyplnění či aktualizace pole „Release“ v záznamu vývojové položky.

Zachycení

Odvozuje se ze změny stavu nebo propojení se záznamem Release.

Typ události inferred
Spuštění buildu
Tato událost označuje začátek buildu v pipeline CI/CD, který často spouští commit kódu. ServiceNow DevOps zaznamenává spuštění pipeline a propojuje ho s původními vývojovými položkami.
Proč je to důležité

Tato činnost propojuje vývoj s automatizovaným testováním nebo nasazením. Analýza doby mezi commitem a zahájením buildu může odhalit prodlevy v procesu CI/CD.

Kde data získat

Událost se zaznamenává přímo do tabulky Pipeline Execution [sn_devops_pipeline_execution] při zahájení buildu v integrovaném nástroji CI/CD, například Jenkins nebo Azure DevOps.

Zachycení

Zaznamená se čas zahájení záznamu v tabulce Pipeline Execution.

Typ události explicit
Zahájení nasazení do produkce
Tato činnost označuje spuštění pipeline pro nasazení do produkčního prostředí. ServiceNow DevOps ji zaznamenává jako samostatnou událost při zahájení provádění produkční fáze pipeline CI/CD.
Proč je to důležité

Označuje začátek závěrečné a často nejdůležitější fáze životního cyklu. Sledování této fáze pomáhá analyzovat délku nasazení a odhalit příležitosti k automatizaci.

Kde data získat

Zaznamenává se přímo do tabulky Stage Execution Run [sn_devops_stage_execution] po odfiltrování fází souvisejících s produkčním prostředím.

Zachycení

Zaznamená se čas zahájení produkční fáze nasazení v rámci Pipeline Execution.

Typ události explicit
Zahájení návrhu
Označuje fázi, ve které se připravuje technický návrh nebo architektura řešení vývojové položky. Obvykle se odvozuje od změny pole stavu v záznamu vývojové položky na hodnotu jako „Design“ nebo „Solutioning“.
Proč je to důležité

Analýza délky fáze návrhu pomáhá odhalit úzká místa při převodu požadavků do návrhu řešení, ještě než začne vývoj.

Kde data získat

Odvozuje se ze změn stavu záznamu vývojové položky, například Story [rm_story]. Hledejte změny pole „State“ nebo vlastního pole „Stage“ na hodnotu související s návrhem.

Zachycení

Odvozuje se ze změny stavu na „Design“ nebo podobnou hodnotu.

Typ události inferred
Zahájení testování QA
Označuje začátek formální fáze testování Quality Assurance. Téměř vždy se odvozuje ze změny stavu vývojové položky na hodnotu jako „In QA“, „Testing“ nebo „Ready for Test“.
Proč je to důležité

Tato činnost označuje předání práce z vývoje týmu QA. Umožňuje měřit délku testovací fáze a odhalit úzká místa způsobená nedostatečnou kapacitou testování.

Kde data získat

Odvozuje se z časového razítka změny pole „State“ v záznamu vývojové položky, například Story nebo Defect, na stav specifický pro QA.

Zachycení

Vychází z časového razítka změny stavu na „Testing“ nebo odpovídající hodnotu.

Typ události inferred
Zahájení UAT
Označuje začátek User Acceptance Testing, při kterém zástupci firmy ověřují funkčnost. Událost se odvozuje ze změny stavu na „UAT“, „In UAT“ nebo „User Acceptance Testing“.
Proč je to důležité

Tato fáze je důležitá pro ověření, že vyvinutá funkce splňuje obchodní požadavky. Analýza její délky může odhalit problémy se zapojením uživatelů nebo nesoulad s požadavky.

Kde data získat

Odvozuje se ze změny stavu záznamu vývojové položky. Datový model stavů zákazníka musí obsahovat samostatný stav pro UAT.

Zachycení

Odvozuje se ze změny stavu na „UAT“.

Typ události inferred
Zjištění nutnosti předělávky
Označuje zjištění problému při testování, kvůli kterému se položka vrací do vývoje. Událost se odvozuje ze zpětného posunu v procesu, například ze změny stavu z „In QA“ zpět na „In Progress“.
Proč je to důležité

Sledování předělávek je důležité pro pochopení problémů s kvalitou a neefektivních postupů. Častý výskyt této činnosti může ukazovat na nedostatky ve vývoji nebo nejasné požadavky.

Kde data získat

Odvozuje se z analýzy historie pole „State“ v tabulce sys_audit nebo sys_history_line. Změna z pozdějšího stavu, například „Testing“, na dřívější, například „In Progress“, označuje předělávku.

Zachycení

Odvozuje se ze zpětné změny stavu, například „Testing“ -> „In Progress“.

Typ události inferred
Zrušení vývojové položky
Označuje ukončení vývojové položky před dokončením. Jde o alternativní koncový stav, který se obvykle odvozuje z nastavení stavu položky na „Cancelled“ nebo „Closed Incomplete“.
Proč je to důležité

Sledování zrušených položek pomáhá odhalit zbytečně vynaloženou práci a pochopit důvody změn rozsahu nebo změn priorit. Poskytuje úplnější přehled o možných výsledcích procesu.

Kde data získat

Odvozuje se z časového razítka změny pole „State“ v záznamu vývojové položky na koncový stav, který neoznačuje dokončení, například „Cancelled“.

Zachycení

Odvozuje se ze změny stavu na „Cancelled“ nebo odpovídající koncový stav.

Typ události inferred
Doporučené Volitelné

Návody na získání dat

Jak získat data ze ServiceNow DevOps

Chcete začít?

Začněte zlepšovat životní cyklus vývoje softwaru ještě dnes. Pomocí této šablony dat odhalte skryté neefektivity a podpořte průběžné zlepšování.

Nečekejte a začněte zlepšovat životní cyklus vývoje softwaru ještě dnes

Najděte neefektivní postupy a zkraťte cyklus SDLC o 30 % nebo více.

Začněte zkušební verzi zdarma

Bez platební karty. Začněte s optimalizací ještě dnes.