Sablon a szoftverfejlesztési életciklus adatainak előkészítéséhez

GitLab
Sablon a szoftverfejlesztési életciklus adatainak előkészítéséhez

Sablon a szoftverfejlesztési életciklus adatainak előkészítéséhez

Ez a sablon végigvezeti az elemzéshez szükséges, alapvető adatokon. Bemutatja, mely attribútumokat érdemes gyűjteni, mely tevékenységeket kell követni, és gyakorlati útmutatást ad az adatok közvetlen GitLabból történő kinyeréséhez. Segítségével felkészítheti adatait a process mining elemzésre.
  • Javasolt attribútumok
  • Követendő fő 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 érdemes felvenni az eseménynaplóba a szoftverfejlesztési életciklus elemzéséhez és optimalizálásához.
3 Kötelező 5 Javasolt 12 Nem kötelező
Név Leírás
Fejlesztési munkaelem
DevelopmentItem
Egy munkaegység, például egy funkció, hibajavítás vagy feladat egyedi azonosítója. Ez szolgál elsődleges esetazonosítóként.
Leírás

A fejlesztési munkaelem a szoftverfejlesztési életcikluson végighaladó, önállóan követhető munkát jelöli. Egyetlen esetbe kapcsolja össze a kapcsolódó tevékenységeket a létrehozástól a bevezetésig. A GitLabban ezt általában az issue projekten belül egyedi belső azonosítója (IID) jelöli.

A fejlesztési munkaelemek szerinti elemzés lehetővé teszi a teljes ciklusidő mérését, a szűk keresztmetszetek feltárását és a folyamatkövetés ellenőrzését. Ez ad alapot annak megértéséhez, milyen hatékonyan jut el a munka az ötlettől az éles üzemig.

Miért fontos?

Ez az alapvető esetazonosító kapcsolja össze a folyamat összes eseményét, így nyomon követhető bármely munkaelem teljes életciklusa.

Hol szerezhető be?

Ez általában egy GitLab-issue belső azonosítója (IID). Az Issues API válaszában az 'iid' mezőben található.

Példák
1024512PRJ-2345
Kezdési idő
StartTime
Az a dátum és idő, amikor egy tevékenység vagy esemény elkezdődött.
Leírás

A StartTime a tevékenység pontos kezdési dátumát és időpontját jelöli. A GitLab-eseményeknél ezt különböző időbélyegmezők rögzítik. Például az „Issue létrehozva” tevékenység StartTime értéke az issue 'created_at' időbélyege, a „Merge Request összevonva” tevékenységé pedig a merge request 'merged_at' időbélyege.

Ez az időbélyeg a process mining egyik alapvető időadata. Az események időrendi sorba rendezésére, a tevékenységek közötti időtartamok kiszámítására, a ciklusidők mérésére és a folyamat teljesítményének időbeli elemzésére használható.

Miért fontos?

Megadja az események időrendi sorrendjét, ami nélkülözhetetlen az időalapú mutatók kiszámításához és a folyamat menetének megértéséhez.

Hol szerezhető be?

A GitLab különböző időbélyegmezőiből nyerhető ki, például az issue-k 'created_at', 'updated_at' és 'closed_at', valamint a merge requestek 'merged_at' mezőjéből.

Példák
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Tevékenység
Activity
A bekövetkezett folyamatlépés vagy esemény neve, például „Issue létrehozva” vagy „Merge Request összevonva”.
Leírás

A Tevékenység attribútum rögzíti a fejlesztési munkaelemmel kapcsolatos különálló eseményeket. Ezek nem egyetlen mezőben szerepelnek a GitLabban, hanem az Issues, Merge Requests és CI/CD Pipelines különböző műveleteiből és időbélyegeiből állíthatók elő. Ilyen esemény például egy issue létrehozása, egy commit feltöltése, egy pipeline hibája vagy egy merge request jóváhagyása.

Ez az attribútum alapvető a folyamattérkép elkészítéséhez, a munkafolyamat megjelenítéséhez, valamint az események sorrendjének és gyakoriságának elemzéséhez. Segítségével azonosíthatók az eltérések, a lépések közötti szűk keresztmetszetek és a gyakori folyamatútvonalak.

Miért fontos?

Meghatározza a folyamattérkép lépéseit, így megjeleníthető és elemezhető a teljes fejlesztési munkafolyamat.

Hol szerezhető be?

A GitLab eseményfolyamának eseménytípusaiból és állapotváltozásaiból, vagy az issue-k és merge requestek 'created_at', 'merged_at' és 'closed_at' időbélyegeinek értelmezésével állítható elő.

Példák
Hiba létrehozvaFejlesztés megkezdődöttMerge Request összevonvaPipeline sikertelenÉles környezetbe bevezetve
Befejezési idő
EndTime
Az a dátum és idő, amikor egy tevékenység vagy esemény befejeződött.
Leírás

Az EndTime a tevékenység pontos befejezési dátumát és időpontját jelöli. A GitLab számos elemi eseményénél, például az „Issue létrehozva” eseménynél, az EndTime megegyezik a StartTime értékével. Az időtartammal rendelkező tevékenységeknél, például a code review-nál, a befejezés időpontját jelöli, például az utolsó jóváhagyás idejét.

Ez az attribútum szükséges az egyes tevékenységek időtartamának (feldolgozási idő) pontos kiszámításához. A szűk keresztmetszetek részletes elemzésével elkülöníthető a feladaton végzett munka ideje a feladatok közötti várakozástól.

Miért fontos?

Lehetővé teszi a tevékenységek pontos időtartamának (feldolgozási idejének) kiszámítását, ami segít feltárni a folyamat nem hatékony lépéseit.

Hol szerezhető be?

Elemi eseményeknél megegyezik a StartTime értékével. Az időtartammal rendelkező tevékenységeknél az adatokban szereplő megfelelő befejezési esemény alapján kell meghatározni.

Példák
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Fejlesztési munkaelem típusa
DevelopmentItemType
A fejlesztési munkaelem besorolása, például „Funkció”, „Hiba”, „Feladat” vagy „Karbantartás”.
Leírás

Ez az attribútum a végzett munka jellegét kategorizálja. A GitLabban ezt általában az issue-hoz rendelt címkékkel oldják meg. A csapatok címkékkel különböztetik meg az új funkciókat, a hibajavításokat, a technikai adósságot és az egyéb munkatípusokat.

A fejlesztési munkaelem típusa szerinti elemzéssel összehasonlíthatók a különböző munkák folyamatai és ciklusideje. Megvizsgálható például, hogy a hibák javítása gyorsabb-e, mint az új funkciók fejlesztése, vagy a technikai adóssággal kapcsolatos feladatok más ellenőrzési folyamatot követnek-e.

Miért fontos?

A folyamat munkatípus szerinti csoportosításával kideríthető, hogy bizonyos munkák gyakrabban járnak-e késéssel, újramunkával vagy eltérésekkel.

Hol szerezhető be?

Általában a GitLab-issue-hoz rendelt 'labels' mezőből állítható elő. A konkrét címkéket szabványos típusokhoz rendelő megfeleltetési szabályra van szükség.

Példák
FunkcióHibaFeladatTechnikai adósság
Felelős
Assignee
Az esemény időpontjában az issue-hoz vagy merge requesthez rendelt felhasználó.
Leírás

A Felelős az a fejlesztő vagy felhasználó, aki a folyamat adott pontján a munkaelemért felel. A GitLabban ezt az Issue vagy Merge Request assignee vagy assignees mezője rögzíti.

A Felelős szerinti elemzés fontos a „Fejlesztői terhelés és erőforrás-elosztás” dashboardhoz. Segít megérteni az erőforrások kihasználtságát, azonosítani a túlterhelt munkatársakat vagy csapatokat, és elemezni a személyek közötti átadásokat.

Miért fontos?

Nyomon követi, ki végezte a munkát. Ez lehetővé teszi a terhelés és az erőforrások elosztásának elemzését, valamint az átadások okozta késések feltárását.

Hol szerezhető be?

A GitLab Issues és Merge Requests API-válaszainak 'assignee.username' vagy 'assignees' mezőjéből nyerhető ki.

Példák
jdoeasmithr.williams
Projekt neve
ProjectName
Annak a GitLab-projektnek a neve, amelyhez a fejlesztési munkaelem tartozik.
Leírás

Ez az attribútum azonosítja azt a kódtárat vagy projektet, amelyben a munka folyik. A GitLabban minden issue és merge request egy projekthez tartozik.

A projekt neve szerinti elemzéssel összehasonlítható a különböző termékek, összetevők vagy szolgáltatások teljesítménye. Kiderülhet, hogy egyes projektek SDLC-folyamatai hatékonyabbak-e másokénál. A dashboardok egy adott területre is szűrhetők vele.

Miért fontos?

Lehetővé teszi a folyamat termék, alkalmazás vagy összetevő szerinti elemzését, így célzott fejlesztések indíthatók.

Hol szerezhető be?

A Project API 'name' vagy 'path_with_namespace' mezőjéből nyerhető ki. Az Issues és Merge Requests rekordok 'project_id' mezője alapján kapcsolható össze.

Példák
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Súlyosság
Severity
A fejlesztési munkaelem súlyossági szintje, jellemzően hibák vagy incidensek esetén.
Leírás

A súlyosság a hiba vagy probléma hatását jelzi a kritikustól az enyhéig terjedő skálán. A GitLabban nincs beépített súlyossági mező, ezért ezt szinte mindig címkékkel kezelik, például 'severity::1' vagy 'severity::2'.

Ez az attribútum szükséges a „Súlyossági eszkalációk alakulása” dashboardhoz és a hozzá tartozó KPI-hoz. A súlyosság életciklus alatti változásainak elemzése feltárhatja, ha egy problémát kezdetben alábecsültek, vagy ha a folyamat súlyosbítja a helyzetet.

Miért fontos?

Segít rangsorolni a munkát, és megvizsgálni, hogy a súlyosabb problémákat gyorsabban kezelik-e. A változások követésével mérhető a „Súlyossági eszkalációk gyakorisága” KPI.

Hol szerezhető be?

A GitLab-issue-hoz rendelt 'labels' mezőből állítható elő. A címkéket, például az 'S1' és 'S2' értékeket, súlyossági szintekhez kell rendelni.

Példák
1 - Kritikus2 - Magas3 - Közepes4 - Alacsony
Adatok utolsó frissítése
LastDataUpdate
Az az időbélyeg, amely megmutatja, mikor frissítették utoljára az esemény adatait a forrásrendszerből.
Leírás

Ez az attribútum rögzíti, hogy mikor nyerték ki vagy frissítették utoljára az esemény adatait a process mining adatkészletében. Nem az esemény bekövetkezésének időpontját jelöli, hanem azt, hogy mikor szinkronizálták utoljára az esemény rekordját.

Ez az információ segít megítélni az adatok frissességét és ellenőrizni, hogy a folyamatelemzés időben készült-e. A felhasználók láthatják, hogy a dashboardok és a KPI-k friss adatokon alapulnak-e, és mekkora késés lehet a forrásrendszer és az elemzés között.

Miért fontos?

Átláthatóvá teszi az adatok frissességét, így a felhasználók tudják, mennyire naprakész a folyamatelemzés.

Hol szerezhető be?

Ezt az időbélyeget az adatkinyerő eszköz vagy az ETL-folyamat hozza létre és rögzíti az adatok frissítésekor.

Példák
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Átadásra várakozás
HandoffWaitTime
Két egymást követő, különböző felelős által végzett tevékenység közötti számított állásidő.
Leírás

Ez a mutató a tevékenység befejezése és a következő tevékenység kezdete közötti időt méri, ha közben megváltozik a felelős. Például azt az időt, amely a fejlesztő munkájának befejezése és a kódellenőrzés reviewer általi megkezdése között telik el.

Ez az „Average Handoff Wait Time” KPI alapja. Segít feltárni az erőforrások elosztásában és a csapatok vagy munkatársak közötti kommunikációban rejlő hatékonysági problémákat, és láthatóvá teszi az aktív munkavégzésen kívüli késéseket.

Miért fontos?

Méri a különböző személyek vagy csapatok közötti átadás során keletkező állásidőt, így feltárja a rejtett késéseket és kommunikációs szűk keresztmetszeteket.

Hol szerezhető be?

A process mining eszköz számítja ki. Ehhez elemzi az eset egymást követő eseményeit, ellenőrzi, hogy eltér-e az „Assignee” értéke, majd kiszámítja az időeltérést.

Példák
1 nap 2 óra15 perc8 óra
Átfutási idő
CycleTime
A fejlesztési elem első és utolsó tevékenysége között eltelt teljes idő.
Leírás

Az átfutási idő számított mutató, amely egy eset teljes időtartamát méri. Általában az egyes fejlesztési elemek első eseménye, például az „Issue Created”, és utolsó eseménye, például a „Deployed to Production” közötti időtartamot jelenti.

Ez az egyik legfontosabb KPI a folyamat általános hatékonyságának mérésére. Az „SDLC End-to-End Cycle Time” dashboard egyik fő mutatója. A fejlesztések nyomon követésére és a rendszerszintű problémákra utaló, elhúzódó esetek azonosítására is használható.

Miért fontos?

A process mining egyik alapvető KPI-ja, amely a fejlesztési életciklus teljes folyamatának hatékonyságát méri.

Hol szerezhető be?

A process mining eszköz minden egyedi CaseId esetén a legnagyobb StartTime értékből kivonja a legkisebb StartTime értéket.

Példák
10 nap 4 óra23 óra 15 perc35 nap
Célág
TargetBranch
A Merge Request célágának neve.
Leírás

A célág az az ág, amelybe a módosításokat be kell olvasztani, például „main”, „develop” vagy egy kiadási ág, például „release/1.5”. Ez minden Merge Request alapvető adata.

A célág szerinti elemzés feltárhatja, hogy eltérően zajlik-e a folyamat attól függően, melyik ágba kerül a kód. A „main” ágba történő összeolvasztás például szigorúbb jóváhagyást és hosszabb átfutási időt igényelhet, mint egy funkcióágba történő beolvasztás. A célág alapján a produkciós telepítések más kódintegrációs folyamatoktól is elkülöníthetők.

Miért fontos?

Segít megkülönböztetni a fejlesztési és kiadási munkafolyamatokat, amelyek a célágtól függően jelentősen eltérhetnek.

Hol szerezhető be?

A GitLab Merge Requests API válaszának „target_branch” mezőjéből származik.

Példák
maindeveloprelease/v2.1.0hotfix/user-auth-bug
Csapat neve
TeamName
A projekthez vagy a felelőshöz tartozó fejlesztőcsapat.
Leírás

A Csapat neve a fejlesztési munkaelemért felelős csoportot vagy squadot jelöli. Ez általában nem szabványos GitLab-mező. Az érték gyakran a projekt elnevezéséből, a csoportstruktúrából vagy a felelősök csapatokhoz rendelésére szolgáló külső megfeleltetési táblából származik.

Ez az attribútum a folyamat teljesítményének csapatszintű elemzésére szolgál. Segít összehasonlítani a különböző csapatok hatékonyságát, terhelését és a folyamatok követését. A „Szűk keresztmetszetek elemzése szakaszonként” dashboardon például csapatok szerint is vizsgálhatók az eredmények.

Miért fontos?

Lehetővé teszi a csapatok teljesítményének és folyamataiknak az összehasonlítását, így feltárhatók a csapatonként jelentkező szűk keresztmetszetek és a bevált gyakorlatok.

Hol szerezhető be?

Gyakran a projekt neve vagy a felelős GitLabon kívül meghatározott csapatstruktúrához rendelésével, illetve a GitLab-csoporthierarchiából állapítható meg.

Példák
Frontend-AlphaBackend-ServicesPlatform-Infra
Fejlesztési munkaelem állapota
DevelopmentItemStatus
A fejlesztési munkaelem állapota az esemény időpontjában, például „Nyitott”, „Folyamatban” vagy „Lezárt”.
Leírás

Ez az attribútum az elsődleges munkaelem, általában egy GitLab-issue állapotát mutatja. A GitLab-issue state mezője 'opened' vagy 'closed' értéket vehet fel. A részletesebb állapotokat gyakran címkékkel kezelik, például 'Status::Triage', 'Status::In-Dev' vagy 'Status::In-Review'.

Az állapotváltozások követése segít megérteni az eset életciklusát. Megmutatja, mennyi időt töltenek az elemek az egyes állapotokban, és lehetővé teszi a folyamatban lévő vagy befejezett munkák szűrését, például az „SDLC teljes ciklusideje” dashboardon.

Miért fontos?

Pillanatképet ad az eset állapotáról, így elemezhető az egyes szakaszokban eltöltött idő, és elkülöníthető a folyamatban lévő munka a befejezettől.

Hol szerezhető be?

Az elsődleges állapot a GitLab-issue 'state' mezőjéből származik ('opened', 'closed'). A részletesebb állapotok gyakran címkékből állíthatók elő.

Példák
megnyitvalezárvaFolyamatbanEllenőrzés alatt
Forrásrendszer
SourceSystem
Megadja, melyik rendszerből származnak az adatok.
Leírás

Ez az attribútum jelöli a folyamatadatok forrását. Ebben az adatmodellben az értéke mindig 'GitLab'.

Erre az attribútumra akkor is szükség van, ha a folyamatadatok több rendszerből származnak, például a tervezéshez használt Jirából és a végrehajtáshoz használt GitLabból. Lehetővé teszi az adatok szűrését és csoportosítását, valamint segít nyomon követni az adatok eredetét.

Miért fontos?

Egyértelművé teszi az adatok eredetét, ami fontos az adatirányítás és a több vállalati rendszerből származó adatok összekapcsolása szempontjából.

Hol szerezhető be?

Ez egy statikus érték, a 'GitLab', amely az adatátalakítás során kerül be.

Példák
GitLab
Kiadási verzió
ReleaseVersion
A telepítéshez tartozó tervezett vagy tényleges szoftververzió-címke.
Leírás

Ez az attribútum azonosítja, hogy a fejlesztési elem melyik szoftverkiadáshoz tartozik. A GitLabban ez mérföldkőhöz, védett címkéhez vagy a Releases funkció egyik bejegyzéséhez kapcsolható.

Ez az adat elengedhetetlen a „Release Schedule Adherence Tracking” dashboardhoz. Ha összeveti a tényleges telepítési dátumot a kiadási verzióhoz tartozó tervezett dátummal, mérheti, mennyire sikerül tartani az ütemtervet, és feltárhatja a kiadási késések okait.

Miért fontos?

A fejlesztési elemeket egy adott szoftverkiadáshoz kapcsolja, így nyomon követhető a kiadás előrehaladása és az ütemterv betartása.

Hol szerezhető be?

Az adat származhat a GitLab Releasesből, egy git tag nevéből vagy a kiadás tervezéséhez használt mérföldkő címéből.

Példák
v1.2.0v3.0.0-beta2023.4.1
Mérföldkő neve
MilestoneTitle
Annak a mérföldkőnek vagy sprintnek a neve, amelyhez a fejlesztési elem tartozik.
Leírás

A GitLabban a mérföldkő egy meghatározott célhoz vagy időszakhoz, például egy sprinthez vagy kiadáshoz kapcsolódó munka követésére szolgál. Ez az attribútum a mérföldkő nevét rögzíti.

Segítségével az egyes sprintek vagy tervezési időszakok keretében elemezhető a folyamat teljesítménye. Megnézheti például, hogy sprintenként javul-e az átfutási idő, vagy a folyamatnézetet az adott kiadáshoz kapcsolódó munkára szűrheti.

Miért fontos?

A fejlesztési munkát tervezési ciklusokhoz, például sprintekhez vagy kiadásokhoz kapcsolja, így mérhető a teljesítmény a tervezett időkeretekhez képest.

Hol szerezhető be?

A GitLab Issues vagy Merge Requests API válaszának „milestone.title” mezőjéből származik.

Példák
2023. negyedik negyedévi kiadás23.11-es sprint1. fázis: MVP
Merge Request állapota
MergeRequestStatus
Az eseményhez tartozó Merge Request állapota, például „Opened”, „Merged” vagy „Closed”.
Leírás

Ez az attribútum a Merge Request (MR) állapotát rögzíti az esemény időpontjában. A GitLab MR-ek állapota lehet „opened”, „closed”, „merged” vagy „locked”. Ez nem azonos a fejlesztési elem általános állapotával.

Az MR állapotának követése elengedhetetlen az SDLC kódintegrációs szakaszának elemzéséhez. Közvetlenül támogatja például a „Code Review Cycle Time & Throughput” dashboardot, és segít feltárni az MR létrehozása, felülvizsgálata, jóváhagyása és összeolvasztása közötti késéseket.

Miért fontos?

Láthatóvá teszi a kódellenőrzés és az összeolvasztás folyamatát, amely gyakran az SDLC egyik kritikus szűk keresztmetszete.

Hol szerezhető be?

A GitLab Merge Requests API válaszának „state” mezőjéből származik.

Példák
megnyitvamergedlezárvalocked
Pipeline állapota
PipelineStatus
A CI/CD pipeline futásának állapota, például „Success”, „Failed” vagy „Running”.
Leírás

Ez az attribútum a commithez vagy Merge Requesthez kapcsolódó CI/CD pipeline-futtatás eredményét jelzi. A GitLabban gyakori állapotok: „running”, „pending”, „success”, „failed”, „canceled” és „skipped”.

Ez az adat elengedhetetlen a „Rework & Rerun Analysis” dashboardhoz. A pipeline gyakori hibái jelentős utómunkát és késéseket okozhatnak. A fejlesztés hatékonyságának és a kódminőségnek a javításához fontos elemezni a hibák gyakoriságát, helyét és hatását.

Miért fontos?

Nyomon követi az automatizált buildelés és tesztelés sikerét, illetve hibáit, így láthatóvá teszi az utómunka ismétlődő köreit, valamint a kódminőségi és tesztautomatizálási problémákat.

Hol szerezhető be?

A GitLab CI/CD Pipelines API válaszának „status” mezőjéből származik.

Példák
successfailedrunningcanceled
Utómunka-e
IsRework
Logikai jelző, amely megadja, hogy egy tevékenység az utómunka egyik ismétlődő köréhez tartozik-e.
Leírás

Ez a számított attribútum azokat a tevékenységeket jelöli, amelyek visszalépést jelentenek a folyamatban, például amikor a tesztelés megkezdése után ismét fejlesztésre kerül sor. A jelző meghatározásához általában bizonyos tevékenységsorozatokat kell felismerni. Ilyen például, ha ugyanabban az esetben a „Development Started” esemény a „Pipeline Failed” vagy a „QA Testing Started” esemény után következik.

Ez az attribútum közvetlenül táplálja a „Rework & Rerun Analysis” dashboardot és a „Rework Rate After Testing” KPI-t. Egyszerűvé teszi az utómunka szűrését és mérését, így a csapatok megérthetik annak gyakoriságát, okait és a projekt ütemtervére gyakorolt hatását.

Miért fontos?

Közvetlenül jelöli és méri az utómunkát, így könnyebb elemezni a folyamat hatékonysági és minőségi problémáinak okait és hatását.

Hol szerezhető be?

A process mining eszköz az egyes esetek tevékenységsorozatát elemezve, az utómunkára utaló mintákat keresve számítja ki.

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

A szoftverfejlesztési életciklus tevékenységei

Ezeket a folyamatlépéseket és mérföldköveket érdemes rögzíteni az eseménynaplóban, hogy pontosan feltárható legyen a folyamat és azonosíthatók legyenek a szűk keresztmetszetek.
4 Javasolt 8 Nem kötelező
Tevékenység Leírás
Éles környezetbe bevezetve
Ez a tevékenység jelöli, hogy a kód sikeresen éles környezetbe került, és elérhetővé vált a végfelhasználók számára. Akkor rögzül, amikor a GitLab CI/CD pipeline-ban kifejezetten erre kijelölt 'deploy to production' job sikeresen befejeződik.
Miért fontos?

Ez a folyamat elsődleges záróeseménye, amely azt jelzi, hogy az érték eljutott a felhasználókhoz. A teljes, végpontok közötti SDLC-ciklusidő és a kiadások gyakoriságának méréséhez is szükséges.

Hol szerezhető be?

A kifejezetten éles környezetbe történő bevezetésre kijelölt, sikeres CI/CD job 'finished_at' időbélyegéből nyerhető ki. A GitLab Environments funkciója ezt kifejezetten követi.

Rögzítés

Használja a sikeres, éles környezetbe történő bevezetést végző CI job 'finished_at' időbélyegét.

Eseménytípus explicit
Hiba létrehozva
Ez a tevékenység jelöli a fejlesztési életciklus kezdetét: ekkor jön létre egy új munkaelem, például egy funkcióigény, hiba vagy feladat. Az esemény akkor rögzül, amikor egy felhasználó új issue-t hoz létre a GitLabban. A rendszer eltárolja a létrehozás időpontját.
Miért fontos?

Ez a teljes folyamat elsődleges kezdőeseménye. Az issue létrehozásától a bevezetésig eltelt idő elemzésével mérhető fel az SDLC teljes ciklusideje.

Hol szerezhető be?

Ez kifejezetten rögzített esemény, amely az 'issues' tábla 'created_at' időbélyegéből vagy az Issues API-n keresztül nyerhető ki. A rendszerjegyzetek szintén rögzítik a létrehozást.

Rögzítés

Használja az issue 'created_at' időbélyegét.

Eseménytípus explicit
Merge Request létrehozva
Azt jelzi, hogy az első fejlesztési munka elkészült, a kód pedig készen áll az ellenőrzésre és az integrálásra. Ez a GitLab munkafolyamatának kifejezetten rögzített, alapvető eseménye, amely akkor keletkezik, amikor egy fejlesztő új merge requestet (MR) nyit.
Miért fontos?

Ez fontos mérföldkő: itt adják át a munkát a fejlesztéstől az ellenőrzésnek és a tesztelésnek. Innen kezdhető a teljes code review- és CI/CD-folyamatciklus elemzése.

Hol szerezhető be?

Ez kifejezetten rögzített esemény, amely a 'merge_requests' tábla 'created_at' időbélyegéből vagy a Merge Requests API-n keresztül nyerhető ki.

Rögzítés

Használja a merge request 'created_at' időbélyegét.

Eseménytípus explicit
Merge Request összevonva
Ez a tevékenység jelzi, hogy a kód ellenőrzése és integrálása sikeresen befejeződött. Kifejezetten rögzített esemény: akkor következik be, amikor egy felhasználó összevonja a merge request ágát a célággal.
Miért fontos?

Ez fontos mérföldkő, amely a fejlesztés és az ellenőrzés végét jelzi. A fejlesztési ciklusidő mérésének végpontja, a bevezetésig eltelt idő mérésének pedig a kezdőpontja.

Hol szerezhető be?

Ez kifejezetten rögzített esemény, amely a 'merge_requests' tábla 'merged_at' időbélyegéből nyerhető ki. Az összevonáskor rendszerjegyzet is készül.

Rögzítés

Használja a merge request 'merged_at' időbélyegét.

Eseménytípus explicit
Bevezetés megkezdődött
Azt jelzi, hogy megkezdődött a kód kiadása egy adott környezetbe, például staging vagy éles környezetbe. A GitLabban ez a CI/CD pipeline-on belüli 'deploy' job indulásának felel meg.
Miért fontos?

A bevezetés kezdetének követése segít elkülöníteni és mérni a bevezetési szakasz időtartamát. Ez szükséges a bevezetésig eltelt idő méréséhez és csökkentéséhez.

Hol szerezhető be?

A bevezetési jobként beállított CI/CD job 'started_at' időbélyegéből nyerhető ki. Ez a GitLab Environments and Deployments funkciójának része.

Rögzítés

Használja a bevezetési feladat CI jobnaplójában szereplő 'started_at' időbélyeget.

Eseménytípus explicit
Code review megkezdődött
A merge request szakmai ellenőrzésének kezdetét jelöli. Az esemény időpontja az első, ellenőrzéshez kapcsolódó műveletből állapítható meg, például az első olyan hozzászólásból vagy beszélgetésből, amelyet nem a szerző tett közzé.
Miért fontos?

Az MR létrehozása és az ellenőrzés kezdete közötti idő mérése megmutatja a várakozásból eredő késéseket. Ennek csökkentése lerövidíti a teljes code review ciklust.

Hol szerezhető be?

A merge requesthez érkezett első olyan hozzászólás vagy ellenőrzési beszélgetés időbélyegéből állapítható meg, amelyet nem az MR szerzője tett közzé. Az adat a rendszerjegyzetekben vagy a Notes API-n keresztül érhető el.

Rögzítés

Keresse meg az MR-hez érkezett első, nem a szerzőtől származó felhasználói hozzászólás időbélyegét.

Eseménytípus inferred
Fejlesztés megkezdődött
Ez a tevékenység jelzi, hogy megkezdődött az issue aktív fejlesztése. Mivel a GitLabban nincs külön „fejlesztés indítása” gomb, az esemény időpontját általában az issue-hoz kapcsolódó ágra elsőként feltöltött kódcommit alapján állapítják meg.
Miért fontos?

Pontosan megmutatja, mikor kezdődött az értéket teremtő fejlesztőmunka. Így mérhető a tényleges kódolási szakasz, és elkülöníthető a tervezésre vagy várakozásra fordított időtől.

Hol szerezhető be?

Az issue-hoz kapcsolt feature branch első commitjának időbélyegéből állapítható meg. Ehhez össze kell kapcsolni az issue-kat az ágakkal, például elnevezési szabályok vagy metaadatok alapján.

Rögzítés

Keresse meg az issue azonosítójához kapcsolódó ág első commitjának időbélyegét.

Eseménytípus inferred
Issue hozzárendelve
Azt jelzi, hogy az issue-t egy adott fejlesztőhöz vagy csapathoz rendelték, vagyis kijelölték a munka felelősét. A GitLab kifejezetten rögzíti ezt az eseményt, amikor az issue felelős mezőjét kitöltik vagy módosítják.
Miért fontos?

A hozzárendelések követése segít elemezni az erőforrások elosztását, a csapatok terhelését és az átadások idejét. Láthatóvá teszi, mennyi idő telik el a munka létrehozása és a feladat átvétele között.

Hol szerezhető be?

Az issue-hoz tartozó GitLab-rendszerjegyzetekből nyerhető ki. Ezek rögzítik, amikor hozzáadnak vagy módosítanak egy 'assignee' értéket. Az esemény időpontja a jegyzetben szerepel.

Rögzítés

Nyerje ki az issue rendszerjegyzeteiből az 'assignee changed' eseményeket.

Eseménytípus explicit
Issue lezárva
A munkaelem adminisztratív lezárását jelzi, rendszerint azután, hogy a módosításokat bevezették és ellenőrizték. Kifejezetten rögzített esemény, amely akkor keletkezik, amikor egy felhasználó lezárja az issue-t a GitLabban.
Miért fontos?

Az issue lezárása gyakran az összes kapcsolódó munka végét jelzi. Ha ezt összeveti a bevezetés időpontjával, feltárhatja a bevezetés utáni ellenőrzés vagy az adminisztráció késéseit.

Hol szerezhető be?

Ez kifejezetten rögzített esemény, amely az 'issues' tábla 'closed_at' időbélyegéből vagy a megfelelő rendszerjegyzetből nyerhető ki.

Rögzítés

Használja az issue 'closed_at' időbélyegét.

Eseménytípus explicit
Jóváhagyás hozzáadva
Azt jelzi, hogy egy ellenőrző hivatalosan jóváhagyta a merge requestben szereplő kódmódosításokat. A GitLab kifejezetten rögzíti ezt az eseményt, amikor egy felhasználó a 'Approve' gombra kattint.
Miért fontos?

A jóváhagyások fontos minőségi ellenőrzési pontok. Követésük megmutatja, mennyi időbe telik a szükséges jóváhagyások megszerzése, és segít biztosítani az ellenőrzési szabályoknak való megfelelést.

Hol szerezhető be?

A merge request jóváhagyási eseményeiből nyerhető ki. Ezek az Approvals API-n keresztül érhetők el, vagy megtekinthetők az MR előzményeiben.

Rögzítés

Használja a merge request jóváhagyási eseménynaplójában szereplő időbélyeget.

Eseménytípus explicit
Pipeline elindult
A CI/CD pipeline elindítását jelzi. A pipeline rendszerint buildelést, tesztelést és biztonsági ellenőrzéseket végez. A GitLab minden indításkor, például egy commit vagy MR létrehozásakor, rögzíti a pipeline-t és annak kezdési időpontját.
Miért fontos?

A pipeline-futtatások követése segít felmérni az automatizált tesztelés és integráció állapotát, valamint hatékonyságát. Megmutatja, mennyi időt vesz igénybe az automatizált ellenőrzés.

Hol szerezhető be?

A 'ci_pipelines' tábla pipeline-rekordjának 'created_at' vagy 'started_at' időbélyegéből, illetve a Pipelines API-n keresztül nyerhető ki.

Rögzítés

Használja az MR ágához tartozó pipeline-futtatási rekord időbélyegét.

Eseménytípus explicit
Pipeline sikertelen
Ez az esemény akkor következik be, ha a CI/CD pipeline bármelyik szakasza sikertelen, például buildhiba vagy sikertelen teszt miatt. A GitLab minden pipeline végső állapotát rögzíti, így a hibák könnyen azonosíthatók.
Miért fontos?

A pipeline-hibák az újramunka egyik fő okai. Gyakoriságuk, időtartamuk és okaik elemzésével feltárhatók a minőségi problémák, a nem megbízható tesztek és a fejlesztőknek szóló visszajelzési folyamat szűk keresztmetszetei.

Hol szerezhető be?

A 'ci_pipelines' tábla pipeline-rekordjának 'failed' állapota jelzi. A 'finished_at' időbélyeg mutatja a hiba bekövetkezésének időpontját.

Rögzítés

Szűrjön a 'failed' állapotú pipeline-rekordokra, és használja a 'finished_at' időbélyeget.

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

Útmutatók az adatok kinyeréséhez

Adatok kinyerése a GitLabból

Kezdheti?

Használja ezt a sablont az adatok előkészítéséhez, és kezdje el optimalizálni szoftverfejlesztési életciklusát. Fejlessze folyamatát még ma!

Fejlessze szoftverfejlesztési életciklusát: kezdje el az optimalizálást még ma

Szüntesse meg az SDLC szűk keresztmetszeteit, csökkentse 30%-kal az átfutási időt, és javítsa a minőséget.

Kezdje el az ingyenes próbaverziót

Nincs szükség bankkártyára, azonnal elkezdheti az optimalizálást.