Szoftverfejlesztési életciklus: adatsablon

GitHub
Szoftverfejlesztési életciklus: adatsablon

Szoftverfejlesztési életciklus: adatsablon

Ez a sablon útmutatást ad a GitHubból származó szoftverfejlesztési életciklus-adatok gyűjtéséhez és előkészítéséhez. Megtalálja benne a javasolt attribútumokat, a követendő tevékenységeket és az adatok kinyeréséhez szükséges gyakorlati tudnivalókat. Használja az útmutatót pontos eseménynapló összeállításához, amelyre hatékony folyamatelemzés és -fejlesztés épülhet.
  • Javasolt attribútumok
  • Követendő tevékenységek
  • Útmutató az adatok kinyeréséhez
Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

A szoftverfejlesztési életciklus attribútumai

Ezeket az adatmezőket javasoljuk felvenni az eseménynaplóba a szoftverfejlesztési életciklus részletes elemzéséhez és a folyamat feltárásához.
3 Kötelező 5 Javasolt 15 Nem kötelező
Név Leírás
Fejlesztési feladat
DevelopmentItemId
Egy fejlesztési munkaegység egyedi azonosítója, például egy funkcióé, hibajavításé vagy feladaté. Ez az elsődleges ügyazonosító.
Leírás

A fejlesztési feladat azonosítója a munkaelem útját követi a létrehozástól a végső telepítésig. Egyetlen folyamatpéldányba kapcsolja össze a hozzá tartozó tevékenységeket, például a branch létrehozását, a commitokat, a pull requesteket, az ellenőrzéseket és a telepítéseket.

Az elemzés során ezzel az azonosítóval számítható ki a fejlesztési feladat teljes ciklusideje. Segítségével rekonstruálható egy funkció vagy hibajavítás teljes útja, így munkaelemenként részletesen elemezhetők a szűk keresztmetszetek, az ismételt munkafázisok és a folyamat eltérései.

Miért fontos?

Ez a process mining alapvető azonosítója: egyetlen ügybe kapcsolja össze az összes kapcsolódó fejlesztési eseményt, így pontosan ábrázolható és elemezhető a teljes szoftverfejlesztési életciklus.

Hol szerezhető be?

Ez jellemzően a GitHubban szereplő issue száma vagy pull request száma. Az issue-hoz vagy pull requesthez kapcsolódó webhookesemények, illetve API-válaszok adatcsomagjának 'number' mezőjéből nyerhető ki.

Példák
101PR-2345TASK-812
Kezdési idő
EventTimestamp
Az a pontos dátum és időpont, amikor egy adott fejlesztési tevékenység vagy esemény történt.
Leírás

Ez az időbélyeg jelöli a tevékenység kezdetét. A fejlesztési feladatok folyamatának rekonstruálásához időrendbe kell állítani az eseményeket. Az időbélyegek sorrendje és a köztük eltelt idő alapján elemezhető a folyamat teljesítménye.

Az elemzés során ez az attribútum szükséges minden időalapú mutató kiszámításához, beleértve a ciklusidőt, a feldolgozási időt és a várakozási időt. Segítségével azonosíthatók a lépések közötti késések, és rendelkezésre állnak a szűk keresztmetszetek elemzéséhez, valamint a teljesítmény dashboardokon való nyomon követéséhez szükséges adatok.

Miért fontos?

Ez az időbélyeg elengedhetetlen az események helyes sorrendbe állításához és a teljesítménymutatók, például a ciklusidő és a szűk keresztmetszetek időtartamának kiszámításához.

Hol szerezhető be?

A GitHub API-k és webhookok JSON-adatcsomagjaiban jellemzően a 'created_at' vagy az 'updated_at' mező tartalmazza. Ilyen adatcsomagok többek között az issue-khoz, pull requestekhez és commitokhoz tartoznak.

Példák
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Tevékenység
ActivityName
A szoftverfejlesztési életciklus során végrehajtott konkrét esemény vagy feladat neve.
Leírás

A tevékenység neve a fejlesztési folyamat egyetlen lépését jelöli, például: 'Issue létrehozva', 'Kód feltöltve a PR-hez', 'Pull request jóváhagyva' vagy 'Telepítés sikeres'. Ezek az események alkotják a fejlesztési feladat teljes folyamatának lépéseit.

Ez az attribútum alapvető a process miningben, mert ebből épül fel a folyamattérkép. A tevékenységek sorrendjének, gyakoriságának és időtartamának elemzésével feltárható a tényleges folyamat, azonosíthatók a gyakori útvonalak és az eltérések, valamint a szűk keresztmetszetek.

Miért fontos?

Ez az attribútum adja a folyamattérkép alapját, és lehetővé teszi a fejlesztési életciklus eseményei sorrendjének ábrázolását és elemzését.

Hol szerezhető be?

A webhookesemények adatcsomagjának 'action' mezőjéből (például issue esetén 'opened' vagy 'closed'), illetve magából az eseménytípusból (például 'PushEvent' vagy 'PullRequestReviewEvent') származik.

Példák
Hiba vagy feladat létrehozvaPull request megnyitvaKód feltöltve a PR-hezEllenőrzés kérésePull request beolvasztva
Befejezési idő
EndTimestamp
Az a pontos dátum és időpont, amikor egy adott fejlesztési tevékenység vagy esemény befejeződött.
Leírás

A befejezési időbélyeg jelöli a tevékenység végét. A GitHub-események közül sok azonnali, például az 'Issue létrehozva', de egyes tevékenységeknek mérhető időtartamuk van, például egy CI-ellenőrzés futása. A befejezési és a kezdési idő különbsége adja a tevékenység feldolgozási idejét.

Ezzel az attribútummal számítható ki a 'ProcessingTime' mutató, amely megmutatja, mennyi aktív munkaidőt igényelnek az egyes feladatok, például a kódellenőrzések vagy az automatizált ellenőrzések. A feldolgozási idők elemzésével azonosíthatók a túl sok időt igénylő, nem hatékony tevékenységek.

Miért fontos?

Lehetővé teszi a tevékenységek pontos feldolgozási idejének kiszámítását, így elkülöníthető az aktív munkaidő és a tétlen várakozás.

Hol szerezhető be?

Az ellenőrzési futások objektumaiban a 'completed_at' mező tartalmazhatja, vagy egy későbbi, logikusan lezáró esemény időbélyegéből számítható ki.

Példák
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Fejlesztési feladat típusa
DevelopmentItemType
A fejlesztési munkaelem besorolása, például funkció, hiba, feladat vagy epic.
Leírás

Ez az attribútum a végzett munka jellegét kategorizálja. Az adatokat jellemzően a GitHub-címkék vagy az issue-sablonok alapján kezelik. A munka típusának ismerete elengedhetetlen a megfelelő teljesítményelvárások meghatározásához, hiszen egy hibajavítás várható ciklusideje jóval rövidebb lehet, mint egy új funkcióé.

Az attribútum lehetővé teszi a különböző munkatípusok összehasonlító elemzését. Segítségével megvizsgálható, hogy a hibajavítások gyorsabban haladnak-e az új funkcióknál, illetve hogyan oszlanak meg az erőforrások a technikai adósság kezelése és az új fejlesztések között. A „Projekt és típus szerinti átbocsátás” dashboard egyik fontos dimenziója.

Miért fontos?

Kategorizálja a munkaelemeket, így összehasonlítható a teljesítmény, és elemezhető, hogyan haladnak át a folyamaton a különböző munkatípusok, például a hibák és a funkciók.

Hol szerezhető be?

Jellemzően az issue-khoz vagy pull requestekhez rendelt GitHub-címkékből származik. Következetes címkézési szabályra van szükség, például 'type:bug' vagy 'type:feature'.

Példák
HibaFunkcióFeladatTechnikai adósság
Hozzárendelt felhasználó
Assignee
A fejlesztési feladat vagy egy konkrét tevékenység, például egy pull request ellenőrzésének elvégzésére kijelölt felhasználó vagy fejlesztő.
Leírás

Ez az attribútum azonosítja az adott szakaszban a munkáért felelős személyt. Lehet az issue felelőse, a pull request szerzője vagy a kódellenőrzésre felkért ellenőr. A felelős követése segít megérteni az erőforrások elosztását és a munkaterhelést.

Az elemzés során ezzel az attribútummal nyomon követhető a fejlesztők munkaterhelése, feltárhatók az erőforrásokhoz kapcsolódó szűk keresztmetszetek, és elemezhető a csapattagok közötti átadások hatékonysága. A dashboardok a felelős szerint szűrhetők, így értékelhető az egyéni vagy csapatteljesítmény, és kiegyensúlyozottan osztható el a munka.

Miért fontos?

Elengedhetetlen a fejlesztők munkaterhelésének, a csapat teljesítményének és a csapattagok közötti átadások hatékonyságának elemzéséhez.

Hol szerezhető be?

A GitHub API issue-khoz, pull requestekhez és ellenőrzési eseményekhez tartozó JSON-adatcsomagjaiban az 'assignee' vagy a 'user' objektumban található.

Példák
john.doejane.smithdev-team-lead
Prioritás
Priority
A fejlesztési feladathoz rendelt prioritási szint, például 'High', 'Medium' vagy 'Low'.
Leírás

A prioritás a munkaelem sürgősségét vagy üzleti jelentőségét jelzi. A GitHubban nincs külön prioritásmező, ezért ezt általában címkékkel kezelik, például „P1-High” vagy „P2-Medium” értékkel. Az adatok megbízható kinyeréséhez egységes címkézési szabályokra van szükség.

Ez az attribútum elengedhetetlen a prioritásalapú folyamatáramlás elemzéséhez. Segítségével az elemzők ellenőrizhetik, hogy a magas prioritású elemek valóban gyorsabban haladnak-e, mint az alacsony prioritásúak, és mérhetik a ciklusidő prioritás szerinti eltérését. Az elemzés a priorizálási folyamat eredményességének értékelését is segíti.

Miért fontos?

Segítségével megvizsgálható, hogy a magas prioritású elemek gyorsabban haladnak-e, mint az alacsonyabb prioritásúak, így ellenőrizhető a priorizálási stratégia eredményessége.

Hol szerezhető be?

Az issue-khoz vagy pull requestekhez rendelt GitHub-címkékből származik. A prioritáscímkékhez egységes elnevezési szabályra van szükség.

Példák
MagasKözepesAlacsonyKritikus
Tároló
RepositoryName
Annak a kódtárolónak a neve, amelyben a fejlesztési tevékenység zajlik.
Leírás

A tároló projekt- vagy termékazonosítóként szolgál: egy adott alkalmazás vagy összetevő kódját, issue-it és pull requestjeit tartalmazza. Segítségével külön vizsgálhatók és összehasonlíthatók a különböző termékek vagy csapatok fejlesztési folyamatai.

Az elemzés során ezzel az attribútummal szűrhetők és hasonlíthatók össze a különböző projektek folyamatteljesítményei. Segít megválaszolni például azt, hogy melyik projekt ciklusideje a leghosszabb, vagy hogyan viszonyul egymáshoz az A és a B projekt hibajavítási folyamata. A „Projekt és típus szerinti átbocsátás” dashboard egyik alapvető attribútuma.

Miért fontos?

Lehetővé teszi a fejlesztési folyamatok projektek, termékek vagy csapatok szerinti bontását és összehasonlítását, így célzottabb elemzést végezhet.

Hol szerezhető be?

Szinte minden GitHub-webhook és API adatcsomagjában megtalálható a 'repository' objektumban. A mező neve jellemzően 'repository.full_name' vagy 'repository.name'.

Példák
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Ág neve
BranchName
Annak a Git-ágnak a neve, amelyben a fejlesztési elemhez tartozó kódmódosítások készültek.
Leírás

Az ág a fejlesztés önálló vonala. Új funkció vagy hibajavítás készülhet rajta anélkül, hogy az érintené a fő kódbázist. Az ág neve gyakran hasznos információt tartalmaz, például az issue számát vagy a munka rövid leírását.

Az ágak nevének elemzése segít megérteni az elágazási stratégiát és ellenőrizni a fejlesztési szabályok betartását. A konkrét kódcommitokat is összekapcsolja a fejlesztési elemmel, így teljesebb képet ad a kódolási tevékenységről.

Miért fontos?

Megadja a fejlesztési ág kontextusát, és segít az elágazási stratégiák, valamint az elnevezési szabályok betartásának ellenőrzésében és elemzésében.

Hol szerezhető be?

Push eseményeknél a „ref” mezőben, pull request API-válaszban pedig a „head” és „base” objektumokban érhető el.

Példák
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Átadás miatti várakozási idő
HandoffWaitingTime
Az az idő, amelyet egy fejlesztési elem különböző személyek által végzett tevékenységek között várakozással tölt.
Leírás

Ez a mutató két tevékenység befejezése és kezdete közötti időt méri, de csak akkor, ha közben megváltozik a felelős személye. Például a „Review Requested” esemény és egy másik felhasználó által végzett „Changes Requested in Review” esemény közötti időt.

A mutató segít feltárni a kommunikációs hiányosságokat és az egyeztetési problémákat. Támogatja a „Critical Handoff Efficiency” dashboardot és az „Average Handoff Waiting Time” KPI-t. Az átadási pontokon tapasztalható hosszú várakozás gyakran erőforráshiányra vagy nem hatékony értesítési folyamatokra utal.

Miért fontos?

Rámutat a különböző csapatok vagy szerepkörök közötti átadás során fellépő, gyenge koordináció vagy az erőforrások elérhetetlensége okozta késésekre. Ezek gyakran jelentős hatékonyságvesztést okoznak.

Hol szerezhető be?

Az egymást követő tevékenységek közül azokat kell azonosítani, amelyeknél megváltozik az „Assignee” vagy a „User” attribútum, majd meg kell mérni a köztük eltelt időt.

Példák
PT1H15MP2DT4HPT25M
CI-ellenőrzés állapota
CiCheckStatus
Az automatizált Continuous Integration (CI) ellenőrzés állapota, például „sikeres” vagy „sikertelen”.
Leírás

Ez az attribútum a pull request kódmódosításain futtatott automatizált buildelés, tesztelés és vizsgálatok eredményét mutatja. A CI-ellenőrzések a modern fejlesztési munkafolyamatok fontos minőségi ellenőrzési pontjai.

Az attribútum elemzésével felmérhető az automatizált tesztelés eredményessége. A magas hibaarány a kód stabilitásával, a tesztkészlettel vagy a fejlesztési környezettel kapcsolatos problémára utalhat. Támogatja a „CI Checks Passed” és a „CI Checks Failed” tevékenységek elemzését, és segít feltárni a hibás buildelések okozta késéseket.

Miért fontos?

Jelzi, hogy az automatizált minőségi ellenőrzések sikeresek vagy sikertelenek voltak, így képet ad a kód minőségéről és a CI-folyamat eredményességéről.

Hol szerezhető be?

A GitHub Checks vagy Statuses API-n keresztül, a check run vagy status objektum „state” vagy „conclusion” mezőjéből kérhető le.

Példák
successfailurependingerror
Címkék
Labels
Az issue-hoz vagy pull requesthez kategorizálás céljából rendelt címkék listája.
Leírás

A GitHub-címkék rugalmasan használhatók metaadatok hozzáadására az issue-khoz és pull requestekhez. Jelezhetik a prioritást, a munka típusát, az érintett összetevőket, a csapatot vagy az állapotot. A címkék teljes listája sokféle, strukturálatlan kontextust ad.

A Prioritás és a Típus attribútum például címkékből származik, de a teljes lista megőrzése hasznos lehet az eseti elemzésekhez és más folyamatminták feltárásához. A címkék tetszőleges kombinációja alapján szűrhetők és csoportosíthatók az esetek.

Miért fontos?

Rugalmas és részletes metaadatforrást biztosít a munkaelemek kategorizálásához, így többféle szempont szerinti elemzést tesz lehetővé.

Hol szerezhető be?

A GitHub API issue-kra és pull requestekre vonatkozó JSON-adatában a „labels” tömbként érhető el. A tömb minden eleme egy „name” mezőt tartalmazó objektum.

Példák
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Commit hash
CommitHash
Egy adott kódcommit egyedi azonosítója (SHA).
Leírás

A commit hash egy 40 karakteres SHA-1 hash, amely egyedileg azonosítja a Gitben lévő commitot. Állandó azonosítóként szolgál a kód egy adott verziójához. A commitok a fejlesztési folyamat változtatásainak legkisebb egységei.

A commit hash részletes nyomon követést tesz lehetővé. Segítségével az elemzők közvetlenül összekapcsolhatják a folyamat eseményét a pontos kódmódosítással. Ez különösen hasznos lehet auditáláskor, a megfelelés ellenőrzésekor vagy az éles környezetben fellépő problémák okának részletes feltárásakor.

Miért fontos?

A folyamatlépést a pontos kódmódosításhoz kapcsolja, így auditáláskor és hibakereséskor is teljes nyomon követhetőséget biztosít.

Hol szerezhető be?

Push események adatában („head_commit.id”), illetve a pull requesthez vagy ághoz tartozó Commits API-n keresztül érhető el.

Példák
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Ellenőrzés állapota
ReviewState
A pull request kódellenőrzésének eredménye, például „Jóváhagyva” vagy „Módosítás szükséges”.
Leírás

Ez az attribútum rögzíti az ellenőrző döntését. A gyakori állapotok közé tartozik az „APPROVED”, amely azt jelzi, hogy a kód készen áll a beolvasztásra, valamint a „CHANGES_REQUESTED”, amely további munkát jelez. További állapot lehet a „COMMENTED” vagy a „PENDING”.

Ez az attribútum fontos az utómunka és a minőség elemzéséhez. A „CHANGES_REQUESTED” események gyakori előfordulása a kezdeti kódminőség problémáira vagy a nem egyértelmű követelményekre utalhat. A „Rework and Regression Loops” dashboardon láthatóvá teszi, mikor küldenek vissza egy fejlesztési elemet módosításra.

Miért fontos?

Közvetlenül jelzi az utómunka-ciklusokat és a minőségi ellenőrzési pontokat a kódellenőrzési folyamatban, így segít feltárni a hatékonysági és minőségi problémák forrását.

Hol szerezhető be?

A GitHub API pull request ellenőrzési objektumának „state” mezőjében érhető el, például egy „PullRequestReviewEvent” adatában.

Példák
APPROVEDCHANGES_REQUESTEDCOMMENTED
Ellenőrző
Reviewer
Az a felhasználó, akitől kódellenőrzést kértek egy pull requesthez.
Leírás

Az ellenőrző olyan fejlesztő vagy csapattag, akit egy pull request kódmódosításainak vizsgálatára jelölnek ki. Ellenőrzi a kód minőségét, helyességét és a szabványoknak való megfelelését. Egy pull requesthez több ellenőrző is tartozhat.

Ez az attribútum elengedhetetlen a kódellenőrzési folyamat elemzéséhez. Segít feltárni az egyes ellenőrzőkhöz kapcsolódó szűk keresztmetszeteket, megérteni az ellenőrzési feladatok eloszlását, és mérni, mennyi idő alatt válaszolnak az ellenőrzők a kérésekre. Az „Átlagos kódellenőrzési ciklusidő” KPI kiszámításához is szükséges.

Miért fontos?

Azonosítja a minőségbiztosításban részt vevő személyeket, így elemezhető az ellenőrzési feladatok terhelése, a késések és a kódellenőrzések általános hatékonysága.

Hol szerezhető be?

A GitHub API-ban a „requested_reviewers” tömbben vagy a pull request ellenőrzési eseményének „user” objektumában érhető el.

Példák
alex.chenmaria.garciasenior-dev-team
Fejlesztési ciklusidő
DevelopmentCycleTime
A fejlesztési elem létrehozásától a végső telepítéséig vagy lezárásáig eltelt teljes idő.
Leírás

Esetenként számított mutató: egy fejlesztési elem első eseménye, például az „Issue Created”, és utolsó eseménye, például a „Deployment Succeeded” vagy az „Issue Closed” közötti időt méri.

Ez a fejlesztési folyamat teljes hatékonyságának egyik legfontosabb KPI-ja. Közvetlenül támogatja az „Overall Development Cycle Time” dashboardot és az „Average Development Cycle Time” KPI-t. A folyamatfejlesztési kezdeményezések egyik gyakori célja ennek a mutatónak a csökkentése.

Miért fontos?

A fejlesztési elem teljes piacra jutási idejét mutatja, ezért fontos KPI a folyamat sebességének és hatékonyságának méréséhez.

Hol szerezhető be?

Esetenként számítják ki: az első tevékenység időbélyegét kivonják az utolsó tevékenység időbélyegéből.

Példák
P5DT6H30MP14DT12HP1DT2H
Forrásrendszer
SourceSystem
Az a rendszer, amelyből a fejlesztési folyamat adatait kinyerték.
Leírás

Ez az attribútum azonosítja az eseményadatok forrását. Ennél a folyamatnál az értéke minden esetben 'GitHub'. Összetettebb környezetben, ahol a fejlesztési tevékenységek több rendszert érintenek, például a tervezéshez Jirát, a kódhoz GitHubot, a telepítéshez pedig Jenkinst használnak, ez a mező különbözteti meg az események forrását.

Az elemzés során segít visszakeresni az adatok eredetét, ami hasznos az ellenőrzéshez és a hibakereséshez. A több platformon átívelő folyamatok elemzését is lehetővé teszi, és egyértelmű kontextust ad az egyes tevékenységekhez.

Miért fontos?

Azonosítja az adatok forrását, ami elengedhetetlen az adatok ellenőrzéséhez és a több integrált rendszeren átívelő folyamatok elemzéséhez.

Hol szerezhető be?

Ez jellemzően az adatkinyerés, -átalakítás és -betöltés (ETL) során hozzáadott, állandó érték, amely megjelöli a rekordok forrását.

Példák
GitHubGitHub Enterprise
Munkaelem állapota
State
Az issue vagy pull request aktuális állapota, például 'open', 'closed' vagy 'merged'.
Leírás

Ez az attribútum a fejlesztési feladat általános állapotát jelzi. Az issue-k jellemző állapotai az 'open' és a 'closed'. A pull requestek állapota 'open', 'closed' vagy 'merged' lehet. Ez pillanatképet ad a feladat előrehaladásáról.

Az elemzés során az állapot alapján különíthető el a folyamatban lévő és a befejezett munka. Elengedhetetlen például az „Aktív fejlesztés előrehaladása” dashboardhoz, amely a folyamatban lévő munkát követi. A folyamat végének meghatározására is használható: a 'merged' vagy 'closed' állapot például jelezheti az ügy lezárását.

Miért fontos?

Egyértelműen jelzi, hogy a munkaelem folyamatban van-e vagy befejeződött. Ez alapvető a folyamat életciklusának elemzéséhez és az aktív munka nyomon követéséhez.

Hol szerezhető be?

Közvetlenül elérhető a GitHub API issue-khoz és pull requestekhez tartozó JSON-adatcsomagjainak 'state' mezőjében.

Példák
openclosedmerged
Pull request száma
PullRequestNumber
A fejlesztési elemhez tartozó pull request egyedi azonosítója.
Leírás

A pull request (PR) kódmódosítások egy adott ágba történő beolvasztására tett javaslat. A pull request száma összekapcsolja a fejlesztési tevékenységeket, például a kód feltöltését és az ellenőrzéseket az elsődleges fejlesztési elemmel vagy issue-val.

Ez az azonosító nélkülözhetetlen a kódintegráció és az ellenőrzési alfolyamat nyomon követéséhez a teljes fejlesztési életcikluson belül. Részletesen elemezhető vele a kódellenőrzési folyamat, többek között az ellenőrzés ideje, az ellenőrzés során feltárt utómunka-ciklusok és a beolvasztási arány. Összeköti a tervezési szakaszt (issue) a megvalósítási szakasszal (PR).

Miért fontos?

Összekapcsolja az issue-kat a hozzájuk tartozó kódmódosításokkal és ellenőrzési folyamatokkal. Így részletesen elemezhető a kódellenőrzési ciklus és annak hatása a teljes szállítási időre.

Hol szerezhető be?

Sok GitHub API-válaszban a „pull_request” objektum „number” mezőjeként, illetve a Pull Requests API fő azonosítójaként érhető el.

Példák
12345678910
Szerző
Author
Az a felhasználó, aki létrehozta az issue-t, a pull requestet vagy a commitot.
Leírás

A szerző hozza létre a fejlesztési folyamat adott elemét. Egy issue szerzője például az a személy, aki bejelentette a hibát vagy kérte a funkciót. A pull request szerzője az a fejlesztő, aki megírta a kódot.

Az elemzésben a szerző alapján feltárhatók a munka forrásai. A hibajelentések szerzőinek vizsgálata például megmutathatja, hogy bizonyos csapatokhoz vagy funkciókhoz kapcsolódnak-e visszatérő minták. A szerző és a felelős együttes vizsgálatával az átadási minták is elemezhetők.

Miért fontos?

Azonosítja a munkaelem vagy kódmódosítás kezdeményezőjét. Ez segíthet az utómunka, a hibajelentések és a funkciókérések forrásának elemzésében.

Hol szerezhető be?

Az issue-kra, pull requestekre és commitokra vonatkozó API-válaszok fő objektumában található „user” objektumban érhető el. A mező neve általában „user.login”.

Példák
sara.jonesmike.leeautomation-bot
Telepítési környezet
DeploymentEnvironment
A telepítés célkörnyezete, például „Staging” vagy „Production”.
Leírás

Ez az attribútum jelzi, hogy hová telepítik a kódot. A különböző környezetekbe történő telepítések nyomon követése segít megérteni a teljes életciklust a fejlesztéstől az éles kiadásig.

Az attribútum a telepítési alfolyamat elemzésére használható. Mérhető vele, mennyi idő alatt jut el a kód a staging környezetből az éles környezetbe, és nyomon követhető a különböző környezetekbe történő telepítések sikeressége. Segít megállapítani, mikor készült el ténylegesen egy fejlesztési elem, és mikor vált elérhetővé a felhasználók számára.

Miért fontos?

Megkülönbözteti az élesítés előtti és az éles kiadásokat. Ez szükséges a tényleges piacra jutási idő méréséhez és a telepítési minták elemzéséhez.

Hol szerezhető be?

Az adat a GitHub Deployments API-ból származik. Ezt gyakran CI/CD-folyamatok vagy más automatizmusok hívják meg.

Példák
developmentstagingproduction
Utolsó adatfrissítés
LastDataUpdate
Az időbélyeg azt mutatja, mikor frissítették utoljára ezt a rekordot a forrásrendszerből.
Leírás

Ez az attribútum rögzíti a legutóbbi adatkinyerés vagy -frissítés dátumát és időpontját. Metaadatként jelzi, mennyire frissek az elemzett adatok. Nem azonos az esemény időbélyegével, amely azt rögzíti, mikor történt az üzleti esemény.

Az elemzés során ez a mező segít megítélni, mennyire naprakész a folyamatról alkotott kép. Megmutatja, hogy valós idejű adatokat vagy egy adott időpontban készült pillanatképet lát-e. Ez fontos a működést nyomon követő dashboardok és a felügyelet szempontjából.

Miért fontos?

Jelzi az adatok frissességét, ami elengedhetetlen ahhoz, hogy az elemzések és a dashboardok naprakész információkra épüljenek.

Hol szerezhető be?

Ezt az időbélyeget az adatkinyerés, -átalakítás és -betöltés (ETL) során hozza létre és adja hozzá a rendszer.

Példák
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Utómunka-e
IsRework
Logikai jelző, amely akkor igaz, ha egy tevékenység a folyamat egy korábbi szakaszába való visszalépést jelent.
Leírás

A jelző értéke igaz, ha egy fejlesztési elem visszalép a folyamatban. Ilyen például, ha egy pull request ellenőrzése „Changes Requested” eredménnyel zárul, vagy ha egy lezárt issue-t újranyitnak. Az érték a tevékenységek sorrendjének elemzéséből származik.

Ez az attribútum elengedhetetlen a veszteségek és a hatékonysági problémák számszerűsítéséhez. Közvetlenül támogatja a „Rework and Regression Loops” dashboardot és a „Rework Rate” KPI-t. Az „IsRework = true” feltételre szűrve az elemzők elkülöníthetik és megvizsgálhatják az utómunka okait.

Miért fontos?

Egyértelműen megjelöli az utómunkát jelentő tevékenységeket, így könnyen számszerűsíthetők, megjeleníthetők és elemezhetők a folyamat hatékonysági problémáinak okai.

Hol szerezhető be?

Származtatott attribútum. A számítás menete: meg kell határozni a folyamat szokásos menetét, majd megjelölni azokat a tevékenységeket, amelyek egy korábbi logikai szakaszba való visszalépéssel eltérnek ettől.

Példák
truefalse
Kötelező Javasolt Nem kötelező

A szoftverfejlesztési életciklus tevékenységei

Ezeket a fontos folyamatlépéseket és mérföldköveket érdemes rögzíteni az eseménynaplóban a pontos folyamattérképezéshez és a szűk keresztmetszetek azonosításához.
6 Javasolt 7 Nem kötelező
Tevékenység Leírás
A CI-ellenőrzések sikeresek
Ez az automatizált ellenőrzések, például a build, az egységtesztek vagy a statikus elemzés sikeres befejezését jelzi a pull request kódján. Az esemény a GitHub Actionshez hasonló rendszerek által jelentett ellenőrzési állapotból következtethető ki.
Miért fontos?

Ez az automatizált minőségi ellenőrzési pont elengedhetetlen a kód stabilitásához. A hibák és a hosszú futási idők jelentős szűk keresztmetszetet okozhatnak a szállítási folyamatban.

Hol szerezhető be?

A GitHub Checks API vagy Statuses API adataiból következtethető ki. Egy ellenőrzési futás vagy állapotfrissítés 'success' értéket, illetve 'success' eredménnyel 'completed' állapotot jelez.

Rögzítés

Figyelje a Checks API-ban az érintett ellenőrzési csomagok 'success' eredményét.

Eseménytípus inferred
Hiba vagy feladat létrehozva
Ez jelöli a fejlesztési feladat életciklusának kezdetét, vagyis egy feladat, hiba vagy funkcióigény hivatalos rögzítését. Az esemény akkor kerül be a rendszerbe, amikor egy felhasználó új issue-t hoz létre egy GitHub-tárolóban.
Miért fontos?

Ez a folyamat elsődleges kezdőtevékenysége. Nélküle nem mérhető a teljes fejlesztési ciklusidő, és nem azonosíthatók a munka kezdeti forrásai.

Hol szerezhető be?

Ez a GitHub Issues API eseményfolyamából rögzített, kifejezett esemény. Az eseménytípus az adott issue esetében jellemzően 'opened'.

Rögzítés

Figyelje az issue-k 'opened' eseményét webhookokkal vagy az API rendszeres lekérdezésével.

Eseménytípus explicit
Issue lezárva
A fejlesztési feladat elkészült, a hozzá tartozó issue-t pedig hivatalosan lezárták. Ez automatikusan megtörténhet a kapcsolódó pull request beolvasztásakor, vagy egy csapattag kézzel is lezárhatja.
Miért fontos?

Ez a tevékenység jelöli a fejlesztési feladat folyamatának végleges végét. Elengedhetetlen a teljes ciklusidő kiszámításához.

Hol szerezhető be?

Ez a GitHub Issues API eseményfolyamából rögzített, kifejezett esemény. Az eseménytípus 'closed'.

Rögzítés

Figyelje az issue-k 'closed' eseményét webhookokkal vagy az API rendszeres lekérdezésével.

Eseménytípus explicit
Pull request beolvasztva
A pull request jóváhagyott kódmódosításai bekerülnek a célbranchbe, például a main vagy a develop branchbe. Ez a pull request kifejezett, végső művelete, amely beépíti az új kódot.
Miért fontos?

Ez fontos mérföldkő, amely a fejlesztés és az ellenőrzés végét jelzi. Sok csapatnál ez az automatizált telepítés előtti utolsó lépés.

Hol szerezhető be?

A GitHub Pull Request API eseményfolyamából vagy webhookokkal rögzíthető. Az esemény művelete 'closed', a pull request adatcsomagjában pedig a 'merged' attribútum értéke true.

Rögzítés

Figyelje a pull requestek 'closed' műveletét, és ellenőrizze, hogy a 'merged' jelző értéke true-e.

Eseménytípus explicit
Pull request jóváhagyva
Az ellenőr hivatalosan jóváhagyta a pull request módosításait, vagyis azok megfelelnek a minőségi és funkcionális követelményeknek. Az esemény akkor rögzíthető, amikor az ellenőr 'approve' állapottal küldi be az értékelését.
Miért fontos?

Ez fontos minőségi ellenőrzési pont és jelentős mérföldkő a beolvasztás előtt. A PR létrehozásától a jóváhagyásig eltelt idő a kódellenőrzési folyamat hatékonyságának fontos KPI-ja.

Hol szerezhető be?

A GitHub Pull Request API-ból vagy webhookokkal rögzíthető, amikor az ellenőrzés állapota 'APPROVED'.

Rögzítés

Szűrje a pull requestek ellenőrzési eseményeit az 'APPROVED' állapotra.

Eseménytípus explicit
Pull request megnyitva
Ez azt jelzi, hogy elkészült a kód első változata, amely készen áll az ellenőrzésre és a beolvasztásra. A fejlesztő pull requestet (PR) hoz létre, hogy a feature branch módosításait javasolja a fő branchbe. Ez kifejezett GitHub-esemény.
Miért fontos?

Ez fontos mérföldkő: lezárja a kezdeti fejlesztési szakaszt, és elindítja az ellenőrzési és beolvasztási folyamatot. Segítségével külön elemezhető a fejlesztési és az ellenőrzési ciklusidő.

Hol szerezhető be?

A GitHub Pull Request API eseményfolyamából vagy webhookokkal rögzíthető. Az esemény művelete 'opened'.

Rögzítés

Figyelje a pull requestek 'opened' műveletét webhookokkal vagy az API rendszeres lekérdezésével.

Eseménytípus explicit
A CI-ellenőrzések sikertelenek
Ez egy automatizált ellenőrzés, például a build vagy egy egységteszt sikertelenségét jelzi a pull request kódján. Az esemény a GitHub Actionshez hasonló rendszer által jelentett sikertelen állapotból következtethető ki.
Miért fontos?

Ez a tevékenység olyan technikai minőségi problémákra hívja fel a figyelmet, amelyek fejlesztői beavatkozást igényelnek, és ismételt munkafázist okoznak. A hibák gyakoriságának elemzése segíthet a helyi tesztelés és a kódminőség javításában.

Hol szerezhető be?

A GitHub Checks API vagy Statuses API adataiból következtethető ki. Egy ellenőrzési futás vagy állapotfrissítés 'failure' értéket, illetve 'failure' eredménnyel 'completed' állapotot jelez.

Rögzítés

Figyelje a Checks API-ban az érintett ellenőrzési csomagok 'failure' eredményét.

Eseménytípus inferred
Branch létrehozva
Ez jelzi, hogy megkezdődött az issue-hoz kapcsolódó aktív fejlesztés: a fejlesztő új branchet hoz létre a fő kódbázisból. Az esemény akkor rögzíthető, amikor új branch kerül fel a tárolóba. A branch neve gyakran tartalmazza az issue számát.
Miért fontos?

Ez jelzi az átmenetet a tervezéstől az aktív kódolásig. Az issue létrehozása és ez az esemény közötti időből megállapítható, mennyi idő telik el, mire egy fejlesztő felveszi a feladatot, illetve mekkora késés alakul ki a kezdeti hátralékban.

Hol szerezhető be?

A GitHub Git API-ból vagy a 'create' típusú eseményeket figyelő webhookokkal rögzíthető. A branch nevét gyakran el kell rendelni egy issue-hoz valamilyen névadási szabály alapján, például 'feature/issue-123'.

Rögzítés

Dolgozza fel az új branchekről érkező 'create' webhookeseményeket, és rendelje hozzájuk a megfelelő issue-t.

Eseménytípus explicit
Ellenőrzés kérése
A pull request szerzője hivatalosan felkéri a csapat egyes tagjait vagy csapatait a kód ellenőrzésére. Ez a GitHub felületén vagy API-ján keresztül végrehajtott kifejezett művelet, amely értesítést küld a felkért ellenőröknek.
Miért fontos?

Ez a tevékenység jelöli a kódellenőrzési folyamatra való hivatalos átadás kezdetét. Az esemény és az ellenőrzés beküldése közötti időből mérhető az ellenőrök válaszideje, és feltárhatók a lehetséges szűk keresztmetszetek.

Hol szerezhető be?

A GitHub Pull Request API eseményfolyamából vagy webhookokkal rögzíthető. Az esemény művelete 'review_requested'.

Rögzítés

Figyelje a pull requestek 'review_requested' műveletét.

Eseménytípus explicit
Issue újranyitva
Egy korábban lezárt issue ismét aktívvá válik, jellemzően azért, mert a javítás nem volt megfelelő, vagy regressziót találtak. Ez kifejezett esemény, amely újraindítja a fejlesztési feladat életciklusát.
Miért fontos?

Ez jelentős ismételt munkafázist jelez, például egy éles környezetbe került hibát vagy egy hiányos javítást. Gyakoriságának követése a szoftverminőség fontos mérőszáma.

Hol szerezhető be?

Ez a GitHub Issues API eseményfolyamából rögzített, kifejezett esemény. Az eseménytípus 'reopened'.

Rögzítés

Figyelje az issue-k 'reopened' eseményét webhookokkal vagy az API rendszeres lekérdezésével.

Eseménytípus explicit
Kód feltöltve a PR-hez
Ez az ellenőrzésre beküldött kód frissítését jelzi, akár az eredeti PR részeként, akár az ellenőrzési visszajelzésre válaszul. Az esemény minden alkalommal rögzíthető, amikor új commit kerül fel egy nyitott pull requesthez tartozó branchre.
Miért fontos?

Ezeknek az eseményeknek a követése elengedhetetlen az ismételt munkafázisok feltárásához. Ha az ellenőrzés után többször is új kód kerül fel, az azt jelzi, hogy módosításokra volt szükség, ami növeli a teljes ciklusidőt.

Hol szerezhető be?

Ez kifejezett esemény a pull request idővonalán, gyakran új commit hozzáadásaként jelenik meg. A 'push' webhookból vagy a PR-hez tartozó commitok figyelésével rögzíthető.

Rögzítés

Kövesse a nyitott pull requesthez tartozó branchen történt 'push' eseményeket.

Eseménytípus explicit
Módosítás kérése az ellenőrzés során
Az ellenőr befejezte a kód ellenőrzését, és megállapította, hogy a pull request jóváhagyása előtt módosításokra van szükség. Az ellenőr hivatalosan, 'request_changes' állapottal küldi be az értékelését.
Miért fontos?

Ez az esemény egyértelműen jelzi az ismételt munkafázist. Gyakoriságának elemzésével feltárhatók a minőségi problémák, a nem egyértelmű követelmények és azok a területek, ahol a fejlesztőknek képzésre lehet szükségük.

Hol szerezhető be?

A GitHub Pull Request API-ból vagy webhookokkal rögzíthető, amikor az ellenőrzés állapota 'CHANGES_REQUESTED'.

Rögzítés

Szűrje a pull requestek ellenőrzési eseményeit a 'CHANGES_REQUESTED' állapotra.

Eseménytípus explicit
Telepítés sikeres
A kódmódosításokat sikeresen telepítették egy adott környezetbe, például tesztkörnyezetbe vagy éles környezetbe. Az esemény jellemzően a GitHub Deployments API-n keresztül rögzíthető, gyakran egy beolvasztás után elindított GitHub Action segítségével.
Miért fontos?

Ez jelzi, hogy a kód a tárolóból egy működő környezetbe került. Követése elengedhetetlen az ötlettől az élesítésig tartó teljes átfutási idő méréséhez.

Hol szerezhető be?

A Deployments API-n keresztül rögzíthető. Egy külső szolgáltatás vagy GitHub Action létrehozza a telepítést, majd az állapotát 'success' értékre frissíti.

Rögzítés

Webhookokkal figyelje a telepítési állapot eseményeit, és keresse a 'success' állapotot.

Eseménytípus inferred
Javasolt Nem kötelező

Útmutatók az adatok kinyeréséhez

Adatok kinyerése a GitHubból

Készen áll a kezdésre?

Készítse elő az adatait ezzel a sablonnal, és kezdje el fejleszteni szoftverfejlesztési életciklusát. Tárja fel a hatékonysági problémákat, és tegye gyorsabbá, gördülékenyebbé a kiadásokat még ma.

Fejlessze SDLC-folyamatát: tárja fel azonnal a hatékonysági problémákat

Csökkentse 30%-kal a ciklusidőt, és tegye gördülékenyebbé a GitHub-fejlesztést.

Próbálja ki ingyen

Nincs szükség bankkártyára, a beállítás néhány perc.