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

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

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

Tato šablona vám pomůže shromáždit a připravit data o životním cyklu vývoje softwaru z GitHubu. Najdete v ní doporučené atributy, důležité aktivity ke sledování i praktické pokyny k extrakci dat. Využijte ji k vytvoření přesného záznamu událostí pro analýzu a zlepšování procesů.
  • Doporučené atributy ke sběru
  • Aktivity, které stojí za to sledovat
  • Pokyny k extrakci 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

Toto jsou doporučená datová pole pro záznam událostí, který využijete k podrobné analýze životního cyklu vývoje softwaru a odhalování procesů.
3 Povinné 5 Doporučené 15 Volitelné
Název Popis
Aktivita
ActivityName
Název konkrétní události nebo úkolu, ke kterému došlo během životního cyklu vývoje softwaru.
Popis

Název aktivity popisuje jeden krok vývojového procesu, například 'Issue vytvořeno', 'Kód odeslán do PR', 'Pull request schválen' nebo 'Nasazení úspěšné'. Tyto události tvoří posloupnost kroků, které dohromady představují celý proces vývojové položky.

Tento atribut je pro process mining zásadní, protože se podle něj sestavuje mapa procesu. Analýza pořadí, četnosti a délky aktivit odhalí skutečný průběh procesu, běžné cesty i odchylky a pomůže určit úzká místa.

Proč je to důležité

Tento atribut tvoří základ mapy procesu a umožňuje zobrazit i analyzovat pořadí událostí v životním cyklu vývoje.

Kde data získat

Odvozuje se z pole 'action' v datech webhookových událostí, například 'opened' nebo 'closed' u issue, případně přímo z typu události, například 'PushEvent' nebo 'PullRequestReviewEvent'.

Příklady
Issue vytvořenoPull request otevřenKód odeslán do PRVyžádána revizePull request sloučen
Čas zahájení
EventTimestamp
Přesné datum a čas, kdy došlo ke konkrétní vývojové aktivitě nebo události.
Popis

Toto časové razítko označuje začátek aktivity. Je nezbytné pro chronologické seřazení událostí a rekonstrukci průběhu procesu u každé vývojové položky. Pořadí a časové rozdíly mezi těmito razítky slouží k analýze výkonnosti procesu.

Při analýze je tento atribut nezbytný pro výpočet všech časových ukazatelů, včetně doby průchodu, doby zpracování a čekání. Umožňuje odhalit prodlevy mezi kroky a poskytuje data pro analýzu úzkých míst i dashboardy pro sledování výkonnosti.

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, například doby průchodu a délky trvání úzkých míst.

Kde data získat

Obvykle se nachází v polích 'created_at' nebo 'updated_at' v datech JSON z GitHub API a webhooků pro různé objekty, například issue, pull requesty a commity.

Příklady
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Vývojová položka
DevelopmentItemId
Jedinečný identifikátor jedné jednotky vývojové práce, například funkce, opravy chyby nebo úkolu. Slouží jako hlavní identifikátor případu.
Popis

ID vývojové položky sleduje pracovní položku od jejího vytvoření až po konečné nasazení. Propojuje všechny související aktivity, například vytvoření větve, commity, pull requesty, revize a nasazení, do jedné ucelené instance procesu.

Při analýze se toto ID používá k výpočtu celkové doby průchodu vývojového úkolu. Umožňuje rekonstruovat celý průběh vývoje funkce nebo opravy chyby a podrobně analyzovat úzká místa, opakované předělávání i odchylky v procesu u jednotlivých pracovních položek.

Proč je to důležité

Jde o nezbytný identifikátor pro process mining. Propojuje všechny související vývojové události do jednoho případu, takže lze přesně zobrazit a analyzovat celý životní cyklus vývoje softwaru.

Kde data získat

Obvykle jde o číslo issue nebo pull requestu z GitHubu. Lze ho získat z pole 'number' v datech webhookových událostí nebo odpovědích API souvisejících s issue či pull requestem.

Příklady
101PR-2345TASK-812
Čas dokončení
EndTimestamp
Přesné datum a čas, kdy byla konkrétní vývojová aktivita nebo událost dokončena.
Popis

Časové razítko dokončení označuje konec aktivity. Mnoho událostí v GitHubu proběhne okamžitě, například 'Issue vytvořeno', některé aktivity však mají měřitelnou dobu trvání, například běh CI kontroly. Rozdíl mezi časem dokončení a časem zahájení udává dobu zpracování aktivity.

Tento atribut slouží k výpočtu ukazatele 'ProcessingTime', který pomáhá zjistit, kolik aktivní práce vyžadují různé úkoly, například revize kódu nebo automatické kontroly. Analýza doby zpracování odhalí neefektivní aktivity, které zabírají příliš mnoho času.

Proč je to důležité

Umožňuje přesně vypočítat dobu zpracování aktivit a rozlišit aktivní práci od čekání.

Kde data získat

Lze ho najít jako 'completed_at' v objektech spuštění kontroly nebo odvodit z časového razítka následující události, která aktivitu logicky ukončuje.

Příklady
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Priorita
Priority
Úroveň priority přiřazená vývojové položce, například 'High', 'Medium' nebo 'Low'.
Popis

Priorita vyjadřuje naléhavost nebo obchodní důležitost pracovní položky. GitHub nemá pro prioritu vlastní pole, proto se obvykle spravuje pomocí štítků, například „P1-High“ nebo „P2-Medium“. Aby bylo možné prioritu spolehlivě zjistit, je potřeba používat jednotné značení.

Tento atribut je nezbytný pro analýzu toku podle priority. Analytici díky němu mohou ověřit, zda se položky s vysokou prioritou skutečně zpracovávají rychleji než položky s nízkou prioritou, a porovnat jejich dobu průchodu procesem. Pomáhá také vyhodnotit účinnost stanovování priorit.

Proč je to důležité

Umožňuje ověřit, zda se položky s vysokou prioritou zpracovávají rychleji než položky s nižší prioritou, a vyhodnotit tak účinnost strategie stanovování priorit.

Kde data získat

Odvozuje se ze štítků GitHubu přiřazených k issues nebo pull requestům. Vyžaduje jednotné značení štítků priority.

Příklady
VysokáStředníNízkáKritická
Přiřazený uživatel
Assignee
Uživatel nebo vývojář odpovědný za vývojovou položku či konkrétní úkol, například revizi pull requestu.
Popis

Tento atribut označuje osobu odpovědnou za práci v dané fázi. Může jít o řešitele issue, autora pull requestu nebo kontrolujícího požádaného o revizi kódu. Sledování přiřazené osoby je důležité pro pochopení rozdělení zdrojů a pracovního vytížení.

Při analýze se tento atribut používá ke sledování vytížení vývojářů, odhalování úzkých míst ve využití zdrojů a hodnocení efektivity předávání práce mezi členy týmu. Dashboardy lze filtrovat podle přiřazené osoby a posoudit tak výkon jednotlivců i týmů a vyváženost rozdělení práce.

Proč je to důležité

Nezbytný pro analýzu vytížení vývojářů, výkonu týmu a efektivity předávání práce mezi jeho členy.

Kde data získat

V datech JSON pro issue, pull requesty a události revizí z GitHub API je dostupný v objektu 'assignee' nebo 'user'.

Příklady
john.doejane.smithdev-team-lead
Repozitář
RepositoryName
Název repozitáře s kódem, ve kterém probíhá vývojová aktivita.
Popis

Repozitář slouží jako identifikátor projektu nebo produktu. Obsahuje veškerý kód, issue a pull requesty pro konkrétní aplikaci nebo komponentu. Umožňuje rozdělit a porovnávat vývojové procesy napříč produkty nebo týmy.

Při analýze tento atribut umožňuje filtrovat a porovnávat výkonnost procesu v různých projektech. Pomáhá odpovědět například na otázky: „Který projekt má nejdelší dobu průchodu?“ nebo „Jak se proces opravy chyb v projektu A liší od projektu B?“ Je nezbytný pro dashboard 'Průchodnost podle projektu a typu'.

Proč je to důležité

Umožňuje rozdělit a porovnávat vývojové procesy napříč projekty, produkty nebo týmy a zaměřit analýzu na konkrétní oblasti.

Kde data získat

Je dostupný v objektu 'repository' téměř ve všech datech webhooků a API GitHubu. Konkrétní pole bývá 'repository.full_name' nebo 'repository.name'.

Příklady
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Typ vývojové položky
DevelopmentItemType
Klasifikace vývojové pracovní položky, například funkce, chyba, úkol nebo epik.
Popis

Tento atribut kategorizuje povahu vykonávané práce. Informace se obvykle spravují pomocí štítků nebo konkrétních šablon issue v GitHubu. Znalost typu práce je důležitá pro stanovení odpovídajících očekávání ohledně výkonnosti, protože oprava chyby může mít mnohem kratší očekávanou dobu průchodu než vývoj nové funkce.

Tento atribut umožňuje porovnávat různé typy práce. Pomáhá zjistit, zda se chyby opravují rychleji než nové funkce, nebo jak se rozdělují zdroje mezi technický dluh a nový vývoj. Jde o důležitou dimenzi dashboardu 'Průchodnost podle projektu a typu'.

Proč je to důležité

Kategorizuje pracovní položky a umožňuje porovnávat výkonnost i analyzovat, jak procesem procházejí různé typy práce, například chyby a funkce.

Kde data získat

Obvykle se odvozuje ze štítků GitHubu přiřazených issue nebo pull requestům. Je potřeba používat jednotnou konvenci štítků, například 'type:bug' nebo 'type:feature'.

Příklady
ChybaFunkceÚkolTechnický dluh
Autor
Author
Uživatel, který vytvořil issue, pull request nebo commit.
Popis

Autor je osoba, která vytvořila konkrétní položku v procesu vývoje. Autorem issue je například člověk, který nahlásil chybu nebo požádal o novou funkci. Autorem pull requestu je vývojář, který napsal kód.

Analýza autora pomáhá zjistit, odkud práce přichází. Analýza autorů hlášení chyb může například odhalit souvislosti s konkrétními týmy nebo funkcemi. V kombinaci s přiřazenou osobou lze také sledovat předávání práce.

Proč je to důležité

Určuje, kdo vytvořil pracovní položku nebo změnu kódu. To se hodí při analýze zdrojů přepracování, hlášení chyb a požadavků na nové funkce.

Kde data získat

Je k dispozici v objektu „user“ uvnitř hlavního objektu odpovědí API pro issues, pull requesty a commity. Pole se obvykle jmenuje „user.login“.

Příklady
sara.jonesmike.leeautomation-bot
Čekání při předání práce
HandoffWaitingTime
Vypočítaná doba, po kterou vývojová položka nečinně čeká mezi aktivitami různých osob.
Popis

Metrika měří dobu od dokončení jedné aktivity do zahájení další, ale pouze v případě, že se změní odpovědná osoba. Jde například o dobu mezi událostí „Kontrola vyžádána“ a událostí „Při kontrole požadovány změny“, kterou provedl jiný uživatel.

Tato metrika pomáhá odhalit nedostatky v komunikaci a problémy s koordinací. Podporuje dashboard „Efektivita kritických předání“ a KPI „Průměrná doba čekání při předání“. Dlouhé čekání při předávání práce často ukazuje na nedostatek zdrojů nebo neefektivní upozorňování.

Proč je to důležité

Odhaluje zpoždění způsobená nedostatečnou koordinací nebo nedostupností zdrojů při předávání práce mezi týmy či rolemi. Taková zpoždění bývají významným zdrojem neefektivity.

Kde data získat

Vypočítá se vyhledáním po sobě jdoucích aktivit, u kterých se změní atribut „Assignee“ nebo „User“, a změřením časového odstupu mezi nimi.

Příklady
PT1H15MP2DT4HPT25M
Číslo pull requestu
PullRequestNumber
Jedinečný identifikátor pull requestu souvisejícího s vývojovou položkou.
Popis

Pull request (PR) je návrh na sloučení sady změn kódu do konkrétní větve. Číslo pull requestu propojuje vývojové činnosti, například nahrání kódu a kontroly, s hlavní vývojovou položkou neboli issue.

Tento identifikátor je důležitý pro sledování integrace kódu a dílčího procesu kontroly v rámci celého vývojového cyklu. Umožňuje podrobně analyzovat kontrolu kódu, včetně její délky, opakovaného zpracování zjištěného při kontrole a četnosti sloučení. Propojuje fázi plánování (issue) s fází implementace (PR).

Proč je to důležité

Propojuje issues s konkrétními změnami kódu a procesem kontroly. Umožňuje podrobně analyzovat cyklus kontroly kódu a jeho vliv na celkovou dobu dodání.

Kde data získat

V mnoha odpovědích GitHub API je k dispozici v poli „number“ objektu „pull_request“. Lze ho získat také jako hlavní identifikátor z API Pull Requests.

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

Jde o metriku na úrovni případu. Vypočítá se jako rozdíl mezi první událostí, například „Issue vytvořeno“, a poslední událostí, například „Nasazení úspěšné“ nebo „Issue uzavřeno“, u jedné vývojové položky.

Tato metrika patří mezi nejdůležitější KPI pro měření celkové efektivity vývojového procesu. Přímo podporuje dashboard „Celková doba vývojového cyklu“ a KPI „Průměrná doba vývojového cyklu“. Zkrácení této doby bývá častým cílem zlepšování procesů.

Proč je to důležité

Vyjadřuje dobu od zahájení práce na vývojové položce po její dodání. Jde o důležité KPI pro měření celkové rychlosti a efektivity procesu.

Kde data získat

Vypočítá se na úrovni případu odečtením časového razítka první aktivity od časového razítka poslední aktivity.

Příklady
P5DT6H30MP14DT12HP1DT2H
Hash commitu
CommitHash
Jedinečný identifikátor (SHA) konkrétního commitu kódu.
Popis

Hash commitu je 40znakový hash SHA-1, který jednoznačně identifikuje commit v Gitu. Slouží jako trvalý identifikátor konkrétní verze kódu. Commity jsou základními jednotkami změn ve vývojovém procesu.

Hash commitu poskytuje velmi podrobnou úroveň sledovatelnosti. Analytici díky němu mohou přímo propojit událost procesu s přesnou změnou kódu. To se hodí při auditu, ověřování shody i podrobné analýze příčin incidentů v produkci.

Proč je to důležité

Umožňuje nejpodrobněji propojit krok procesu s konkrétní změnou kódu a zajistit úplnou sledovatelnost při auditu i ladění.

Kde data získat

Je k dispozici v datech událostí push („head_commit.id“) nebo prostřednictvím Commits API pro pull request či větev.

Příklady
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Jde o přepracování
IsRework
Logická hodnota, která je pravdivá, pokud aktivita představuje návrat do předchozí fáze procesu.
Popis

Tento příznak se nastaví na true, když se vývojová položka v procesu vrátí zpět. Může jít například o pull request, u kterého kontrola požaduje změny, nebo o znovuotevřené issue. Hodnota se odvozuje z posloupnosti aktivit.

Atribut je nezbytný pro vyčíslení plýtvání a neefektivity. Přímo podporuje dashboard „Smyčky přepracování a návratu“ a KPI „Míra přepracování“. Analytici mohou filtrovat podle „IsRework = true“ a zaměřit se na příčiny přepracování.

Proč je to důležité

Výslovně označuje aktivity, které představují přepracování. Usnadňuje tak jeho vyčíslení, zobrazení i analýzu příčin neefektivity procesu.

Kde data získat

Jde o odvozený atribut. Nejprve se stanoví standardní tok procesu a poté se označí každá aktivita, která se od něj odchyluje návratem do dřívější logické fáze.

Příklady
truefalse
Kontrolující
Reviewer
Uživatel požádal o kontrolu kódu v pull requestu.
Popis

Kontrolující je vývojář nebo člen týmu, který má za úkol prověřit změny kódu v pull requestu z hlediska kvality, správnosti a dodržení standardů. Pull request může mít více kontrolujících.

Tento atribut je nezbytný pro analýzu procesu kontroly kódu. Pomáhá odhalit úzká místa spojená s konkrétními kontrolujícími, porozumět rozložení jejich pracovní zátěže a měřit dobu, za kterou reagují na žádosti o kontrolu. Je také důležitý pro výpočet KPI „Průměrná doba cyklu kontroly kódu“.

Proč je to důležité

Určuje osoby zapojené do kontroly kvality. Umožňuje analyzovat jejich pracovní zátěž, zpoždění i celkovou efektivitu kontrol kódu.

Kde data získat

V GitHub API je k dispozici v poli „requested_reviewers“ nebo v objektu „user“ události kontroly pull requestu.

Příklady
alex.chenmaria.garciasenior-dev-team
Název větve
BranchName
Název větve Git, ve které byly provedeny změny kódu pro danou vývojovou položku.
Popis

Větev je samostatná vývojová linie, která umožňuje pracovat na nové funkci nebo opravě chyby, aniž by se zasahovalo do hlavní kódové základny. Název větve často obsahuje užitečné informace, například číslo issue nebo stručný popis práce.

Analýza názvů větví pomáhá porozumět strategii větvení a ověřit dodržování vývojových konvencí. Usnadňuje také propojení konkrétních commitů s vývojovou položkou, takže získáte úplný přehled o práci na kódu.

Proč je to důležité

Upřesňuje, o jakou vývojovou linii jde, a pomáhá dodržovat i analyzovat strategii větvení a konvence pro pojmenování.

Kde data získat

U událostí push je k dispozici v poli „ref“, v odpovědi API pro pull request pak v objektech „head“ a „base“.

Příklady
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Poslední aktualizace dat
LastDataUpdate
Časové razítko označující, kdy byla data tohoto záznamu naposledy obnovena ze zdrojového systému.
Popis

Tento atribut zaznamenává datum a čas poslední extrakce nebo aktualizace dat. Poskytuje informace o aktuálnosti analyzovaných dat. Liší se od časového razítka události, které zaznamenává, kdy k obchodní události došlo.

Při analýze pomáhá určit, jak aktuální je pohled na proces. Uživatelé díky němu poznají, zda pracují s daty v reálném čase, nebo se snímkem z určitého okamžiku. To je důležité pro provozní dashboardy a monitorování.

Proč je to důležité

Označuje aktuálnost dat, která je nezbytná pro to, aby analýzy a dashboardy vycházely z nejnovějších informací.

Kde data získat

Toto časové razítko se vytváří a přidává při extrakci, transformaci a načítání dat (ETL).

Příklady
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Prostředí nasazení
DeploymentEnvironment
Cílové prostředí pro nasazení, například „Staging“ nebo „Production“.
Popis

Tento atribut určuje, kam se kód nasazuje. Sledování nasazení do různých prostředí pomáhá porozumět celému cyklu od vývoje až po vydání do produkce.

Atribut umožňuje analyzovat dílčí proces nasazení. Lze pomocí něj měřit dobu potřebnou k přesunu kódu ze stagingu do produkce a sledovat úspěšnost nasazení v jednotlivých prostředích. Pomáhá určit, kdy je vývojová položka skutečně dokončená a předaná uživatelům.

Proč je to důležité

Rozlišuje vydání před produkcí od vydání do produkce. To je důležité pro měření skutečné doby uvedení na trh a analýzu způsobů nasazování.

Kde data získat

Tyto informace se získávají z GitHub Deployments API. Volání často spouštějí CI/CD pipeline nebo jiné automatizované procesy.

Příklady
developmentstagingproduction
Stav CI kontroly
CiCheckStatus
Stav automatické kontroly Continuous Integration (CI), například „úspěšná“ nebo „neúspěšná“.
Popis

Tento atribut zachycuje výsledek automatického sestavení, testů a kontrol, které se spouštějí nad změnami kódu v pull requestu. CI kontroly jsou v současných vývojových workflow důležitým kontrolním bodem kvality.

Analýza tohoto atributu pomáhá vyhodnotit účinnost automatického testování. Vysoký podíl neúspěšných kontrol může ukazovat na problémy se stabilitou kódu, sadou testů nebo vývojovým prostředím. Atribut podporuje aktivity „CI kontroly úspěšné“ a „CI kontroly neúspěšné“ a pomáhá analyzovat zpoždění způsobená nefunkčním sestavením.

Proč je to důležité

Ukazuje, zda automatické kontroly kvality proběhly úspěšně, nebo selhaly. Poskytuje tak přehled o kvalitě kódu a účinnosti CI pipeline.

Kde data získat

Získává se z pole „state“ nebo „conclusion“ objektů check run či status prostřednictvím GitHub Checks API nebo Statuses API.

Příklady
successfailurependingerror
Stav kontroly
ReviewState
Výsledek kontroly kódu v pull requestu, například „Schváleno“ nebo „Požadovány změny“.
Popis

Tento atribut zachycuje rozhodnutí kontrolujícího. Mezi běžné stavy patří „APPROVED“, který znamená, že je kód připraven ke sloučení, a „CHANGES_REQUESTED“, který značí, že je potřeba kód upravit. Dalšími stavy mohou být „COMMENTED“ nebo „PENDING“.

Atribut je důležitý pro analýzu opakovaného zpracování a kvality. Častý výskyt událostí „CHANGES_REQUESTED“ může ukazovat na problémy s kvalitou původního kódu nebo nejasné požadavky. Podporuje dashboard „Smyčky přepracování a návratu“ tím, že ukazuje, kdy je vývojová položka vrácena k úpravám.

Proč je to důležité

Přímo ukazuje opakované zpracování a kontrolní body kvality v procesu kontroly kódu. Pomáhá tak určit zdroje neefektivity a problémů s kvalitou.

Kde data získat

V GitHub API je k dispozici v poli „state“ objektu kontroly pull requestu, například v datech události „PullRequestReviewEvent“.

Příklady
APPROVEDCHANGES_REQUESTEDCOMMENTED
Stav položky
State
Aktuální stav issue nebo pull requestu, například 'open', 'closed' nebo 'merged'.
Popis

Tento atribut označuje celkový stav vývojové položky. Issue mají obvykle stavy 'open' a 'closed'. Pull requesty mohou mít stavy 'open', 'closed' a 'merged'. Atribut poskytuje přehled o postupu položky.

Při analýze se stav používá k rozlišení rozpracované a dokončené práce. Je nezbytný pro dashboardy, jako je 'Průběh aktivního vývoje', které sledují probíhající práci. Slouží také k určení konce procesu. Stav 'merged' nebo 'closed' může například označovat dokončení případu.

Proč je to důležité

Jasně ukazuje, zda se na pracovní položce právě pracuje, nebo zda je dokončená. To je základ pro analýzu životního cyklu a sledování rozpracované práce.

Kde data získat

Je přímo dostupný v poli 'state' v datech JSON pro issue a pull requesty z GitHub API.

Příklady
openclosedmerged
Štítky
Labels
Seznam značek nebo štítků přiřazených k issue či pull requestu pro účely kategorizace.
Popis

Štítky v GitHubu umožňují flexibilně doplňovat metadata k issues a pull requestům. Mohou označovat prioritu, typ práce, komponenty, týmy nebo stav. Seznam štítků poskytuje bohatý, nestrukturovaný kontext.

Konkrétní atributy, například priorita a typ, se odvozují ze štítků. Uchování celého seznamu se ale hodí pro průběžnou analýzu a hledání dalších vzorců v procesu. Umožňuje flexibilně filtrovat a členit případy podle libovolné kombinace štítků.

Proč je to důležité

Poskytuje flexibilní a bohatý zdroj metadat pro kategorizaci pracovních položek a umožňuje jejich analýzu z různých hledisek.

Kde data získat

V datech JSON pro issues a pull requesty z GitHub API je k dispozici jako pole „labels“. Každá položka v poli je objekt s polem „name“.

Příklady
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Zdrojový systém
SourceSystem
Systém, ze kterého byla extrahována data o vývojovém procesu.
Popis

Tento atribut označuje původ dat události. V tomto procesu bude jeho hodnota vždy 'GitHub'. Ve složitějším prostředí, kde vývojové aktivity probíhají ve více systémech, například Jira pro plánování, GitHub pro kód a Jenkins pro nasazení, toto pole rozlišuje zdroj jednotlivých událostí.

Při analýze pomáhá dohledat původ dat při ověřování a řešení problémů. Umožňuje také analyzovat procesy probíhající na různých platformách a poskytuje jasný kontext pro každou aktivitu.

Proč je to důležité

Označuje původ dat, což je nezbytné pro jejich ověření i analýzu procesů, které mohou probíhat ve více propojených systémech.

Kde data získat

Obvykle jde o statickou hodnotu přidanou při extrakci, transformaci a načítání dat (ETL), která označuje zdroj záznamů.

Příklady
GitHubGitHub Enterprise
Povinné Doporučené Volitelné

Aktivity v životním cyklu vývoje softwaru

Zachyťte tyto důležité kroky a milníky v záznamu událostí. Pomohou vám přesně odhalit průběh procesu i úzká místa.
6 Doporučené 7 Volitelné
Aktivita Popis
CI kontroly úspěšné
Označuje úspěšné dokončení automatických kontrol, například sestavení, jednotkových testů nebo statické analýzy kódu v pull requestu. Událost se odvozuje ze stavu kontrol hlášeného systémy, jako je GitHub Actions.
Proč je to důležité

Tato automatická kontrolní fáze pomáhá zajistit stabilitu kódu. Neúspěšné kontroly nebo dlouhá doba jejich běhu mohou představovat významná úzká místa v procesu dodání.

Kde data získat

Událost se odvozuje z GitHub Checks API nebo Statuses API. Spuštění kontroly nebo aktualizace stavu hlásí 'success' nebo 'completed' se závěrem 'success'.

Zachycení

V Checks API sledujte u příslušných sad kontrol závěr 'success'.

Typ události inferred
Issue uzavřeno
Vývojová položka je považována za dokončenou a příslušné issue se formálně uzavře. Může k tomu dojít automaticky po sloučení propojeného pull requestu nebo může issue ručně uzavřít člen týmu.
Proč je to důležité

Tato aktivita představuje jednoznačný konec procesu pro danou vývojovou položku. Je nezbytná pro výpočet celkové doby průchodu.

Kde data získat

Jde o explicitní událost zachycenou v proudu událostí z GitHub Issues API. Typ události je 'closed'.

Zachycení

Pomocí webhooků nebo pravidelného dotazování API sledujte u issue událost 'closed'.

Typ události explicit
Issue vytvořeno
Označuje začátek životního cyklu vývojové položky, tedy formální založení úkolu, chyby nebo požadavku na funkci. Tato událost se zaznamená, když uživatel vytvoří nové issue v repozitáři GitHubu.
Proč je to důležité

Jde o hlavní počáteční aktivitu procesu. Je nezbytná pro měření celkové doby vývoje a pochopení toho, odkud práce přichází.

Kde data získat

Jde o explicitní událost zachycenou v proudu událostí z GitHub Issues API. Typ události pro dané číslo issue bývá 'opened'.

Zachycení

Pomocí webhooků nebo pravidelného dotazování API sledujte u issue událost 'opened'.

Typ události explicit
Pull request otevřen
Označuje, že je první část kódu připravena ke kontrole a začlenění. Vývojář vytvoří pull request (PR), kterým navrhne začlenění změn z vývojové větve do hlavní větve. Jde o explicitní událost v GitHubu.
Proč je to důležité

Jde o důležitý milník, který uzavírá počáteční fázi vývoje a zahajuje proces kontroly a začlenění změn. Díky němu lze samostatně analyzovat dobu vývoje a dobu kontroly.

Kde data získat

Událost se zachytí z proudu událostí GitHub Pull Request API nebo pomocí webhooků. Akce události je 'opened'.

Zachycení

Pomocí webhooků nebo pravidelného dotazování API sledujte u pull requestu akci 'opened'.

Typ události explicit
Pull request schválen
Kontrolující formálně schválil změny v pull requestu, což znamená, že splňují požadavky na kvalitu a funkčnost. Událost se zaznamená, když kontrolující odešle revizi se stavem 'approve'.
Proč je to důležité

Jde o důležitou kontrolní fázi a významný milník před sloučením změn. Doba od vytvoření PR do dosažení tohoto stavu je důležitým KPI efektivity procesu kontroly.

Kde data získat

Událost se zachytí z GitHub Pull Request API nebo pomocí webhooků, když je revize odeslána se stavem 'APPROVED'.

Zachycení

Ve filtrech událostí odeslání revize pull requestu vyberte stav 'APPROVED'.

Typ události explicit
Pull request sloučen
Schválené změny kódu z pull requestu jsou oficiálně začleněny do cílové větve, například main nebo develop. Jde o explicitní závěrečnou akci pull requestu, která začlení nový kód.
Proč je to důležité

Jde o důležitý milník, který označuje dokončení vývoje a kontroly. Pro mnoho týmů je to poslední krok před automatickým nasazením.

Kde data získat

Událost se zachytí z proudu událostí GitHub Pull Request API nebo pomocí webhooků. Akce události je 'closed' a atribut 'merged' v datech pull requestu má hodnotu true.

Zachycení

Sledujte u pull requestu akci 'closed' a ověřte, zda má příznak 'merged' hodnotu true.

Typ události explicit
CI kontroly neúspěšné
Označuje neúspěšnou automatickou kontrolu, například chybu při sestavení nebo neúspěšný jednotkový test kódu v pull requestu. Událost se odvozuje z chybového stavu hlášeného systémem, jako je GitHub Actions.
Proč je to důležité

Tato aktivita upozorňuje na technické problémy s kvalitou, které vyžadují zásah vývojáře a vedou k opakovanému předělávání. Analýza četnosti chyb může pomoci zlepšit místní testování nebo kvalitu kódu.

Kde data získat

Událost se odvozuje z GitHub Checks API nebo Statuses API. Spuštění kontroly nebo aktualizace stavu hlásí 'failure' nebo 'completed' se závěrem 'failure'.

Zachycení

V Checks API sledujte u příslušných sad kontrol závěr 'failure'.

Typ události inferred
Issue znovu otevřeno
Dříve uzavřené issue se znovu aktivuje, obvykle proto, že oprava nebyla dostatečná nebo se objevila regrese. Tato explicitní událost znovu zahajuje životní cyklus vývojové položky.
Proč je to důležité

Jde o výrazný signál opakovaného předělávání, který může ukazovat na chybu, jež unikla do produkce, nebo na neúplnou opravu. Četnost této události je důležitým ukazatelem celkové kvality softwaru.

Kde data získat

Jde o explicitní událost zachycenou v proudu událostí z GitHub Issues API. Typ události je 'reopened'.

Zachycení

Pomocí webhooků nebo pravidelného dotazování API sledujte u issue událost 'reopened'.

Typ události explicit
Kód odeslán do PR
Označuje aktualizaci kódu předloženého ke kontrole, ať už jde o součást původního PR, nebo o reakci na připomínky. Událost se zaznamená pokaždé, když je do větve spojené s otevřeným pull requestem odeslán nový commit.
Proč je to důležité

Sledování těchto událostí je důležité pro odhalení opakovaného předělávání. Více odeslání kódu po kontrole znamená, že byly nutné změny, které prodlužují celkovou dobu průchodu.

Kde data získat

Jde o explicitní událost na časové ose pull requestu, často označenou jako přidání commitu. Lze ji zachytit pomocí webhooku 'push' nebo sledováním commitů spojených s PR.

Zachycení

Sledujte události 'push' ve větvi spojené s otevřeným pull requestem.

Typ události explicit
Nasazení úspěšné
Změny kódu byly úspěšně nasazeny do konkrétního prostředí, například staging nebo produkce. Událost se obvykle zachytí přes GitHub Deployments API. Nasazení často spouští GitHub Action po sloučení změn.
Proč je to důležité

Označuje přechod kódu z repozitáře do živého prostředí. Jeho sledování je nezbytné pro měření celkové doby od nápadu po nasazení do produkce.

Kde data získat

Událost se zachytí přes Deployments API. Externí služba nebo GitHub Action vytvoří nasazení a poté aktualizuje jeho stav na 'success'.

Zachycení

Pomocí webhooků sledujte události stavu nasazení a hledejte stav 'success'.

Typ události inferred
Při revizi požadovány změny
Kontrolující dokončil revizi kódu a rozhodl, že před schválením pull requestu je nutné provést úpravy. Svou revizi formálně odešle se stavem 'request_changes'.
Proč je to důležité

Tato událost výslovně signalizuje opakované předělávání. Analýza její četnosti pomáhá odhalit problémy s kvalitou, nejasné požadavky nebo oblasti, ve kterých je potřeba školení vývojářů.

Kde data získat

Událost se zachytí z GitHub Pull Request API nebo pomocí webhooků, když je revize odeslána se stavem 'CHANGES_REQUESTED'.

Zachycení

Ve filtrech událostí odeslání revize pull requestu vyberte stav 'CHANGES_REQUESTED'.

Typ události explicit
Větev vytvořena
Označuje začátek aktivní práce na issue, kdy vývojář vytvoří novou větev z hlavní větve kódu. Událost se zaznamená při odeslání nové větve do repozitáře. Její název často obsahuje číslo issue.
Proč je to důležité

Označuje přechod od plánování k aktivnímu programování. Doba mezi vytvořením issue a touto událostí pomáhá měřit, jak rychle se vývojář práce ujme, a odhalit počáteční prodlevy ve frontě.

Kde data získat

Událost lze zachytit přes GitHub Git API nebo pomocí webhooků sledujících události 'create' typu 'branch'. Název větve je často nutné propojit s issue podle zavedené konvence, například 'feature/issue-123'.

Zachycení

Zpracujte webhookové události 'create' pro nové větve a přiřaďte je k issue.

Typ události explicit
Vyžádána revize
Autor pull requestu formálně požádá konkrétní členy týmu nebo týmy o kontrolu kódu. Tato akce v rozhraní nebo API GitHubu odešle požadovaným kontrolujícím oznámení.
Proč je to důležité

Tato aktivita označuje oficiální předání práce ke kontrole kódu. Doba od této události do odeslání revize pomáhá měřit rychlost reakce kontrolujících a odhalit možná úzká místa.

Kde data získat

Událost se zachytí z proudu událostí GitHub Pull Request API nebo pomocí webhooků. Akce události je 'review_requested'.

Zachycení

Sledujte u pull requestu akci 'review_requested'.

Typ události explicit
Doporučené Volitelné

Návody k extrakci dat

Jak získat data z GitHubu

Chcete začít?

Pomocí této šablony připravte data a začněte zlepšovat životní cyklus vývoje softwaru. Odhalte neefektivní místa a zkraťte cestu k rychlejšímu a plynulejšímu vydávání.

Zlepšete SDLC: rychle odhalte neefektivní místa

Zkraťte dobu cyklu o 30 % a zjednodušte vývoj v GitHubu.

Začněte se zkušební verzí zdarma

Platební kartu nepotřebujete. Nastavení zabere jen několik minut.