Uw Software Development Lifecycle Data Template
Uw Software Development Lifecycle Data Template
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen
- Richtlijnen voor data-extractie
Software Development Lifecycle Attributen
| 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 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 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 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
|
|||
Software Development Lifecycle Activiteiten
| 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
|
|||