Šablona dat pro životní cyklus vývoje softwaru
Šablona dat pro životní cyklus vývoje softwaru
- Doporučené atributy ke sběru
- Aktivity, které stojí za to sledovat
- Pokyny k extrakci dat
Atributy životního cyklu vývoje softwaru
| 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
|
|||
Aktivity v životním cyklu vývoje softwaru
| 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
|
|||
Návody k extrakci dat
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.
Platební kartu nepotřebujete. Nastavení zabere jen několik minut.