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

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

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

Tato šablona vám pomůže určit základní údaje potřebné k analýze procesu životního cyklu vývoje softwaru. Uvádí doporučené atributy ke sběru, důležité aktivity ke sledování a praktický postup, jak údaje získat přímo z GitLabu. Připravte si s její pomocí data pro process mining.
  • Doporučené atributy ke sběru
  • Důležité aktivity ke sledování
  • Pokyny k získání dat
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 a optimalizaci životního cyklu vývoje softwaru.
3 Povinné 5 Doporučené 12 Volitelné
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 created_at daného issue, zatímco StartTime aktivity 'Sloučení merge requestu' odpovídá časovému údaji merged_at merge requestu.

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 assignee nebo assignees u issue či merge requestu.

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 state s hodnotou 'opened' nebo 'closed'. Podrobnější stavy se často spravují pomocí štítků s oborem platnosti, například 'Status::Triage', 'Status::In-Dev' nebo 'Status::In-Review'.

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
Povinné Doporučené Volitelné

Aktivity životního cyklu vývoje softwaru

Jde o důležité kroky procesu a milníky, které zachyťte v záznamu událostí, abyste mohli přesně zjistit průběh procesu a odhalit úzká místa.
4 Doporučené 8 Volitelné
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
Doporučené Volitelné

Návody k získání dat

Jak získat data z GitLabu

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.

Začněte bezplatnou zkušební verzi

Platební kartu nepotřebujete. S optimalizací můžete začít hned.