Šablona dat pro životní cyklus vývoje softwaru
Šablona dat pro životní cyklus vývoje softwaru
- Doporučené atributy ke sběru
- Důležité aktivity ke sledování
- Návod na získání dat ze ServiceNow DevOps
Atributy životního cyklu vývoje softwaru
| 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 | |||
Aktivity v životním cyklu vývoje softwaru
| 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 | |||
Návody na získání dat
Kroky
- Seznamte se s modelem stavů: Než vytvoříte sestavy, zdokumentujte konkrétní hodnoty v poli stavu vývojové položky, například v tabulce Story
[rm_story]nebo Defect[rm_defect], které odpovídají požadovaným aktivitám. Hodnotu stavu „In Progress“ můžete například namapovat na aktivitu „Development Started“. - Přejděte k vytváření sestavy: Přihlaste se do své instance ServiceNow. V navigátoru filtrů přejděte na
Reports > View / Runa klikněte na tlačítkoCreate a report. - Vytvořte sestavu změn stavů: Nejprve vytvořte sestavu, která zachytí aktivity vyvolané změnou stavu. Nastavte ji takto:
- Název sestavy:
ProcessMind - State Change Events - Typ zdroje:
Table - Tabulka:
Audit [sys_audit] - Typ:
List - Nastavení sloupců: Přidejte
Document key,Created on,Table name,Field name,Old valueaNew value. - Filtr: Nastavte
Table namena jednu z tabulek vývojových položek, napříkladStory, aField namena pole stavu, napříkladState. V poliCreated onnastavte filtr podle požadovaného období.
- Název sestavy:
- Vytvořte sestavu vytvoření položek: Vytvořte novou sestavu pro počáteční událost vytvoření.
- Název sestavy:
ProcessMind - Item Creation Events - Typ zdroje:
Table - Tabulka:
Story [rm_story]nebo hlavní tabulka vývojových položek - Typ:
List - Nastavení sloupců: Přidejte sloupce s požadovanými atributy, například
Number,Created on,Assigned to,PriorityaState. - Filtr: Nastavte filtr podle data v poli
Created on.
- Název sestavy:
- Vytvořte sestavu potvrzení změn kódu: Vytvořte sestavu pro explicitní události DevOps související s potvrzením změn.
- Název sestavy:
ProcessMind - Commit Events - Typ zdroje:
Table - Tabulka:
Commit [sn_devops_commit] - Typ:
List - Nastavení sloupců: Přidejte sloupce jako
Work item,Commit timeaAuthor. - Filtr: Nastavte filtr podle data v poli
Commit time.
- Název sestavy:
- Vytvořte sestavy sestavení a nasazení: Zopakujte postup z předchozího kroku pro tabulky
Build [sn_devops_build]aDeployment [sn_devops_deployment]. Tyto tabulky obsahují záznamy o aktivitáchBuild Triggered,Deployment to Production Started,Deployed to ProductionaDeployment Failed. - Exportujte všechny sestavy: Spusťte jednotlivé vytvořené sestavy. V každé klikněte na ikonu kontextové nabídky, tedy tři tečky nebo šipku dolů, a vyberte
Export > CSVneboExport > Excel. Uložte všechny soubory. - Spojte a transformujte data: Otevřete exportované soubory v tabulkovém procesoru nebo použijte nástroj pro přípravu dat. Ručně spojte data ze všech souborů do jednoho listu. Vytvořte požadované sloupce záznamu událostí (
DevelopmentItem,ActivityName,EventTimeatd.) a namapujte do nich data ze zdrojových sloupců. Například namapujteDocument keyze sestavy auditu aNumberze sestavy Story do sloupceDevelopmentItem. - Namapujte názvy aktivit: Vytvořte sloupec
ActivityNamepřevodem zdrojových dat. U sestavy změn stavů použijte zdokumentovaný model stavů a namapujte položkyNew valuena názvy aktivit, například stav „Testing“ na „QA Testing Started“. U ostatních sestav přiřaďte každému řádku pevný název aktivity, například všechny řádky z exportu potvrzení změn označte jako „Code Committed“. - Dokončete a uložte soubor: Přidejte sloupce
SourceSystemaLastDataUpdatese statickými hodnotami pro všechny řádky. Ověřte, že jsou všechna časová razítka ve stejném formátu. Výsledný spojený soubor uložte jako jedno CSV. Poté ho můžete nahrát do ProcessMind.
Konfigurace
- Požadované tabulky: Pro získání dat jsou potřeba především tabulka
Audit [sys_audit]pro odvozené události, příslušné tabulky vývojových položek (napříkladStory [rm_story],Defect [rm_defect]) a hlavní tabulky ServiceNow DevOps:Commit [sn_devops_commit],Build [sn_devops_build]aDeployment [sn_devops_deployment]. - Důležité filtry: Nejdůležitější je filtr časového období, který použijte jednotně ve všech reportech na poli s časovým údajem, například
Created on,Commit timeneboStart time. V reportusys_auditje nezbytné filtrovat podleTable name(napříkladrm_story) aField name(napříkladstate), aby se zahrnuly pouze relevantní změny stavů. - Doporučené období: Doporučujeme získat data za 3 až 6 měsíců. Získáte tak reprezentativní datovou sadu, aniž byste zatížili systém. U větších systémů zvažte získávání dat po jednotlivých měsících.
- Definice modelu stavů: Musíte znát model stavů pracovních položek ve své organizaci. Je to nutné pro správné namapování hodnot stavů z tabulky
sys_auditna odpovídající obchodní aktivity, například „Zahájení testování QA“ nebo „Schválení UAT“. - Předpoklady: Uživatelé, kteří data získávají, potřebují roli
report_usernebo odpovídající oprávnění k vytváření a spouštění reportů. Potřebují také přístup pro čtení k výše uvedeným tabulkám DevOps a vývoje aplikací. Musí být nainstalován plugin ServiceNow DevOps a aktivně propojen s nástroji SCM a CI/CD.
Ukázkový dotaz sql
/*
This extraction method uses the ServiceNow report builder UI. The following sections describe the configuration for each report that must be created and exported.
The exported data must then be manually combined and transformed into a single event log file.
*/
---
-- REPORT 1: Item Creation Events
---
Report_Name: ProcessMind - Item Creation Events
Source_Table: rm_story
Report_Type: List
Columns:
- Number (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- 'Development Item Created' (create a formula or static column for ActivityName)
- Assigned to (maps to AssignedDeveloper)
- Priority (maps to DevelopmentItemPriority)
- State (maps to DevelopmentItemState)
- cmdb_ci (maps to ModuleComponentAffected)
- Type (maps to DevelopmentItemType)
- Assignment group (maps to AssignmentGroup)
Filters:
- sys_created_on ON Last 6 months
---
-- REPORT 2: Inferred State Change Events
---
Report_Name: ProcessMind - State Change Events
Source_Table: sys_audit
Report_Type: List
Columns:
- documentkey (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- newvalue (maps to ActivityName, requires translation)
- user (maps to AssignedDeveloper)
ActivityName_Mapping_Logic (Example):
- WHEN newvalue IS '[Your Design State]' THEN 'Design Started'
- WHEN newvalue IS '[Your In Progress State]' THEN 'Development Started'
- WHEN newvalue IS '[Your QA State]' THEN 'QA Testing Started'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your In Progress State]' THEN 'Rework Identified'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your UAT State]' THEN 'QA Testing Completed'
- WHEN newvalue IS '[Your UAT State]' THEN 'UAT Started'
- WHEN newvalue IS '[Your UAT Approved State]' THEN 'UAT Approved'
- WHEN newvalue IS '[Your Release Ready State]' THEN 'Prepared For Release'
- WHEN newvalue IS '[Your Cancelled State]' THEN 'Development Item Cancelled'
Filters:
- tablename = 'rm_story'
- fieldname = 'state'
- sys_created_on ON Last 6 months
---
-- REPORT 3: Code Commit Events
---
Report_Name: ProcessMind - Commit Events
Source_Table: sn_devops_commit
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- commit_time (maps to EventTime)
- 'Code Committed' (create a formula or static column for ActivityName)
- author.name (maps to AssignedDeveloper)
Filters:
- commit_time ON Last 6 months
---
-- REPORT 4: Build Events
---
Report_Name: ProcessMind - Build Events
Source_Table: sn_devops_build
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime)
- 'Build Triggered' (create a formula or static column for ActivityName)
Filters:
- start_time ON Last 6 months
---
-- REPORT 5: Deployment Events
---
Report_Name: ProcessMind - Deployment Events
Source_Table: sn_devops_deployment
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime for 'Started' activities)
- end_time (maps to EventTime for 'Completed' or 'Failed' activities)
- state (maps to ActivityName, requires translation)
ActivityName_Mapping_Logic:
- WHEN state IS 'in_progress' THEN 'Deployment to Production Started'
- WHEN state IS 'successful' THEN 'Deployed to Production'
- WHEN state IS 'failed' THEN 'Deployment Failed'
Filters:
- start_time ON Last 6 months
- [Filter for production deployments based on your environment configuration]
---
-- Additional events like 'Code Review Performed' may require a separate report
-- on a table like `sn_devops_pull_request` if available and configured.
--- Kroky
- Předpoklady: Zajistěte síťový přístup ke své instanci ServiceNow a vyžádejte si vyhrazený servisní účet s oprávněním ke čtení (dobrým začátkem jsou role
itilasn_devops.viewer). Tento účet potřebuje přístup k tabulkám, jako jsourm_story,sys_audita schémasn_devops_*. - Nainstalujte ODBC ovladač ServiceNow: Stáhněte si z portálu podpory ServiceNow příslušný ODBC ovladač pro svůj operační systém. Postupujte podle pokynů k instalaci.
- Nastavte DSN: Na počítači, ze kterého budete spouštět dotaz, vytvořte nový systémový DSN (Data Source Name). Ve správci zdrojů dat ODBC přidejte ovladač ServiceNow a zadejte adresu URL instance (například
yourinstance.service-now.com), uživatelské jméno a heslo. - Připojte se pomocí SQL klienta: K připojení k ServiceNow přes nastavený DSN použijte SQL klienta, například DBeaver nebo Microsoft SQL Server Management Studio (prostřednictvím propojeného serveru), případně skriptovací jazyk, jako je Python s knihovnou ODBC.
- Určete model stavů: Před spuštěním dotazu zjistěte přesné hodnoty, které vaše organizace používá v poli
statetabulek vývojových položek (napříkladrm_story,rm_defect). V ukázkovém dotazu jsou běžné hodnoty jako „In Progress“ nebo „In QA“. Nahraďte je hodnotami používanými ve vaší organizaci. - Upravte SQL dotaz: Zkopírujte dodaný SQL dotaz do klienta. Upravte zástupné hodnoty na začátku dotazu, včetně počátečního data pro získání dat a konkrétních hodnot stavů odpovídajících jednotlivým aktivitám životního cyklu vývoje.
- Spusťte dotaz: Spusťte celý SQL dotaz nad databází ServiceNow prostřednictvím připojení ODBC. V závislosti na časovém období a objemu dat to může trvat déle.
- Zkontrolujte data: Po dokončení dotazu krátce zkontrolujte vrácenou datovou sadu. Ověřte, že obsahuje různé aktivity a že sloupce jako
DevelopmentItem,ActivityNameaEventTimemají očekávané hodnoty. - Exportujte do CSV: Exportujte celý výsledek do souboru CSV. Použijte kódování UTF-8 a zkontrolujte, že záhlaví sloupců odpovídají názvům atributů požadovaným ProcessMind, například
DevelopmentItem,ActivityNameaEventTime. - Připravte soubor k nahrání: Zkontrolujte, že na konci výsledného souboru CSV nejsou prázdné řádky a že formát dat v polích
EventTimeaLastDataUpdateje jednotný a ProcessMind ho podporuje (napříkladYYYY-MM-DD HH:MM:SS).
Konfigurace
- Předpoklady: Potřebujete přístup k instanci ServiceNow se zapnutým modulem DevOps a vyhrazený uživatelský účet s oprávněním ke čtení požadovaných tabulek. Na klientském počítači musí být nainstalován a nastaven ODBC ovladač ServiceNow.
- Nastavení ODBC ovladače: K připojení potřebujete adresu URL instance, uživatelské jméno a heslo nebo token OAuth. Před spuštěním složitých dotazů je nezbytné otestovat připojení DSN.
- Filtr časového období: Dodaný dotaz obsahuje zástupnou podmínku
s.sys_created_on >= '2023-01-01', která omezuje objem získaných dat. Doporučujeme získat data za vymezené období, například za posledních 6 až 12 měsíců, aby dotaz doběhl v přijatelném čase. - Úprava modelu stavů: Přesnost odvozených událostí závisí výhradně na modelu stavů. Nahraďte zástupné hodnoty stavů (například
[Your 'In Progress' State Value],[Your 'In QA' State Value]) přesnými hodnotami nastavenými v ServiceNow. Rozlišují se malá a velká písmena. - Tabulky pracovních položek: Dotaz je připravený pro tabulku Story (
rm_story). Pokud vaše organizace používá také Defects (rm_defect), Enhancements (rm_enhancement) nebo jiné typy úkolů, přidejte je pomocíUNION ALLdo počátečního společného tabulkového výrazu (CTE)DevItems. - Výkon: Přímé dotazy do produkční instance ServiceNow mohou ovlivnit její výkon. Rozsáhlá data získávejte mimo špičku. U velmi velkých datových sad zvažte postupné získávání dat podle pole
sys_updated_on.
Ukázkový dotaz sql
WITH DevItems AS (
-- This CTE selects the base set of development items to analyze.
-- Add other tables like rm_defect or rm_enhancement here using UNION ALL if needed.
SELECT
s.sys_id,
s.number,
s.sys_created_on,
s.sys_updated_on,
s.assigned_to,
s.priority,
s.state,
s.cmdb_ci, -- Module/Component Affected
s.sys_class_name, -- Development Item Type
s.assignment_group,
DATEDIFF(second, s.sys_created_on, s.closed_at) AS cycle_time_seconds
FROM rm_story s
WHERE s.sys_created_on >= '2023-01-01' -- *** Placeholder: Set your desired start date ***
),
StateChanges AS (
-- This CTE unnests the audit trail for state changes, which are used for inferred activities.
SELECT
a.documentkey AS item_sys_id,
a.sys_created_on AS change_time,
a.oldvalue,
a.newvalue,
-- *** Placeholder: Define the numeric order of your states to detect rework. Adjust values and names. ***
CASE a.oldvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS old_state_order,
CASE a.newvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS new_state_order
FROM sys_audit a
WHERE a.tablename = 'rm_story' AND a.fieldname = 'state'
)
-- 1. Development Item Created
SELECT
i.number AS DevelopmentItem,
'Development Item Created' AS ActivityName,
i.sys_created_on AS EventTime,
'ServiceNow DevOps' AS SourceSystem,
GETDATE() AS LastDataUpdate,
us.name AS AssignedDeveloper,
i.priority AS DevelopmentItemPriority,
i.state AS DevelopmentItemState,
ci.name AS ModuleComponentAffected,
i.sys_class_name AS DevelopmentItemType,
grp.name AS AssignmentGroup,
i.cycle_time_seconds AS DevelopmentItemCycleTime,
CAST(0 AS BIT) AS IsRework
FROM DevItems i
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id
LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id
LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 2. Design Started
SELECT i.number, 'Design Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Design'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 3. Development Started
SELECT i.number, 'Development Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In Progress'' State Value]' AND sc.old_state_order < 3 -- *** Placeholder: Adjust state value and order ***
UNION ALL
-- 4. Code Committed
SELECT i.number, 'Code Committed', c.committed_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_commit c JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 5. Build Triggered
SELECT i.number, 'Build Triggered', b.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_build b JOIN sn_devops_commit_build cb ON b.sys_id = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 6. Code Review Performed
SELECT i.number, 'Code Review Performed', pr.closed_at, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_pull_request pr JOIN DevItems i ON pr.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE pr.state = 'merged' -- Or 'closed', depending on process
UNION ALL
-- 7. QA Testing Started
SELECT i.number, 'QA Testing Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In QA'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 8. Rework Identified
SELECT i.number, 'Rework Identified', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(1 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.new_state_order < sc.old_state_order AND sc.new_state_order > 1 -- Moved to an earlier state
UNION ALL
-- 9. QA Testing Completed
SELECT i.number, 'QA Testing Completed', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In QA'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 10. UAT Started
SELECT i.number, 'UAT Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In UAT'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 11. UAT Approved
SELECT i.number, 'UAT Approved', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In UAT'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 12. Prepared For Release
SELECT i.number, 'Prepared For Release', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Ready for Release'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 13. Deployment to Production Started
SELECT i.number, 'Deployment to Production Started', se.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' -- *** Placeholder: Adjust stage name ***
UNION ALL
-- 14. Deployed to Production
SELECT i.number, 'Deployed to Production', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'SUCCESS' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 15. Deployment Failed
SELECT i.number, 'Deployment Failed', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'FAILURE' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 16. Development Item Cancelled
SELECT i.number, 'Development Item Cancelled', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Cancelled'' State Value]'; -- *** Placeholder: Adjust state value *** 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.
Bez platební karty. Začněte s optimalizací ještě dnes.