Š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í
- Pokyny k získání dat
Atributy životního cyklu vývoje softwaru
| Název | Popis | ||
|---|---|---|---|
|
Aktivita
Activity
|
Název konkrétního kroku nebo události procesu, například 'Vytvoření issue' nebo 'Sloučení merge requestu'. | ||
|
Popis
Atribut Aktivita zachycuje jednotlivé události, které se týkají vývojové položky. V GitLab nejsou uloženy v jednom poli, ale odvozují se z různých akcí a časových údajů v issue, merge requestech a pipeline CI/CD. Jednotlivými aktivitami jsou například vytvoření issue, odeslání commitu, selhání pipeline nebo schválení merge requestu. Tento atribut je základem pro vytvoření mapy procesu, zobrazení workflow a analýzu pořadí a četnosti událostí. Pomáhá odhalit odchylky, úzká místa mezi kroky a obvyklé cesty procesem.
Proč je to důležité
Určuje kroky v mapě procesu a umožňuje zobrazit a analyzovat vývojové workflow od začátku do konce.
Kde data získat
Odvozuje se z typů událostí a změn stavů v proudu událostí GitLab nebo z časových údajů, jako jsou 'created_at', 'merged_at' a 'closed_at' u issue a merge requestů.
Příklady
Vytvoření issueZahájení vývojeSloučení merge requestuSelhání pipelineNasazení do produkce
|
|||
|
Čas zahájení
StartTime
|
Časový údaj označující začátek aktivity nebo události. | ||
|
Popis
StartTime označuje přesné datum a čas konkrétní aktivity. Události v GitLab se zaznamenávají do různých časových polí. Například StartTime aktivity 'Vytvoření issue' odpovídá časovému údaji Tento časový údaj je základním časovým prvkem v process mining. Slouží k seřazení událostí, výpočtu doby mezi aktivitami, měření délky cyklů a analýze výkonnosti procesu v čase.
Proč je to důležité
Tento atribut určuje chronologické pořadí událostí. Je nezbytný pro výpočet všech časových metrik a pochopení průběhu procesu.
Kde data získat
Získává se z různých časových polí v GitLab, například 'created_at', 'updated_at' a 'closed_at' u issue a 'merged_at' u merge requestů.
Příklady
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
Vývojová položka
DevelopmentItem
|
Jedinečný identifikátor pracovní jednotky, například funkce, opravy chyby nebo úkolu. Slouží jako hlavní identifikátor případu. | ||
|
Popis
Vývojová položka představuje jednu sledovatelnou pracovní jednotku, která prochází životním cyklem vývoje softwaru. Propojuje všechny související aktivity do jednoho případu, od vytvoření až po nasazení. V GitLab ji obvykle představuje interní ID issue (IID), které je jedinečné v rámci projektu. Analýza podle vývojové položky umožňuje měřit délku cyklu od začátku do konce, hledat úzká místa a ověřovat dodržování procesu. Pomáhá pochopit, jak efektivně se práce dostává od návrhu do produkce.
Proč je to důležité
Jde o hlavní identifikátor případu, který propojuje všechny události procesu a umožňuje sledovat celý životní cyklus pracovní položky.
Kde data získat
Obvykle jde o interní ID (IID) issue v GitLab. V odpovědi Issues API ho najdete v poli 'iid'.
Příklady
1024512PRJ-2345
|
|||
|
Čas ukončení
EndTime
|
Časový údaj označující dokončení aktivity nebo události. | ||
|
Popis
EndTime označuje přesné datum a čas dokončení aktivity. U mnoha jednotlivých událostí v GitLab, například 'Vytvoření issue', je EndTime stejný jako StartTime. U aktivit, které trvají určitou dobu, například 'Kontrola kódu', označuje čas dokončení, třeba udělení posledního schválení. Tento atribut je nezbytný pro přesný výpočet délky jednotlivých aktivit (doby zpracování). Pomáhá podrobně analyzovat úzká místa, protože odlišuje čas aktivní práce na úkolu od čekání mezi úkoly.
Proč je to důležité
Umožňuje přesně vypočítat délku aktivit (dobu zpracování), což pomáhá najít neefektivní kroky procesu.
Kde data získat
U jednotlivých událostí odpovídá StartTime. U aktivit s určitou délkou je třeba EndTime odvodit z odpovídající události dokončení v datech.
Příklady
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Název projektu
ProjectName
|
Název projektu GitLab, do kterého vývojová položka patří. | ||
|
Popis
Tento atribut určuje konkrétní úložiště kódu nebo projekt, ve kterém se pracuje. V GitLab patří každé issue a každý merge request do určitého projektu. Analýza podle názvu projektu umožňuje porovnávat výkonnost různých produktů, komponent nebo služeb. Pomáhá zjistit, zda mají některé projekty zdravější procesy SDLC než jiné, a filtrovat dashboardy podle konkrétní oblasti.
Proč je to důležité
Umožňuje rozdělit analýzu procesu podle produktu, aplikace nebo komponenty a zaměřit zlepšování na konkrétní oblast.
Kde data získat
Údaj se získává z polí 'name' nebo 'path_with_namespace' v Project API a propojuje se pomocí pole 'project_id' v issue a merge requestech.
Příklady
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Přiřazená osoba
Assignee
|
Uživatel přiřazený k issue nebo merge requestu v době události. | ||
|
Popis
Přiřazená osoba je vývojář nebo uživatel odpovědný za pracovní položku v určité fázi procesu. V GitLab se zaznamenává v poli Analýza podle přiřazené osoby je důležitá pro dashboard „Vytížení a rozdělení práce vývojářů“. Pomáhá posoudit využití zdrojů, odhalit přetížené jednotlivce nebo týmy a analyzovat předávání práce.
Proč je to důležité
Ukazuje, kdo práci vykonal. Umožňuje analyzovat vytížení, efektivitu rozdělení zdrojů a prodlevy způsobené předáváním práce.
Kde data získat
Údaj se získává z polí 'assignee.username' nebo 'assignees' v odpovědích GitLab Issues API a Merge Requests API.
Příklady
jdoeasmithr.williams
|
|||
|
Typ vývojové položky
DevelopmentItemType
|
Zařazení vývojové položky, například 'Funkce', 'Chyba', 'Úkol' nebo 'Údržba'. | ||
|
Popis
Tento atribut určuje povahu vykonávané práce. V GitLab se obvykle nastavuje pomocí štítků u issue. Týmy jimi rozlišují nové funkce, opravy chyb, technický dluh a další typy práce. Analýza podle typu vývojové položky umožňuje porovnávat průběh procesů a délku cyklů u různých druhů práce. Lze například zjistit, zda se chyby řeší rychleji, než se vyvíjejí nové funkce, nebo zda úkoly technického dluhu procházejí jiným procesem kontroly.
Proč je to důležité
Rozdělení procesu podle typu práce pomáhá zjistit, zda některé typy práce častěji vedou k prodlevám, opakované práci nebo odchylkám.
Kde data získat
Obvykle se odvozuje ze štítků přiřazených k issue v GitLab. K převedení konkrétních štítků na standardizované typy je potřeba mapovací logika.
Příklady
FunkceChybaÚkolTechnický dluh
|
|||
|
Závažnost
Severity
|
Úroveň závažnosti vývojové položky, obvykle u chyb nebo incidentů. | ||
|
Popis
Závažnost vyjadřuje dopad chyby nebo problému, od kritického po drobný. GitLab nemá vlastní pole pro závažnost, proto se téměř vždy nastavuje pomocí štítků, například 'severity::1' nebo 'severity::2'. Tento atribut je důležitý pro dashboard „Vývoj eskalací závažnosti“ a související KPI. Analýza změn závažnosti v průběhu životního cyklu může odhalit problémy, jejichž dopad byl zpočátku podceněn, nebo procesy, které situaci zhoršují.
Proč je to důležité
Pomáhá určovat priority práce a analyzovat, zda se položky s vysokou závažností řeší rychleji. Sledování změn podporuje KPI „Četnost eskalací závažnosti“.
Kde data získat
Odvozuje se ze štítků přiřazených k issue v GitLab. Pro určení úrovně závažnosti ze štítků, jako jsou 'S1' nebo 'S2', je potřeba mapování.
Příklady
1 - Kritická2 - Vysoká3 - Střední4 - Nízká
|
|||
|
Čekání při předání práce
HandoffWaitTime
|
Vypočítaná doba nečinnosti mezi dvěma po sobě jdoucími aktivitami, které provádějí různí řešitelé. | ||
|
Popis
Tato metrika měří dobu mezi dokončením jedné aktivity a zahájením následující, pokud se změní řešitel. Měří například čas od chvíle, kdy vývojář dokončí práci, do chvíle, kdy kontrolor zahájí code review. Jde o hlavní metriku KPI „Průměrná doba čekání při předání práce“. Pomáhá odhalit skrytou neefektivitu při rozdělování zdrojů a komunikaci mezi týmy nebo jednotlivci. Upozorňuje na prodlevy, které nejsou součástí aktivní práce.
Proč je to důležité
Měří dobu nečinnosti při předávání práce mezi lidmi nebo týmy a odhaluje skryté prodlevy i problémy v komunikaci.
Kde data získat
Vypočítává ji nástroj process mining. Je třeba analyzovat po sobě jdoucí události v rámci případu, ověřit, zda se liší pole „Assignee“, a poté vypočítat časový rozdíl.
Příklady
1 den 2 hodiny15 minut8 hodin
|
|||
|
Cílová větev
TargetBranch
|
Název cílové větve, do které se má Merge Request sloučit. | ||
|
Popis
Cílová větev je větev, do které se mají změny sloučit, například „main“, „develop“ nebo větev pro vydání, jako je „release/1.5“. Jde o základní údaj každého Merge Request. Analýza podle cílové větve může odhalit rozdíly v průběhu práce při slučování kódu do různých větví. Například slučování do „main“ může vyžadovat důkladnější schválení a trvat déle než slučování do vývojové větve. Pomáhá také odlišit nasazení do produkce od jiných typů integrace kódu.
Proč je to důležité
Pomáhá rozlišit vývojové a releasové workflow, protože průběh práce se může výrazně lišit podle cílové větve.
Kde data získat
Získává se z pole „target_branch“ v odpovědi GitLab Merge Requests API.
Příklady
maindeveloprelease/v2.1.0hotfix/user-auth-bug
|
|||
|
Doba cyklu
CycleTime
|
Celková doba od první do poslední aktivity vývojové položky. | ||
|
Popis
Doba cyklu je vypočítaná metrika, která měří celkovou dobu trvání případu. Obvykle se počítá jako časový rozdíl mezi první událostí, například „Issue Created“, a poslední událostí, například „Deployed to Production“, u jedné vývojové položky. Jde o hlavní KPI pro měření celkové efektivity procesu. Je to klíčová metrika dashboardů, jako je „Doba cyklu SDLC od začátku do konce“, a slouží ke sledování zlepšení i k odhalování dlouhotrvajících případů, které mohou ukazovat na systémové problémy.
Proč je to důležité
Toto základní KPI process mining měří efektivitu vývojového cyklu od začátku do konce.
Kde data získat
Nástroj process mining ji vypočítá tak, že pro každé jedinečné CaseId odečte nejnižší StartTime od nejvyššího StartTime.
Příklady
10 dní 4 hodiny23 hodin 15 minut35 dní
|
|||
|
Jde o přepracování
IsRework
|
Logická hodnota, která určuje, zda je aktivita součástí opakovaného cyklu přepracování. | ||
|
Popis
Tento vypočítaný atribut označuje aktivity, které představují krok zpět v procesu, například návrat k vývoji po zahájení testování. Příznak se obvykle nastavuje na základě konkrétních posloupností aktivit. Může jít například o událost „Development Started“, která u stejného případu následuje po události „Pipeline Failed“ nebo „QA Testing Started“. Tento atribut přímo slouží dashboardu „Analýza přepracování a opakovaných běhů“ a KPI „Míra přepracování po testování“. Umožňuje snadno filtrovat a kvantifikovat přepracování, takže týmy lépe porozumí jeho četnosti, příčinám i dopadu na harmonogram projektu.
Proč je to důležité
Přímo označuje a kvantifikuje přepracování, takže lze snadno analyzovat příčiny a dopad neefektivního procesu i problémů s kvalitou.
Kde data získat
Nástroj process mining ji vypočítá analýzou posloupnosti aktivit v každém případu a vyhledáním vzorců, které ukazují na přepracování.
Příklady
truefalse
|
|||
|
Název milníku
MilestoneTitle
|
Název milníku nebo sprintu, ke kterému je vývojová položka přiřazena. | ||
|
Popis
Milník v GitLabu slouží ke sledování práce na konkrétním cíli nebo v určeném časovém období, například během sprintu nebo při přípravě vydání. Tento atribut zachycuje název milníku. Díky tomuto atributu můžete analyzovat průběh procesu v rámci konkrétních sprintů nebo plánovacích období. Zjistíte například, zda se doba cyklu mezi sprinty zkracuje, nebo můžete v zobrazení procesu filtrovat pouze práci související s nadcházejícím vydáním.
Proč je to důležité
Propojuje vývojovou práci s plánovacími cykly, například sprinty nebo vydáními, a umožňuje porovnat výsledky s plánovaným časovým rámcem.
Kde data získat
Získává se z pole „milestone.title“ v odpovědích GitLab Issues API nebo Merge Requests API.
Příklady
Vydání Q4-2023Sprint 23.11Fáze 1: MVP
|
|||
|
Název týmu
TeamName
|
Vývojový tým přiřazený k projektu nebo osobě odpovědné za práci. | ||
|
Popis
Název týmu označuje skupinu odpovědnou za vývojovou položku. V GitLab obvykle nejde o standardní pole. Často se odvozuje z konvencí pojmenování projektů, struktury skupin nebo z přiřazení uživatelů k týmům podle externí referenční tabulky. Tento atribut slouží k analýze výkonnosti procesu na úrovni týmů. Pomáhá porovnávat efektivitu, vytížení a dodržování procesu mezi týmy a podporuje například týmový pohled na dashboard „Analýza úzkých míst podle fáze“.
Proč je to důležité
Umožňuje analyzovat výkonnost a porovnávat procesy mezi týmy. Pomáhá odhalit úzká místa specifická pro jednotlivé týmy i osvědčené postupy.
Kde data získat
Obvykle se odvozuje přiřazením názvu projektu nebo odpovědné osoby ke struktuře týmů definované mimo GitLab, případně ze struktury skupin v GitLab.
Příklady
Frontend-AlphaBackend-ServicesPlatform-Infra
|
|||
|
Poslední aktualizace dat
LastDataUpdate
|
Časový údaj označující, kdy byla data této události naposledy obnovena ze zdrojového systému. | ||
|
Popis
Tento atribut zaznamenává datum a čas, kdy byla data události naposledy extrahována nebo aktualizována v datové sadě pro process mining. Neoznačuje čas, kdy k události došlo, ale kdy byl její záznam naposledy synchronizován. Tato informace pomáhá posoudit aktuálnost dat a ověřit, zda analýza procesu vychází z včasných údajů. Uživatelé díky ní vědí, zda dashboardy a KPI vycházejí z aktuálních dat, a mohou zohlednit případné zpoždění mezi zdrojovým systémem a analýzou.
Proč je to důležité
Zpřehledňuje aktuálnost dat, takže uživatelé vědí, jak aktuální je analýza procesu.
Kde data získat
Tento časový údaj vytváří a zaznamenává nástroj pro extrakci dat nebo proces ETL při jejich aktualizaci.
Příklady
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Stav Merge Request
MergeRequestStatus
|
Stav Merge Request spojeného s událostí, například „Opened“, „Merged“ nebo „Closed“. | ||
|
Popis
Tento atribut zachycuje stav Merge Request (MR) v okamžiku události. MR v GitLabu mohou mít různé stavy: „opened“, „closed“, „merged“ nebo „locked“. Nejde o celkový stav vývojové položky. Sledování stavu MR je důležité pro analýzu fáze integrace kódu v rámci SDLC. Poskytuje podklady pro dashboardy, jako je „Doba cyklu a průchodnost code review“, a pomáhá odhalit prodlevy mezi vytvořením MR, kontrolou kódu, schválením a sloučením.
Proč je to důležité
Zpřehledňuje kontrolu kódu a slučování, které v SDLC často představují úzké místo.
Kde data získat
Získává se z pole „state“ v odpovědi GitLab Merge Requests API.
Příklady
otevřenomergeduzavřenolocked
|
|||
|
Stav pipeline
PipelineStatus
|
Stav běhu CI/CD pipeline, například „Success“, „Failed“ nebo „Running“. | ||
|
Popis
Tento atribut udává výsledek běhu CI/CD pipeline spojeného s commitem nebo Merge Request. Mezi běžné stavy v GitLabu patří „running“, „pending“, „success“, „failed“, „canceled“ a „skipped“. Tyto údaje jsou nezbytné pro dashboard „Analýza přepracování a opakovaných běhů“. Časté selhání pipeline může vést k přepracování a prodlevám. Analýza četnosti, místa výskytu a dopadu těchto selhání pomáhá zvyšovat efektivitu vývoje a kvalitu kódu.
Proč je to důležité
Sleduje úspěšné a neúspěšné automatizované sestavení a testy. Odhaluje opakované cykly přepracování i problémy s kvalitou kódu nebo automatizací testů.
Kde data získat
Získává se z pole „status“ v odpovědi GitLab CI/CD Pipelines API.
Příklady
successfailedrunningcanceled
|
|||
|
Stav vývojové položky
DevelopmentItemStatus
|
Stav vývojové položky v době události, například 'Otevřeno', 'Probíhá' nebo 'Uzavřeno'. | ||
|
Popis
Tento atribut zachycuje stav hlavní pracovní položky, obvykle issue v GitLab. Issue v GitLab má pole Sledování změn stavu je důležité pro pochopení životního cyklu případu. Ukazuje, jak dlouho položky zůstávají v jednotlivých stavech, a umožňuje v dashboardech, například „Délka cyklu SDLC od začátku do konce“, filtrovat rozpracovanou a dokončenou práci.
Proč je to důležité
Poskytuje přehled o stavu případu. Umožňuje analyzovat dobu strávenou v jednotlivých fázích a filtrovat rozpracovanou a dokončenou práci.
Kde data získat
Hlavní stav se získává z pole 'state' issue v GitLab ('opened', 'closed'). Podrobnější stavy se často odvozují ze štítků.
Příklady
otevřenouzavřenoProbíháProbíhá kontrola
|
|||
|
Verze vydání
ReleaseVersion
|
Plánované nebo skutečné označení verze softwaru spojené s nasazením. | ||
|
Popis
Tento atribut určuje konkrétní vydání softwaru, jehož součástí je vývojová položka. V GitLabu lze vydání přiřadit pomocí milníku, chráněného tagu nebo položky v sekci Releases. Tento údaj je nezbytný pro dashboard „Sledování dodržení plánu vydání“. Porovnáním skutečného data nasazení s plánovaným datem spojeným s verzí vydání mohou organizace měřit, jak se jim daří dodržovat harmonogram, a zjišťovat příčiny zpoždění.
Proč je to důležité
Propojuje vývojové položky s konkrétním vydáním softwaru. Díky tomu lze sledovat průběh vydání a dodržování harmonogramu.
Kde data získat
Údaj lze získat z GitLab Releases, názvu git tagu nebo názvu milníku použitého při plánování vydání.
Příklady
v1.2.0v3.0.0-beta2023.4.1
|
|||
|
Zdrojový systém
SourceSystem
|
Určuje systém, ze kterého data pocházejí. | ||
|
Popis
Tento atribut určuje původ dat procesu. V tomto datovém modelu bude jeho hodnota vždy 'GitLab'. Atribut je důležitý v prostředích, kde se kombinují data o procesech z více systémů, například Jira pro plánování a GitLab pro realizaci. Umožňuje filtrování a segmentaci a pomáhá zachovat přehled o původu dat.
Proč je to důležité
Zajišťuje přehled o původu dat, což je důležité pro správu dat i pro jejich integraci z více podnikových systémů.
Kde data získat
Jde o statickou hodnotu 'GitLab', která se přidává při transformaci dat.
Příklady
GitLab
|
|||
Aktivity životního cyklu vývoje softwaru
| Aktivita | Popis | ||
|---|---|---|---|
|
Nasazení do produkce
|
Tato aktivita označuje úspěšné nasazení kódu do produkčního prostředí, kde je dostupný koncovým uživatelům. Zaznamená se po úspěšném dokončení konkrétní úlohy 'deploy to production' v pipeline CI/CD GitLab. | ||
|
Proč je to důležité
Jde o hlavní koncovou událost procesu, která označuje dodání hodnoty. Je nezbytná pro měření celkové délky cyklu SDLC od začátku do konce a četnosti vydávání verzí.
Kde data získat
Údaj se získává z časového údaje 'finished_at' úspěšné úlohy CI/CD určené k nasazení do produkce. Funkce Environments v GitLab tuto událost sleduje přímo.
Zachycení
Použijte časový údaj 'finished_at' z úspěšné úlohy CI pro nasazení do produkce.
Typ události
explicit
|
|||
|
Sloučení merge requestu
|
Tato aktivita označuje úspěšné dokončení kontroly a začlenění kódu. Jde o explicitní událost, ke které dojde, když uživatel sloučí větev merge requestu do cílové větve. | ||
|
Proč je to důležité
Jde o významný milník, který označuje dokončení vývoje a kontroly. Je koncovým bodem pro měření délky vývojového cyklu a počátečním bodem pro měření doby nasazení.
Kde data získat
Jde o explicitní událost zachycenou z časového údaje 'merged_at' v tabulce 'merge_requests'. Při sloučení se vytvoří také systémová poznámka.
Zachycení
Použijte časový údaj 'merged_at' daného merge requestu.
Typ události
explicit
|
|||
|
Vytvoření issue
|
Tato aktivita označuje začátek vývojového cyklu a vznik nové pracovní položky, například funkce, chyby nebo úkolu. Zachytí se ve chvíli, kdy uživatel vytvoří issue v GitLab. Systém zaznamená čas vytvoření. | ||
|
Proč je to důležité
Jde o hlavní počáteční událost procesu od začátku do konce. Doba od vytvoření issue po nasazení poskytuje úplný přehled o délce cyklu SDLC.
Kde data získat
Jde o explicitní událost zachycenou z časového údaje 'created_at' v tabulce 'issues' nebo prostřednictvím Issues API. Událost vytvoření zaznamenávají také systémové poznámky.
Zachycení
Použijte časový údaj 'created_at' daného issue.
Typ události
explicit
|
|||
|
Vytvoření merge requestu
|
Označuje dokončení počáteční vývojové práce a připravenost kódu ke kontrole a začlenění. Jde o explicitní a zásadní událost workflow GitLab, která se zaznamená při vytvoření nového merge requestu (MR). | ||
|
Proč je to důležité
Jde o důležitý milník, který označuje předání práce z vývoje ke kontrole a testování. Je výchozím bodem pro analýzu celého cyklu kontroly kódu a pipeline CI/CD.
Kde data získat
Jde o explicitní událost zachycenou z časového údaje 'created_at' v tabulce 'merge_requests' nebo prostřednictvím Merge Requests API.
Zachycení
Použijte časový údaj 'created_at' daného merge requestu.
Typ události
explicit
|
|||
|
Přidání schválení
|
Označuje formální schválení změn kódu v merge requestu kontrolujícím uživatelem. GitLab tuto událost zaznamená, když uživatel klikne na tlačítko 'Approve'. | ||
|
Proč je to důležité
Schválení představují důležitou kontrolu kvality. Jejich sledování pomáhá zjistit, jak dlouho trvá získat potřebná potvrzení, a ověřit dodržování pravidel kontroly.
Kde data získat
Údaj se získává z událostí schválení merge requestu. Jsou dostupné prostřednictvím Approvals API nebo v historii MR.
Zachycení
Použijte časový údaj záznamu události schválení merge requestu.
Typ události
explicit
|
|||
|
Přiřazení issue
|
Označuje přiřazení issue konkrétnímu vývojáři nebo týmu, tedy určení odpovědnosti za práci. GitLab tuto událost zaznamená vždy, když je u issue vyplněno nebo změněno pole přiřazené osoby. | ||
|
Proč je to důležité
Sledování přiřazení je důležité pro analýzu rozdělení zdrojů, vytížení týmu a předávání práce. Pomáhá odhalit prodlevy mezi vytvořením práce a jejím převzetím.
Kde data získat
Údaj se získává ze systémových poznámek GitLab k issue, které zaznamenávají přidání nebo změnu 'assignee'. Čas události je uveden v poznámce.
Zachycení
Ze systémových poznámek issue extrahujte události 'assignee changed'.
Typ události
explicit
|
|||
|
Selhání pipeline
|
K této aktivitě dochází, když běh pipeline CI/CD selže v kterékoli fázi, například kvůli chybě při sestavení nebo neúspěšnému testu. GitLab zaznamenává konečný stav každé pipeline, takže selhání lze snadno najít. | ||
|
Proč je to důležité
Selhání pipeline často vedou k opakované práci. Analýza jejich četnosti, délky a příčin pomáhá odhalit problémy s kvalitou, nestabilní testy a úzká místa ve zpětné vazbě pro vývojáře.
Kde data získat
Událost se určí podle stavu 'failed' u záznamu pipeline v tabulce 'ci_pipelines'. Časový údaj 'finished_at' označuje, kdy k selhání došlo.
Zachycení
Vyfiltrujte záznamy pipeline se stavem 'failed' a použijte časový údaj 'finished_at'.
Typ události
explicit
|
|||
|
Spuštění pipeline
|
Označuje spuštění automatizované pipeline CI/CD, která obvykle provádí sestavení, testy a bezpečnostní kontroly. GitLab při každém spuštění pipeline, například po commitu nebo vytvoření MR, vytvoří záznam s časem zahájení. | ||
|
Proč je to důležité
Sledování běhů pipeline je důležité pro kontrolu stavu a efektivity automatizovaného testování a integrace. Pomáhá zjistit, kolik času zabere automatické ověřování.
Kde data získat
Údaj se získává z časového údaje 'created_at' nebo 'started_at' záznamu pipeline v tabulce 'ci_pipelines' nebo prostřednictvím Pipelines API.
Zachycení
Použijte časový údaj ze záznamu běhu pipeline přiřazeného k větvi MR.
Typ události
explicit
|
|||
|
Uzavření issue
|
Označuje konečné administrativní uzavření pracovní položky, obvykle poté, co byly její změny nasazeny a ověřeny. GitLab tuto událost zaznamená, když uživatel issue uzavře. | ||
|
Proč je to důležité
Uzavření issue často znamená konec veškeré související práce. Porovnáním času uzavření s časem nasazení lze odhalit prodlevy při ověřování po nasazení nebo v administrativních postupech.
Kde data získat
Jde o explicitní událost zachycenou z časového údaje 'closed_at' v tabulce 'issues' nebo z odpovídající systémové poznámky.
Zachycení
Použijte časový údaj 'closed_at' daného issue.
Typ události
explicit
|
|||
|
Zahájení kontroly kódu
|
Označuje začátek vzájemné kontroly merge requestu. Událost se odvozuje od první akce související s kontrolou, například prvního komentáře nebo příspěvku ve vlákně od někoho jiného než autora. | ||
|
Proč je to důležité
Měření doby od vytvoření MR do zahájení kontroly odhalí čekání ve frontě. Zkrácení této doby pomáhá zkrátit celý cyklus kontroly kódu.
Kde data získat
Událost se odvozuje z času prvního komentáře nebo vlákna kontroly u merge requestu od někoho jiného než jeho autora. Tyto údaje jsou dostupné v systémových poznámkách nebo prostřednictvím Notes API.
Zachycení
Najděte čas prvního komentáře k MR od uživatele, který není jeho autorem.
Typ události
inferred
|
|||
|
Zahájení nasazení
|
Označuje začátek nasazování kódu do konkrétního prostředí, například staging nebo produkce. V GitLab tomu odpovídá zahájení úlohy 'deploy' v pipeline CI/CD. | ||
|
Proč je to důležité
Sledování začátku nasazení pomáhá určit délku této fáze. Je důležité pro měření a zkracování doby nasazení.
Kde data získat
Údaj se získává z časového údaje 'started_at' úlohy CI/CD nastavené jako úloha nasazení. Jde o součást funkce Environments and Deployments v GitLab.
Zachycení
U úlohy nasazení použijte časový údaj 'started_at' ze záznamu úlohy CI.
Typ události
explicit
|
|||
|
Zahájení vývoje
|
Tato aktivita označuje začátek aktivní práce na kódu souvisejícím s issue. Obvykle se odvozuje od prvního commitu odeslaného do větve propojené s issue, protože GitLab nemá samostatné tlačítko pro zahájení vývoje. | ||
|
Proč je to důležité
Určuje přesný začátek vývojové práce, která přináší hodnotu. Umožňuje přesně měřit samotné programování a oddělit je od plánování nebo čekání ve frontě.
Kde data získat
Odvozuje se z časového údaje prvního commitu ve větvi funkce propojené s issue. Je třeba propojit issue s větvemi, obvykle pomocí konvencí pojmenování nebo metadat.
Zachycení
Najděte čas prvního commitu ve větvi přiřazené k ID issue.
Typ události
inferred
|
|||
Návody k získání dat
Chcete začít?
Pomocí této šablony připravte data a začněte optimalizovat životní cyklus vývoje softwaru. Pusťte se do zlepšování procesu.
Zlepšete životní cyklus vývoje softwaru: začněte s optimalizací
Odhalte úzká místa SDLC, zkraťte dobu cyklu o 30 % a zvyšte kvalitu.
Platební kartu nepotřebujete. S optimalizací můžete začít hned.