Uw Software Development Lifecycle Data Template

GitLab
Uw Software Development Lifecycle Data Template

Uw Software Development Lifecycle Data Template

Deze uitgebreide template begeleidt u door de essentiële data-punten die nodig zijn om uw Software Development Lifecycle proces te analyseren. Het schetst de cruciale attributen om te verzamelen, de belangrijkste activiteiten om te volgen, en biedt praktische richtlijnen voor het extraheren van deze informatie direct uit GitLab. Met deze resource kunt u vol vertrouwen uw data voorbereiden voor inzichtelijke process mining.
  • Aanbevolen attributen om vast te leggen
  • Belangrijkste activiteiten om te volgen
  • Richtlijnen voor data-extractie
Nieuw met event logs? Leer hoe je een process mining event log creëert.

Software Development Lifecycle Attributen

Dit zijn de aanbevolen data-velden om op te nemen in uw event log voor uitgebreide software development lifecycle-analyse en -optimalisatie.
3 Verplicht 5 Aanbevolen 13 Optioneel
Naam Omschrijving
Activiteit
Activity
De naam van de specifieke processtap of het event dat plaatsvond, zoals 'Issue Aangemaakt' of 'Merge Request Gemerged'.
Omschrijving

Het Activity attribuut legt de afzonderlijke events vast die plaatsvinden bij een ontwikkelitem. Deze worden niet als één veld in GitLab opgeslagen, maar worden afgeleid uit verschillende acties en timestamp-velden over Issues, Merge Requests en CI/CD Pipelines. Bijvoorbeeld, het aanmaken van een issue, het pushen van een commit, het falen van een pipeline, of het goedkeuren van een merge request zijn allemaal afzonderlijke activiteiten.

Dit attribuut is fundamenteel voor het bouwen van de procesmap, het visualiseren van de workflow en het analyseren van de sequentie en frequentie van events. Het wordt gebruikt om afwijkingen, knelpunten tussen stappen en gemeenschappelijke procespaden te identificeren.

Het belang

Het definieert de stappen in de procesmap, waardoor visualisatie en analyse van de end-to-end ontwikkelworkflow mogelijk is.

Vindplaats

Afgeleid van event-typen en statuswijzigingen in GitLab's event stream, of door timestamp-velden zoals 'created_at', 'merged_at' en 'closed_at' te interpreteren op Issues en Merge Requests.

Voorbeelden
Issue AangemaaktOntwikkeling gestartMerge Request gemergedPipeline MisluktGedeployd naar productie
Development Item
DevelopmentItem
De unieke identificatie voor een werkeenheid, zoals een feature, bugfix of task, dienend als de primaire case-identificatie.
Omschrijving

Een Development Item is een individueel, traceerbaar werkitem binnen de softwareontwikkelingscyclus. Het koppelt alle relevante activiteiten, van creatie tot de uiteindelijke deployment, aan elkaar in één logische case. In GitLab wordt dit meestal weergegeven door de interne ID (IID) van de Issue, die uniek is binnen een project.

Door op Development Items te analyseren, kunt u de end-to-end doorlooptijd meten, bottlenecks identificeren en de procescompliance bewaken. Het biedt u het nodige inzicht in de efficiëntie van uw voortbrengingsproces, van concept tot productie.

Het belang

Dit is de essentiële case-identificatie die alle process events met elkaar verbindt, waardoor het mogelijk wordt de volledige lifecycle van elk werkitem te traceren.

Vindplaats

Dit is typisch de interne ID (IID) van een GitLab Issue. Het kan worden gevonden in de Issues API-respons als het 'iid'-veld.

Voorbeelden
1024512PRJ-2345
Starttijd
StartTime
De `timestamp` die aangeeft wanneer een `activiteit` of `event` begon.
Omschrijving

StartTime markeert de precieze datum en tijd waarop een specifieke activiteit plaatsvond. Voor events in GitLab wordt dit vastgelegd in verschillende timestamp-velden. Bijvoorbeeld, de StartTime van de activiteit 'Issue Aangemaakt' zou de created_at timestamp van de issue zijn, terwijl de StartTime van de activiteit 'Merge Request Gemerged' de merged_at timestamp van de merge request zou zijn.

Deze timestamp is het kern tijdselement in process mining. Het wordt gebruikt om events chronologisch te ordenen, duren tussen activiteiten te berekenen, cyclustijden te meten en procesprestaties over tijd te analyseren.

Het belang

Dit attribuut geeft de chronologische sequentie van events weer, wat essentieel is voor het berekenen van alle tijdsgebonden metrics en het begrijpen van de procesflow.

Vindplaats

Geëxtraheerd uit verschillende timestamp-velden in GitLab, zoals 'created_at', 'updated_at', 'closed_at' op issues, en 'merged_at' op merge requests.

Voorbeelden
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Dev Item Type
DevelopmentItemType
De classificatie van het ontwikkelitem, zoals 'Feature', 'Bug', 'Task' of 'Maintenance'.
Omschrijving

Dit attribuut categoriseert de aard van het uitgevoerde werk. In GitLab wordt dit veelal geïmplementeerd met behulp van labels op een issue. Teams gebruiken labels om onderscheid te maken tussen nieuwe functionaliteit, defectoplossing, technische schuld en andere werktypen.

Analyseren per ontwikkelitemtype maakt het mogelijk om procesflows en cyclustijden voor verschillende soorten werk te vergelijken. Men kan bijvoorbeeld analyseren of bugs sneller worden opgelost dan features worden ontwikkeld, of dat technische schuld-taken een ander reviewproces volgen.

Het belang

Het segmenteren van het proces op werktype helpt te identificeren of bepaalde soorten werk meer vatbaar zijn voor vertragingen, herwerk of afwijkingen.

Vindplaats

Gewoonlijk afgeleid van de 'labels' die zijn toegepast op een GitLab Issue. Er is een mapping logic nodig om specifieke labels om te zetten in gestandaardiseerde types.

Voorbeelden
FeatureBugTaskTechnische Schuld
Eindtijd
EndTime
De timestamp die aangeeft wanneer een activiteit of event is voltooid.
Omschrijving

EndTime markeert de precieze datum en tijd waarop een activiteit is voltooid. Voor veel atomaire events in GitLab, zoals 'Issue Created', is de EndTime gelijk aan de StartTime. Voor activiteiten die een duur hebben, zoals 'Code Review', vertegenwoordigt het de voltooiing timestamp, bijvoorbeeld wanneer de uiteindelijke goedkeuring wordt gegeven.

Dit attribuut is essentieel voor het nauwkeurig berekenen van de duur van individuele activiteiten (Processing Time). Het helpt bij gedetailleerde knelpuntanalyse door onderscheid te maken tussen de tijd die actief aan een taak is besteed en de wachttijd tussen taken.

Het belang

Maakt de berekening van precieze activiteitsduren (processing times) mogelijk, wat essentieel is voor het identificeren van inefficiënte stappen in het proces.

Vindplaats

Voor atomaire events is dit hetzelfde als StartTime. Voor langdurige activiteiten moet dit worden afgeleid door een overeenkomstig voltooiingsevent in de data te vinden.

Voorbeelden
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
Ernst
Severity
Het ernstniveau van het ontwikkelitem, typisch voor bugs of incidenten.
Omschrijving

Ernst (Severity) geeft de impact van een bug of issue aan, variërend van kritiek tot minder belangrijk. GitLab heeft geen native severity-veld, dus dit wordt bijna altijd geïmplementeerd met behulp van labels (bijv. 'severity::1', 'severity::2').

Dit attribuut is essentieel voor het 'Severity Escalation Trends' dashboard en de bijbehorende KPI. Het analyseren van veranderingen in ernst gedurende de levenscyclus kan problemen aan het licht brengen die aanvankelijk werden onderschat of processen die problemen verergeren.

Het belang

Helpt bij het prioriteren van werk en het analyseren of items met hoge ernst sneller worden afgehandeld. Het volgen van wijzigingen ondersteunt de KPI 'Frequentie van Ernstescalatie'.

Vindplaats

Afgeleid van de 'labels' die zijn toegepast op een GitLab Issue. Er is een mapping vereist om labels zoals 'S1', 'S2' te interpreteren als severity levels.

Voorbeelden
1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
Projectnaam
ProjectName
De naam van het GitLab-project waartoe het ontwikkelitem behoort.
Omschrijving

Dit attribuut identificeert de specifieke code repository of het project waar het werk wordt uitgevoerd. In GitLab is elke issue en merge request opgenomen binnen een project.

Analyseren per projectnaam maakt prestatievergelijkingen mogelijk tussen verschillende producten, componenten of services. Het kan helpen identificeren of bepaalde projecten gezondere SDLC-processen hebben dan andere en is nuttig voor het filteren van dashboards naar een specifiek interessegebied.

Het belang

Maakt procesanalyse mogelijk die gesegmenteerd kan worden per product, applicatie of component, wat gerichte verbeteringsinspanningen vergemakkelijkt.

Vindplaats

Opgehaald uit de velden 'name' of 'path_with_namespace' in de Project API, gekoppeld via de 'project_id' in Issues en Merge Requests.

Voorbeelden
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Toegewezen gebruiker
Assignee
De gebruiker die is toegewezen aan de issue of merge request op het moment van het event.
Omschrijving

De toegewezene (Assignee) is de individuele ontwikkelaar of gebruiker die op een bepaald moment in het proces verantwoordelijk is voor het werkitem. In GitLab wordt dit vastgelegd in het veld assignee of assignees van een Issue of Merge Request.

Analyseren per toegewezene (Assignee) is cruciaal voor het 'Developer Workload & Allocation' dashboard. Het helpt bij het begrijpen van resource-utilisatie, het identificeren van overbelaste individuen of teams, en het analyseren van handoffs tussen verschillende personen.

Het belang

Volgt wie het werk heeft uitgevoerd, wat een analyse van de werkbelasting, efficiënte resource-allocatie en de identificatie van vertragingen door overdrachten mogelijk maakt.

Vindplaats

Opgehaald uit de velden 'assignee.username' of 'assignees' in de GitLab Issues en Merge Requests API-responses.

Voorbeelden
jdoeasmithr.williams
Bewerkingstijd
ProcessingTime
De duur van een enkele activiteit, berekend als het verschil tussen de eind- en starttijd.
Omschrijving

Verwerkingstijd meet de actieve werktijd voor een specifieke activiteit, onderscheiden van de wachttijd tussen activiteiten. Het wordt berekend als Eindtijd minus Starttijd voor één event record. Voor directe events is de verwerkingstijd nul.

Deze metric is cruciaal voor Fase-specifieke Knelpuntanalyse. Door de verwerkingstijden van activiteiten binnen een fase, zoals Code Review, te aggregeren, kunnen analisten precies bepalen hoeveel tijd actief aan werk wordt besteed, wat helpt bij het opsporen van inefficiënte processtappen.

Het belang

Meet de duur van individuele activiteiten, wat helpt om actieve werktijd te onderscheiden van inactieve wachttijd voor nauwkeurige knelpuntanalyse.

Vindplaats

Berekend door de process mining-tool als het verschil tussen de EndTime en StartTime van een activiteit.

Voorbeelden
2 uur en 30 minuten0 minuten3 dagen 8 uur
Bronsysteem
SourceSystem
Identificeert het systeem waaruit de data afkomstig is.
Omschrijving

Dit attribuut specificeert de oorsprong van de procesdata. Voor dit datamodel zal de waarde consistent 'GitLab' zijn.

Het opnemen van dit attribuut is cruciaal in omgevingen waar procesdata kan worden gecombineerd uit meerdere systemen, zoals Jira voor planning en GitLab voor uitvoering. Het maakt filtering en segmentatie mogelijk en helpt bij het handhaven van data lineage.

Het belang

Zorgt voor duidelijkheid over de data-oorsprong, wat cruciaal is voor data governance en bij het integreren van data uit meerdere bedrijfssystemen.

Vindplaats

Dit is een statische waarde, 'GitLab', toegevoegd tijdens het data transformatieproces.

Voorbeelden
GitLab
Dev Item Status
DevelopmentItemStatus
De status van het ontwikkelitem op het moment van het event, zoals 'Open', 'In Progress' of 'Gesloten'.
Omschrijving

Dit attribuut weerspiegelt de status van het primaire werkitem, typisch een Issue in GitLab. GitLab Issues hebben een state die 'opened' of 'closed' kan zijn. Meer gedetailleerde statussen worden vaak beheerd met behulp van scoped labels (bijv. 'Status::Triage', 'Status::In-Dev', 'Status::In-Review').

Het volgen van statuswijzigingen is cruciaal voor het begrijpen van de case lifecycle. Het helpt identificeren hoe lang items in elke status blijven en kan worden gebruikt om te filteren op actief of voltooid werk in dashboards zoals 'SDLC End-to-End Cycle Time'.

Het belang

Biedt een momentopname van de status van de case, waardoor analyse van de bestede tijd in verschillende fasen en filtering op lopend versus voltooid werk mogelijk is.

Vindplaats

De primaire status komt uit het 'state'-veld van een GitLab Issue ('opened', 'closed'). Meer gedetailleerde statussen worden vaak afgeleid van labels.

Voorbeelden
openedclosedIn uitvoeringIn beoordeling
Doorlooptijd
CycleTime
De totale verstreken tijd van de eerste activiteit tot de laatste activiteit voor een ontwikkelitem.
Omschrijving

Cycle Time is een berekende metric die de totale duur van een case meet. Het wordt doorgaans berekend als het tijdsverschil tussen het allereerste event (bijv. 'Issue Created') en het allerlaatste event (bijv. 'Deployed to Production') voor een enkel Development Item.

Dit is een primaire KPI voor het meten van de algehele procesefficiëntie. Het is de belangrijkste metric in dashboards zoals 'SDLC End-to-End Cycle Time' en wordt gebruikt om verbeteringen te volgen en langdurige cases te identificeren die systemische problemen kunnen aanduiden.

Het belang

Dit is een kern process mining KPI die de end-to-end efficiëntie van de ontwikkelingslevenscyclus meet.

Vindplaats

Berekend door de process mining-tool door de minimale StartTime af te trekken van de maximale StartTime voor elke unieke CaseId.

Voorbeelden
10 dagen 4 uur23 uur 15 minuten35 dagen
Is herstelwerk
IsRework
Een booleaanse vlag die aangeeft of een activity deel uitmaakt van een herstelwerk-lus.
Omschrijving

Dit berekende attribuut markeert activiteiten die een stap terug in het proces vertegenwoordigen, zoals terugkeren naar ontwikkeling nadat testen al is begonnen. De logica voor deze markering omvat typisch het detecteren van specifieke sequenties van activiteiten, bijvoorbeeld een 'Ontwikkeling Gestart' event dat plaatsvindt na een 'Pipeline Mislukt' of 'QA Testing Gestart' event voor dezelfde case.

Dit attribuut voedt direct het 'Rework & Rerun Analysis' dashboard en de 'Rework Rate After Testing' KPI. Het maakt eenvoudige filtering en kwantificering van herwerk mogelijk, waardoor teams de frequentie, oorzaken en impact ervan op projecttijdlijnen beter begrijpen.

Het belang

Vlagt en kwantificeert direct herbewerking, waardoor het gemakkelijk wordt om de oorzaken en impact van procesinefficiënties en kwaliteitsproblemen te analyseren.

Vindplaats

Berekend door de process mining-tool door de sequentie van activiteiten voor elk case te analyseren en patronen te identificeren die herbewerking aanduiden.

Voorbeelden
truefalse
Laatste data-update
LastDataUpdate
De timestamp die aangeeft wanneer de data voor dit event voor het laatst is ververst vanuit het bronsysteem.
Omschrijving

Dit attribuut registreert de datum en tijd waarop de event data voor het laatst is geëxtraheerd of bijgewerkt in de process mining dataset. Het vertegenwoordigt niet wanneer het event plaatsvond, maar eerder wanneer de registratie van het event voor het laatst is gesynchroniseerd.

Deze informatie is essentieel voor het begrijpen van de actualiteit van de data en het valideren van de tijdigheid van de procesanalyse. Het helpt gebruikers erop te vertrouwen dat de dashboards en KPI's gebaseerd zijn op recente data en informeert hen over de potentiële vertraging tussen het bronsysteem en de analyse.

Het belang

Biedt transparantie over de actualiteit van data, waardoor gebruikers weten hoe actueel de procesanalyse is.

Vindplaats

Deze timestamp wordt gegenereerd en vastgelegd door de data-extractietool of het ETL-proces op het moment van een data refresh.

Voorbeelden
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Merge Request Status
MergeRequestStatus
De status van de merge request die gekoppeld is aan het event, zoals 'Opened', 'Merged' of 'Closed'.
Omschrijving

Dit attribuut legt de status vast van een Merge Request (MR) op het moment van een event. GitLab MRs hebben verschillende statussen: 'opened', 'closed', 'merged' of 'locked'. Dit staat los van de algehele ontwikkelitemstatus.

Het volgen van de MR-status is cruciaal voor het analyseren van de code-integratiefase van de SDLC. Het ondersteunt direct dashboards zoals 'Code Review Cycle Time & Throughput' en helpt vertragingen tussen MR-creatie, review, goedkeuring en mergen op te sporen.

Het belang

Biedt inzicht in het code review- en mergeproces, wat vaak een kritisch knelpunt is in de SDLC.

Vindplaats

Opgehaald uit het veld 'state' in de GitLab Merge Requests API-response.

Voorbeelden
openedmergedclosedlocked
Milestone Titel
MilestoneTitle
De titel van de milestone of sprint waaraan het ontwikkelitem is toegewezen.
Omschrijving

Een Milestone in GitLab wordt gebruikt om werk te volgen tegen een specifiek doel of een tijdbox, zoals een sprint of een releaseversie. Dit attribuut legt de naam of titel van die milestone vast.

Dit attribuut maakt het mogelijk procesprestaties te analyseren binnen de context van specifieke sprints of planningsperioden. Het kan worden gebruikt om te zien of cyclustijden verbeteren van de ene sprint naar de andere, of om de procesweergave te filteren om alleen werk te tonen dat gerelateerd is aan een aankomende release.

Het belang

Koppelt ontwikkelwerk aan planningscycli zoals sprints of releases, waardoor analyse van prestaties ten opzichte van geplande timeboxes mogelijk is.

Vindplaats

Opgehaald uit het veld 'milestone.title' in de GitLab Issues of Merge Requests API-responses.

Voorbeelden
Q4-2023 ReleaseSprint 23.11Fase 1: MVP
Overdrachtwachttijd
HandoffWaitTime
Berekende idle time tussen twee opeenvolgende activiteiten uitgevoerd door verschillende assignees.
Omschrijving

Deze metric berekent de duur van de kloof tussen de voltooiing van één activiteit en de start van de volgende, specifiek wanneer de toegewezene verandert. Het meet bijvoorbeeld de tijd vanaf het moment dat een ontwikkelaar zijn werk voltooit tot wanneer een reviewer de code review start.

Dit is de belangrijkste metric voor de KPI 'Gemiddelde Handoff Wachttijd'. Het helpt verborgen inefficiënties in resource-allocatie en communicatie tussen teams of individuen bloot te leggen, en benadrukt vertragingen die geen deel uitmaken van actief werk.

Het belang

Kwantificeert inactieve tijd tijdens handoffs tussen verschillende personen of teams, en onthult verborgen vertragingen en communicatieknelpunten.

Vindplaats

Berekend door de process mining-tool. Dit vereist het analyseren van opeenvolgende events binnen een case, controleren of de 'Assignee' anders is, en vervolgens het tijdsverschil berekenen.

Voorbeelden
1 dag 2 uur15 minuten8 uur
Pipeline Status
PipelineStatus
De status van de CI/CD pipeline-uitvoering, zoals 'Success', 'Failed' of 'Running'.
Omschrijving

Dit attribuut geeft het resultaat aan van een CI/CD pipeline-uitvoering die gekoppeld is aan een commit of merge request. Veelvoorkomende statussen in GitLab zijn 'running', 'pending', 'success', 'failed', 'canceled' en 'skipped'.

Deze data is essentieel voor het 'Rework & Rerun Analysis' dashboard. Frequente pipeline-storingen kunnen een belangrijke bron zijn van herwerk en vertraging, en het analyseren van hun frequentie, locatie en impact is cruciaal voor het verbeteren van de ontwikkelingsefficiëntie en codekwaliteit.

Het belang

Volgt het succes en falen van geautomatiseerde builds en tests, waarbij herwerkcycli en problemen met codekwaliteit of testautomatisering aan het licht komen.

Vindplaats

Opgehaald uit het veld 'status' in de GitLab CI/CD Pipelines API-response.

Voorbeelden
successmisluktrunninggeannuleerd
Releaseversie
ReleaseVersion
De geplande of werkelijke softwareversietag die is gekoppeld aan de deployment.
Omschrijving

Dit attribuut identificeert de specifieke software release waarvan een ontwikkelitem deel uitmaakt. In GitLab kan dit worden gekoppeld via een Milestone, een protected tag of een vermelding in de Releases feature.

Dit is essentieel voor het 'Release Schedule Adherence Tracking' dashboard. Door de werkelijke deploymentdatum te vergelijken met een geplande datum die gekoppeld is aan de releaseversie, kunnen organisaties hun vermogen meten om deadlines te halen en de oorzaken van releasevertragingen diagnosticeren.

Het belang

Koppelt development items aan een specifieke softwarerelease, wat cruciaal is voor het volgen van de releasevoortgang en de naleving van planningen.

Vindplaats

Dit kan afkomstig zijn van GitLab Releases, de naam van een git tag, of de titel van een milestone die wordt gebruikt voor releaseplanning.

Voorbeelden
v1.2.0v3.0.0-beta2023.4.1
Target Branch
TargetBranch
De naam van de doelbranch voor een merge request.
Omschrijving

De Target Branch is de branch waarin wijzigingen bedoeld zijn om te worden gemerged, bijvoorbeeld 'main', 'develop' of een release branch zoals 'release/1.5'. Dit is een essentieel stuk informatie voor elke Merge Request.

Analyseren per Target Branch kan verschillende procesgedragingen onthullen voor code die wordt gemerged naar verschillende bestemmingen. Merges naar 'main' kunnen bijvoorbeeld een rigoureuzer goedkeuringsproces en langere cyclustijden hebben dan merges naar een feature branch. Het kan ook helpen om productie-deployments te onderscheiden van andere typen code-integratie.

Het belang

Helpt onderscheid te maken tussen verschillende ontwikkel- en release-workflows, aangezien processen aanzienlijk kunnen variëren afhankelijk van de doelbranch.

Vindplaats

Opgehaald uit het veld 'target_branch' in de GitLab Merge Requests API-response.

Voorbeelden
maindeveloprelease/v2.1.0hotfix/user-auth-bug
Teamnaam
TeamName
Het ontwikkelingsteam dat is gekoppeld aan het project of de toegewezene.
Omschrijving

Teamnaam vertegenwoordigt de groep of squad die verantwoordelijk is voor het ontwikkelitem. Deze informatie is typisch geen standaardveld in GitLab en wordt vaak afgeleid uit projectnaamgevingsconventies, groepsstructuren of door toegewezenen te koppelen aan hun respectievelijke teams met behulp van een externe referentietabel.

Dit attribuut wordt gebruikt om procesprestaties op teamniveau te analyseren. Het helpt bij het vergelijken van efficiëntie, werkbelasting en naleving van het proces tussen verschillende teams, en ondersteunt dashboards zoals 'Fase-specifieke Knelpuntanalyse' vanuit een teamgebaseerd perspectief.

Het belang

Maakt prestatieanalyse en procesvergelijking tussen verschillende teams mogelijk, wat helpt bij het identificeren van teamspecifieke knelpunten of best practices.

Vindplaats

Vaak afgeleid door de projectnaam of toegewezene te koppelen aan een teamstructuur die buiten GitLab is gedefinieerd, of afgeleid uit GitLab-groephiërarchieën.

Voorbeelden
Frontend-AlphaBackend-ServicesPlatform-Infra
Verplicht Aanbevolen Optioneel

Software Development Lifecycle Activiteiten

Dit zijn de belangrijkste stappen en mijlpalen die je in je event log vastlegt voor een goede process discovery en het opsporen van knelpunten.
4 Aanbevolen 8 Optioneel
Activiteit Omschrijving
Gedeployd naar productie
Deze activiteit markeert de succesvolle deployment van de code naar de live productieomgeving, waardoor deze beschikbaar wordt voor eindgebruikers. Dit wordt vastgelegd wanneer een specifieke 'deploy to production' job in een GitLab CI/CD pipeline succesvol wordt voltooid.
Het belang

Dit is het primaire eind-event voor het proces, wat aangeeft dat waarde is geleverd. Het is essentieel voor het meten van de totale end-to-end SDLC-cyclustijd en releasefrequentie.

Vindplaats

Vastgelegd vanuit de 'finished_at'-timestamp van een succesvolle CI/CD-job die specifiek is aangewezen voor productie-deployment. GitLab's Environments-feature volgt dit expliciet.

Vastleggen

Gebruik de 'finished_at' timestamp van de succesvolle productie deployment CI job.

Gebeurtenistype explicit
Issue Aangemaakt
Deze activiteit markeert het begin van de ontwikkelingslevenscyclus, en vertegenwoordigt het aanmaken van een nieuw werkitem, zoals een feature, bug of task. Het wordt expliciet vastgelegd wanneer een gebruiker een nieuwe issue aanmaakt in GitLab, wat de creatie-timestamp registreert.
Het belang

Dit is het primaire start-event voor het end-to-end proces. Het analyseren van de tijd van issue-creatie tot deployment geeft een compleet beeld van de SDLC-cyclustijd.

Vindplaats

Dit is een expliciet event vastgelegd uit de 'created_at' timestamp in de 'issues' tabel of via de Issues API. Systeemnotities registreren ook het creatie-event.

Vastleggen

Gebruik de 'created_at' timestamp van de issue.

Gebeurtenistype explicit
Merge Request aangemaakt
Geeft aan dat het initiële ontwikkelwerk voltooid is en de code klaar is voor review en integratie. Dit is een expliciet, cruciaal event in de GitLab workflow, vastgelegd wanneer een ontwikkelaar een nieuwe merge request (MR) opent.
Het belang

Dit is een kritieke mijlpaal die de handoff markeert van ontwikkeling naar review en testen. Het is het instappunt voor het analyseren van de gehele code review- en CI/CD pipeline-cyclus.

Vindplaats

Dit is een expliciet event vastgelegd uit de 'created_at' timestamp in de 'merge_requests' tabel of via de Merge Requests API.

Vastleggen

Gebruik de 'created_at' timestamp van de merge request.

Gebeurtenistype explicit
Merge Request gemerged
Deze activiteit betekent de succesvolle voltooiing van het code review- en integratieproces. Het is een expliciet event dat plaatsvindt wanneer een gebruiker de branch van de merge request merget in de target branch.
Het belang

Dit is een belangrijke mijlpaal die aangeeft dat ontwikkeling en review voltooid zijn. Het dient als het eindpunt voor het meten van de ontwikkelingscyclustijd en het startpunt voor het meten van de deployment lead time.

Vindplaats

Dit is een expliciet event vastgelegd uit de 'merged_at' timestamp in de 'merge_requests' tabel. Een systeemnotitie wordt ook gegenereerd bij het mergen.

Vastleggen

Gebruik de 'merged_at' timestamp van de merge request.

Gebeurtenistype explicit
Code review gestart
Markeert het begin van het peer review proces voor een merge request. Dit event wordt afgeleid van de eerste review-gerelateerde actie, zoals de eerste opmerking of thread die door iemand anders dan de auteur is geplaatst.
Het belang

Het meten van de tijd van MR-creatie tot het begin van de review benadrukt wachtrijvertragingen. Het verkorten van deze wachttijd is essentieel om de totale code review cyclus te verkorten.

Vindplaats

Afgeleid van de timestamp van de eerste opmerking of review thread op de merge request die niet van de MR-auteur afkomstig is. Deze data is beschikbaar via systeemnotities of de Notes API.

Vastleggen

Vind de timestamp van de eerste gebruikersopmerking bij een MR van een niet-auteur.

Gebeurtenistype inferred
Goedkeuring toegevoegd
Vertegenwoordigt een formele goedkeuring van de codewijzigingen in een merge request door een reviewer. Dit is een expliciet event dat door GitLab wordt vastgelegd wanneer een gebruiker op de knop 'Approve' klikt.
Het belang

Goedkeuringen zijn cruciale kwaliteitspoorten. Het bijhouden ervan helpt de benodigde tijd voor vereiste goedkeuringen te analyseren en waarborgt compliance met reviewbeleid.

Vindplaats

Vastgelegd uit merge request-goedkeuringsevens. Deze zijn beschikbaar via de Approvals API of zijn te zien in de geschiedenis van de MR.

Vastleggen

Gebruik de timestamp uit het event log van de merge request goedkeuring.

Gebeurtenistype explicit
Implementatie gestart
Vertegenwoordigt het begin van het proces om code vrij te geven aan een specifieke omgeving, zoals staging of productie. In GitLab komt dit overeen met de start van een 'deploy' job binnen een CI/CD pipeline.
Het belang

Het volgen van de start van deployment helpt de duur van de deploymentfase te isoleren. Het is cruciaal voor het meten en optimaliseren van de deployment lead time.

Vindplaats

Vastgelegd vanuit de 'started_at'-timestamp van een CI/CD-job die is geconfigureerd als een deployment-job. Dit maakt deel uit van GitLab's Environments and Deployments-feature.

Vastleggen

Gebruik de 'started_at' timestamp uit het CI job log voor een deployment taak.

Gebeurtenistype explicit
Ontwikkeling gestart
Deze activiteit markeert het begin van actief codeerwerk aan de issue. Dit wordt typisch afgeleid van de eerste code-commit die naar een branch is gepusht die gekoppeld is aan de issue, aangezien GitLab geen expliciete 'start development'-knop heeft.
Het belang

Lokaliseert het exacte begin van waardetoevoegend ontwikkelwerk, waardoor nauwkeurige meting van de pure codeerfase mogelijk is en deze wordt gescheiden van planning of wachttijd.

Vindplaats

Afgeleid door de timestamp van de eerste commit te vinden op een feature branch die gekoppeld is aan de issue. Dit vereist het koppelen van issues aan branches, vaak gedaan via naamgevingsconventies of metadata.

Vastleggen

Vind de timestamp van de eerste commit op een branch die gekoppeld is aan de issue ID.

Gebeurtenistype inferred
Pipeline gestart
Vertegenwoordigt de initiatie van een geautomatiseerde CI/CD-pipeline, die typisch builds, tests en beveiligingsscans uitvoert. GitLab creëert expliciet een pipeline record met een start timestamp wanneer een pipeline wordt getriggerd, bijvoorbeeld door een commit of MR-creatie.
Het belang

Het volgen van pipeline-uitvoeringen is essentieel voor het monitoren van de gezondheid en efficiëntie van geautomatiseerde test- en integratieprocessen. Het helpt te identificeren hoeveel tijd wordt besteed aan geautomatiseerde validatie.

Vindplaats

Vastgelegd vanuit de 'created_at'- of 'started_at'-timestamp van een pipeline-record in de 'ci_pipelines'-tabel of via de Pipelines API.

Vastleggen

Gebruik de timestamp uit de pipeline execution record die gekoppeld is aan de branch van de MR.

Gebeurtenistype explicit
Pipeline Mislukt
Deze activiteit vindt plaats wanneer een CI/CD pipeline-uitvoering in enig stadium faalt, zoals een build-fout of een mislukte test. GitLab registreert expliciet de uiteindelijke status van elke pipeline, waardoor storingen eenvoudig te identificeren zijn.
Het belang

Pipeline storingen zijn een belangrijke oorzaak van herwerk. Het analyseren van hun frequentie, duur en oorzaak helpt bij het identificeren van kwaliteitsproblemen, onbetrouwbare tests en knelpunten in de feedback loop naar ontwikkelaars.

Vindplaats

Geïdentificeerd door een 'failed' status op een pipeline record in de 'ci_pipelines' tabel. De 'finished_at' timestamp geeft aan wanneer de storing optrad.

Vastleggen

Filter op pipeline records met de status 'failed' en gebruik de 'finished_at' timestamp.

Gebeurtenistype explicit
Probleem afgesloten
Vertegenwoordigt de definitieve administratieve sluiting van het werkitem, typisch nadat de wijzigingen zijn gedeployed en geverifieerd. Dit is een expliciet event dat wordt vastgelegd wanneer een gebruiker de issue in GitLab sluit.
Het belang

Het sluiten van een issue betekent vaak het definitieve einde van alle gerelateerde werkzaamheden. Een vergelijking hiervan met de deployment-tijd kan vertragingen in post-deployment validatie of administratieve processen onthullen.

Vindplaats

Dit is een expliciet event vastgelegd uit de 'closed_at' timestamp in de 'issues' tabel of uit de corresponderende systeemnotitie.

Vastleggen

Gebruik de 'closed_at' timestamp van de issue.

Gebeurtenistype explicit
Probleem toegewezen
Vertegenwoordigt de toewijzing van een issue aan een specifieke ontwikkelaar of team, wat aangeeft dat het eigendom voor het werk is vastgesteld. Dit is een expliciet event dat door GitLab wordt gelogd wanneer het assignee-veld van een issue wordt ingevuld of gewijzigd.
Het belang

Het volgen van toewijzingen is cruciaal voor het analyseren van resource-allocatie, teamwerkbelasting en handoff-tijden. Het helpt vertragingen te identificeren tussen het moment waarop werk wordt aangemaakt en wanneer het wordt opgepakt.

Vindplaats

Vastgelegd uit GitLab's systeemnotities voor het issue, die registreren wanneer een 'assignee' wordt toegevoegd of gewijzigd. De event timestamp is vastgelegd in de notitie.

Vastleggen

Extraheer 'assignee changed'-events uit de systeemnotities van het issue.

Gebeurtenistype explicit
Aanbevolen Optioneel

Extractie Guides

Hoe u uw data uit GitLab haalt