Sablon a szoftverfejlesztési életciklus adatainak előkészítéséhez
Sablon a szoftverfejlesztési életciklus adatainak előkészítéséhez
- Javasolt attribútumok
- Követendő fő tevékenységek
- Útmutató az adatok kinyeréséhez
A szoftverfejlesztési életciklus attribútumai
| 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 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 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
|
|||
A szoftverfejlesztési életciklus tevékenységei
| 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
|
|||
Útmutatók az adatok kinyeréséhez
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.
Nincs szükség bankkártyára, azonnal elkezdheti az optimalizálást.