Datatemplate voor de softwareontwikkelingscyclus
Datatemplate voor de softwareontwikkelingscyclus
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om bij te houden
- Uitleg over data-extractie
Attributen voor de softwareontwikkelingscyclus
| Naam | Beschrijving | ||
|---|---|---|---|
|
Activiteit
Activity
|
De naam van de specifieke processtap of gebeurtenis, zoals 'Issue aangemaakt' of 'Merge request samengevoegd'. | ||
|
Beschrijving
Het attribuut Activiteit legt de afzonderlijke gebeurtenissen vast die bij een ontwikkelitem plaatsvinden. Deze staan niet in één veld in GitLab, maar worden afgeleid van verschillende acties en timestampvelden in Issues, Merge Requests en CI/CD Pipelines. Voorbeelden van activiteiten zijn het aanmaken van een issue, het pushen van een commit, het mislukken van een pipeline en het goedkeuren van een merge request. Dit attribuut vormt de basis voor de proceskaart, de visualisatie van de workflow en de analyse van de volgorde en frequentie van gebeurtenissen. Je gebruikt het om afwijkingen, bottlenecks tussen stappen en veelvoorkomende procesroutes te vinden.
Waarom dit belangrijk is
Dit bepaalt de stappen op de proceskaart en maakt het mogelijk de ontwikkelworkflow van begin tot eind te visualiseren en analyseren.
Waar vind je dit?
Afgeleid van gebeurtenistypen en statuswijzigingen in de eventstream van GitLab, of door timestampvelden zoals
Voorbeelden
Issue aangemaaktOntwikkeling gestartMerge request samengevoegdPipeline misluktNaar productie geïmplementeerd
|
|||
|
Ontwikkelitem
DevelopmentItem
|
De unieke identificatie van een werkeenheid, zoals een functie, bugfix of taak. Dit is de primaire case-ID. | ||
|
Beschrijving
Een ontwikkelitem is een afzonderlijk, traceerbaar stuk werk dat de softwareontwikkelingscyclus doorloopt. Het verbindt alle bijbehorende activiteiten, van aanmaak tot uiteindelijke implementatie, in één samenhangende case. In GitLab is dit meestal het interne ID (IID) van een issue, dat binnen een project uniek is. Door ontwikkelitems te analyseren, kun je de doorlooptijd van begin tot eind meten, bottlenecks opsporen en controleren of het proces wordt gevolgd. Zo zie je hoe efficiënt werk van idee tot productie wordt opgeleverd.
Waarom dit belangrijk is
Dit is de essentiële case-ID die alle procesgebeurtenissen met elkaar verbindt. Zo kun je de volledige levenscyclus van elk werkitem volgen.
Waar vind je dit?
Dit is meestal het interne ID (IID) van een GitLab-issue. Je vindt het in het veld
Voorbeelden
1024512PRJ-2345
|
|||
|
Starttijd
StartTime
|
De timestamp die aangeeft wanneer een activiteit of gebeurtenis begon. | ||
|
Beschrijving
StartTime geeft de exacte datum en tijd aan waarop een specifieke activiteit plaatsvond. In GitLab wordt dit vastgelegd in verschillende timestampvelden. De StartTime van de activiteit 'Issue aangemaakt' is bijvoorbeeld de timestamp Deze timestamp vormt de tijdsbasis voor process mining. Je gebruikt hem om gebeurtenissen chronologisch te ordenen, de tijd tussen activiteiten te berekenen, doorlooptijden te meten en procesprestaties over tijd te analyseren.
Waarom dit belangrijk is
Dit attribuut geeft de chronologische volgorde van gebeurtenissen weer. Die is nodig om tijdsgebonden metrieken te berekenen en het procesverloop te begrijpen.
Waar vind je dit?
Afkomstig uit verschillende timestampvelden in GitLab, zoals
Voorbeelden
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
Eindtijd
EndTime
|
De timestamp die aangeeft wanneer een activiteit of gebeurtenis is afgerond. | ||
|
Beschrijving
EndTime geeft de exacte datum en tijd aan waarop een activiteit is afgerond. Bij veel afzonderlijke gebeurtenissen in GitLab, zoals 'Issue aangemaakt', is de EndTime gelijk aan de StartTime. Bij activiteiten met een duur, zoals 'Codebeoordeling', geeft deze de afrondingstijd aan, bijvoorbeeld het moment waarop de laatste goedkeuring wordt gegeven. Dit attribuut is nodig om de duur van afzonderlijke activiteiten (verwerkingstijd) nauwkeurig te berekenen. Het helpt bij een gedetailleerde bottleneckanalyse, doordat je de tijd waarin actief aan een taak wordt gewerkt kunt onderscheiden van de wachttijd tussen taken.
Waarom dit belangrijk is
Maakt het mogelijk de duur van activiteiten (verwerkingstijden) nauwkeurig te berekenen. Dat helpt om inefficiënte processtappen op te sporen.
Waar vind je dit?
Bij afzonderlijke gebeurtenissen is dit hetzelfde als StartTime. Bij activiteiten met een duur moet je de eindtijd afleiden uit een bijbehorende voltooiingsgebeurtenis in de data.
Voorbeelden
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Ernst
Severity
|
De ernst van het ontwikkelitem, meestal bij bugs of incidenten. | ||
|
Beschrijving
Ernst geeft de impact van een bug of probleem aan, van kritiek tot gering. GitLab heeft geen standaardveld voor ernst. Daarom wordt dit vrijwel altijd met labels vastgelegd, zoals 'severity::1' of 'severity::2'. Dit attribuut is nodig voor het dashboard 'Trends in escalaties naar ernst' en de bijbehorende KPI. Door veranderingen in de ernst tijdens de levenscyclus te analyseren, kun je problemen vinden die aanvankelijk te laag zijn ingeschat, of processen die problemen verergeren.
Waarom dit belangrijk is
Helpt bij het prioriteren van werk en laat zien of problemen met een hoge ernst sneller worden afgehandeld. Door veranderingen bij te houden, kun je de KPI 'Frequentie van escalaties naar ernst' volgen.
Waar vind je dit?
Afgeleid van de labels op een GitLab-issue. Er is een mapping nodig om labels zoals 'S1' en 'S2' als ernstniveaus te interpreteren.
Voorbeelden
1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
|
|||
|
Projectnaam
ProjectName
|
De naam van het GitLab-project waartoe het ontwikkelitem behoort. | ||
|
Beschrijving
Dit attribuut geeft aan in welke specifieke coderepository of welk project het werk plaatsvindt. In GitLab horen elk issue en merge request bij een project. Door op projectnaam te analyseren, kun je prestaties van verschillende producten, onderdelen of diensten vergelijken. Zo zie je of de SDLC-processen in bepaalde projecten beter verlopen. Je kunt dashboards ook filteren op een specifiek gebied.
Waarom dit belangrijk is
Maakt het mogelijk het proces per product, applicatie of onderdeel te analyseren, zodat verbeteringen gericht kunnen worden aangepakt.
Waar vind je dit?
Afkomstig uit de velden
Voorbeelden
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Toegewezen persoon
Assignee
|
De gebruiker die op het moment van de gebeurtenis aan het issue of merge request is toegewezen. | ||
|
Beschrijving
De toegewezen persoon is de ontwikkelaar of gebruiker die op een bepaald moment in het proces verantwoordelijk is voor het werkitem. In GitLab staat deze in het veld Analyse op basis van toegewezen personen is belangrijk voor het dashboard 'Werklast en verdeling van ontwikkelaars'. Zo krijg je inzicht in de verdeling van werk, zie je welke personen of teams overbelast zijn en kun je overdrachten tussen mensen analyseren.
Waarom dit belangrijk is
Houdt bij wie het werk heeft uitgevoerd. Zo kun je de werklast en de efficiëntie van de werkverdeling analyseren en vertragingen door overdrachten opsporen.
Waar vind je dit?
Afkomstig uit de velden
Voorbeelden
jdoeasmithr.williams
|
|||
|
Type ontwikkelitem
DevelopmentItemType
|
De classificatie van het ontwikkelitem, zoals 'Functie', 'Bug', 'Taak' of 'Onderhoud'. | ||
|
Beschrijving
Dit attribuut deelt het soort werk in. In GitLab gebeurt dit meestal met labels op een issue. Teams gebruiken labels om nieuwe functies, het oplossen van defecten, technische schuld en andere soorten werk van elkaar te onderscheiden. Door ontwikkelitems op type te analyseren, kun je procesroutes en doorlooptijden voor verschillende soorten werk vergelijken. Zo kun je nagaan of bugs sneller worden opgelost dan functies worden ontwikkeld, of dat taken rond technische schuld een ander beoordelingsproces volgen.
Waarom dit belangrijk is
Door het proces op soort werk te segmenteren, zie je of bepaalde soorten werk vaker vertraging, herstelwerk of afwijkingen opleveren.
Waar vind je dit?
Meestal afgeleid van de labels op een GitLab-issue. Er is een mapping nodig om specifieke labels om te zetten naar gestandaardiseerde typen.
Voorbeelden
FunctieBugTaakTechnische schuld
|
|||
|
Bronsysteem
SourceSystem
|
Geeft aan uit welk systeem de data afkomstig is. | ||
|
Beschrijving
Dit attribuut geeft de herkomst van de procesdata aan. In dit datamodel is de waarde altijd 'GitLab'. Dit attribuut is belangrijk in omgevingen waar procesdata uit meerdere systemen wordt gecombineerd, bijvoorbeeld Jira voor planning en GitLab voor uitvoering. Je kunt ermee filteren en segmenteren en de herkomst van de data volgen.
Waarom dit belangrijk is
Maakt duidelijk waar de data vandaan komt. Dat is belangrijk voor datagovernance en voor het combineren van data uit meerdere bedrijfssystemen.
Waar vind je dit?
Dit is een vaste waarde, 'GitLab', die tijdens de datatransformatie wordt toegevoegd.
Voorbeelden
GitLab
|
|||
|
Doelbranch
TargetBranch
|
De naam van de branch waarin de wijzigingen van een merge request terechtkomen. | ||
|
Beschrijving
De doelbranch is de branch waarin wijzigingen moeten worden samengevoegd, bijvoorbeeld 'main', 'develop' of een releasebranch zoals 'release/1.5'. Dit is een belangrijk gegeven voor elke Merge Request. Door gegevens per doelbranch te analyseren, zie je of het proces verschilt naargelang de bestemming van de code. Voor samenvoegingen naar 'main' kan bijvoorbeeld een grondiger goedkeuringsproces gelden en kunnen de doorlooptijden langer zijn dan bij een featurebranch. Zo kun je ook productiedeployments onderscheiden van andere vormen van code-integratie.
Waarom dit belangrijk is
Helpt verschillende ontwikkel- en releaseworkflows van elkaar te onderscheiden, omdat het proces sterk kan verschillen per doelbranch.
Waar vind je dit?
Opgehaald uit het veld 'target_branch' in het antwoord van de GitLab Merge Requests API.
Voorbeelden
maindeveloprelease/v2.1.0hotfix/user-auth-bug
|
|||
|
Doorlooptijd
CycleTime
|
De totale tijd tussen de eerste en de laatste activiteit van een developmentitem. | ||
|
Beschrijving
Doorlooptijd is een berekende metriek die de totale duur van een case meet. Meestal bereken je deze door het tijdsverschil te nemen tussen de eerste gebeurtenis, bijvoorbeeld 'Issue aangemaakt', en de laatste gebeurtenis, bijvoorbeeld 'Naar productie gedeployed', voor één developmentitem. Dit is een belangrijke KPI voor de efficiëntie van het hele proces. De metriek staat centraal in dashboards zoals 'Doorlooptijd van de volledige softwareontwikkelingscyclus' en helpt verbeteringen bij te houden en langlopende cases op te sporen die op structurele problemen kunnen wijzen.
Waarom dit belangrijk is
Deze KPI voor process mining meet de efficiëntie van de volledige softwareontwikkelingscyclus.
Waar vind je dit?
Berekend door de process mining-tool: per unieke CaseId wordt de minimale StartTime afgetrokken van de maximale StartTime.
Voorbeelden
10 dagen en 4 uur23 uur en 15 minuten35 dagen
|
|||
|
Is herstelwerk
IsRework
|
Een booleaanse indicator die aangeeft of een activiteit deel uitmaakt van een herstelwerkcyclus. | ||
|
Beschrijving
Dit berekende attribuut markeert activiteiten die een stap terug in het proces betekenen, zoals teruggaan naar ontwikkeling nadat het testen al is begonnen. De indicator wordt meestal berekend door specifieke activiteitspatronen te herkennen. Een voorbeeld is een gebeurtenis 'Ontwikkeling gestart' na 'Pipeline mislukt' of 'QA-testen gestart' voor dezelfde case. Dit attribuut voedt het dashboard 'Analyse van herstelwerk en opnieuw uitvoeren' en de KPI 'Percentage herstelwerk na het testen'. Je kunt herstelwerk eenvoudig filteren en kwantificeren om de frequentie, oorzaken en gevolgen voor projectplanningen te onderzoeken.
Waarom dit belangrijk is
Markeert en kwantificeert herstelwerk, zodat je de oorzaken en gevolgen van inefficiënte processen en kwaliteitsproblemen kunt analyseren.
Waar vind je dit?
Berekend door de process mining-tool. Die analyseert de activiteitenvolgorde per case en herkent patronen die op herstelwerk wijzen.
Voorbeelden
truefalse
|
|||
|
Laatste data-update
LastDataUpdate
|
De timestamp die aangeeft wanneer de data voor deze gebeurtenis voor het laatst uit het bronsysteem is vernieuwd. | ||
|
Beschrijving
Dit attribuut registreert de datum en tijd waarop de gebeurtenisdata voor het laatst is geëxtraheerd of bijgewerkt in de process mining-dataset. Het geeft niet aan wanneer de gebeurtenis plaatsvond, maar wanneer de registratie ervan voor het laatst is gesynchroniseerd. Deze informatie is belangrijk om te weten hoe actueel de data is en of de procesanalyse op tijd is bijgewerkt. Zo zie je of de dashboards en KPI’s op recente data zijn gebaseerd en hoeveel vertraging er kan zitten tussen het bronsysteem en de analyse.
Waarom dit belangrijk is
Laat zien hoe actueel de data is, zodat duidelijk is hoe recent de procesanalyse is.
Waar vind je dit?
Deze timestamp wordt aangemaakt en vastgelegd door de data-extractietool of het ETL-proces wanneer de data wordt vernieuwd.
Voorbeelden
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Naam van milestone
MilestoneTitle
|
De naam van de milestone of sprint waaraan het developmentitem is toegewezen. | ||
|
Beschrijving
In GitLab gebruik je een milestone om werk bij te houden dat aan een specifiek doel of een bepaalde periode is gekoppeld, zoals een sprint of releaseversie. Dit attribuut bevat de naam of titel van die milestone. Met dit attribuut kun je de procesprestaties binnen specifieke sprints of planningsperioden analyseren. Je kunt bijvoorbeeld nagaan of de doorlooptijden van de ene sprint op de andere verbeteren, of de procesweergave filteren op werk voor een aankomende release.
Waarom dit belangrijk is
Koppelt ontwikkelwerk aan planningscycli, zoals sprints of releases, zodat je de prestaties kunt vergelijken met geplande perioden.
Waar vind je dit?
Opgehaald uit het veld 'milestone.title' in de antwoorden van de GitLab Issues- of Merge Requests-API.
Voorbeelden
Release vierde kwartaal 2023Sprint 23.11Fase 1: MVP
|
|||
|
Pipelinestatus
PipelineStatus
|
De status van de CI/CD-pipeline-uitvoering, zoals 'Geslaagd', 'Mislukt' of 'Wordt uitgevoerd'. | ||
|
Beschrijving
Dit attribuut geeft de uitkomst aan van een CI/CD-pipeline die bij een commit of merge request hoort. Veelvoorkomende statussen in GitLab zijn 'running', 'pending', 'success', 'failed', 'canceled' en 'skipped'. Deze data is essentieel voor het dashboard 'Analyse van herstelwerk en opnieuw uitvoeren'. Regelmatig mislukte pipelines kunnen veel herstelwerk en vertraging veroorzaken. Door te analyseren hoe vaak dit gebeurt, waar het gebeurt en wat de gevolgen zijn, kun je de efficiëntie van de ontwikkeling en de codekwaliteit verbeteren.
Waarom dit belangrijk is
Houdt bij welke geautomatiseerde builds en tests slagen of mislukken. Zo worden herstelwerk en problemen met codekwaliteit of testautomatisering zichtbaar.
Waar vind je dit?
Opgehaald uit het veld 'status' in het antwoord van de GitLab CI/CD Pipelines API.
Voorbeelden
successfailedrunningcanceled
|
|||
|
Releaseversie
ReleaseVersion
|
De geplande of werkelijke softwareversie die bij de deployment hoort. | ||
|
Beschrijving
Dit attribuut geeft aan bij welke specifieke softwarerelease een developmentitem hoort. In GitLab kan dit worden vastgelegd via een milestone, een beveiligde tag of een vermelding bij Releases. Dit attribuut is essentieel voor het dashboard 'Bijhouden of releases op schema liggen'. Door de werkelijke deploymentdatum te vergelijken met de geplande datum van de releaseversie, kunnen organisaties nagaan of releases op tijd worden geleverd en de oorzaken van vertraging achterhalen.
Waarom dit belangrijk is
Koppelt developmentitems aan een specifieke softwarerelease. Zo kun je de voortgang van releases en het halen van de planning bijhouden.
Waar vind je dit?
Je kunt dit gegeven ophalen uit GitLab Releases, de naam van een git-tag of de titel van een milestone voor de releaseplanning.
Voorbeelden
v1.2.0v3.0.0-beta2023.4.1
|
|||
|
Status ontwikkelitem
DevelopmentItemStatus
|
De status van het ontwikkelitem op het moment van de gebeurtenis, zoals 'Open', 'In uitvoering' of 'Gesloten'. | ||
|
Beschrijving
Dit attribuut geeft de status weer van het belangrijkste werkitem, meestal een issue in GitLab. GitLab-issues hebben een Door statuswijzigingen bij te houden, krijg je inzicht in de levenscyclus van een case. Je ziet hoelang items in elke status blijven en kunt dashboards zoals 'SDLC-doorlooptijd van begin tot eind' filteren op actief of afgerond werk.
Waarom dit belangrijk is
Geeft een momentopname van de status van de case. Zo kun je analyseren hoelang werk in verschillende fases blijft en lopend werk van afgerond werk onderscheiden.
Waar vind je dit?
De hoofdstatus komt uit het veld
Voorbeelden
openedclosedIn uitvoeringIn beoordeling
|
|||
|
Status van merge request
MergeRequestStatus
|
De status van de merge request die bij de gebeurtenis hoort, zoals 'Geopend', 'Samengevoegd' of 'Gesloten'. | ||
|
Beschrijving
Dit attribuut legt de status van een Merge Request (MR) vast op het moment van een gebeurtenis. GitLab-MR’s hebben verschillende statussen: 'opened', 'closed', 'merged' of 'locked'. Deze status staat los van de algemene status van het developmentitem. De MR-status bijhouden is belangrijk om de code-integratiefase van de softwareontwikkelingscyclus te analyseren. De status vormt de basis voor dashboards zoals 'Doorlooptijd en doorvoer van code reviews' en helpt vertragingen tussen het aanmaken, beoordelen, goedkeuren en samenvoegen van een MR op te sporen.
Waarom dit belangrijk is
Geeft inzicht in het proces voor code review en samenvoegen, dat in de softwareontwikkelingscyclus vaak een belangrijk bottleneck is.
Waar vind je dit?
Opgehaald uit het veld 'state' in het antwoord van de GitLab Merge Requests API.
Voorbeelden
openedmergedclosedlocked
|
|||
|
Teamnaam
TeamName
|
Het ontwikkelteam dat bij het project of de toegewezen persoon hoort. | ||
|
Beschrijving
Teamnaam geeft aan welke groep of welk team verantwoordelijk is voor het ontwikkelitem. Dit is meestal geen standaardveld in GitLab. De teamnaam wordt vaak afgeleid van naamgevingsconventies voor projecten of groepsstructuren, of door toegewezen personen via een externe referentietabel aan hun team te koppelen. Met dit attribuut kun je procesprestaties per team analyseren. Je kunt de efficiëntie, werklast en naleving van processen tussen teams vergelijken. Ook kun je teamdashboards maken, zoals 'Bottleneckanalyse per fase'.
Waarom dit belangrijk is
Maakt het mogelijk prestaties en processen tussen teams te vergelijken. Zo kun je teamspecifieke bottlenecks en goede werkwijzen opsporen.
Waar vind je dit?
Vaak afgeleid door de projectnaam of toegewezen persoon te koppelen aan een teamstructuur buiten GitLab, of door de groepshiërarchie in GitLab te gebruiken.
Voorbeelden
Frontend-AlphaBackend-ServicesPlatform-Infra
|
|||
|
Wachttijd bij overdracht
HandoffWaitTime
|
Berekende wachttijd tussen twee opeenvolgende activiteiten die door verschillende toegewezen personen worden uitgevoerd. | ||
|
Beschrijving
Deze metriek berekent de tijd tussen het afronden van een activiteit en het starten van de volgende, wanneer de toegewezen persoon verandert. Zo meet je bijvoorbeeld de tijd tussen het moment waarop een ontwikkelaar klaar is en het moment waarop een reviewer de code review start. Dit is de belangrijkste metriek voor de KPI 'Gemiddelde wachttijd bij overdracht'. De metriek maakt verborgen inefficiëntie in de verdeling van werk en communicatie tussen teams of personen zichtbaar. Zo komen vertragingen aan het licht die niet aan actief werk zijn toe te schrijven.
Waarom dit belangrijk is
Meet de wachttijd bij overdrachten tussen personen of teams en maakt zo verborgen vertragingen en communicatieknelpunten zichtbaar.
Waar vind je dit?
Berekend door de process mining-tool. Hiervoor worden opeenvolgende gebeurtenissen binnen een case geanalyseerd, wordt gecontroleerd of 'Toegewezen persoon' verschilt en wordt vervolgens het tijdsverschil berekend.
Voorbeelden
1 dag en 2 uur15 minuten8 uur
|
|||
Activiteiten in de softwareontwikkelingscyclus
| Activiteit | Beschrijving | ||
|---|---|---|---|
|
Issue aangemaakt
|
Deze activiteit markeert het begin van de ontwikkelcyclus: er wordt een nieuw werkitem aangemaakt, zoals een functie, bug of taak. GitLab registreert dit expliciet wanneer een gebruiker een issue aanmaakt, inclusief het tijdstip. | ||
|
Waarom dit belangrijk is
Dit is de belangrijkste startgebeurtenis van het end-to-endproces. De tijd tussen het aanmaken van een issue en de implementatie geeft een volledig beeld van de doorlooptijd van de SDLC.
Waar vind je dit?
Dit is een expliciete gebeurtenis, vastgelegd met de timestamp
Vastleggen
Gebruik de timestamp
Gebeurtenistype
explicit
|
|||
|
Merge request aangemaakt
|
Dit geeft aan dat het eerste ontwikkelwerk klaar is en de code kan worden beoordeeld en geïntegreerd. Het is een expliciete, belangrijke gebeurtenis in de GitLab-workflow, die wordt vastgelegd wanneer een ontwikkelaar een nieuw merge request (MR) opent. | ||
|
Waarom dit belangrijk is
Dit is een belangrijk moment: het werk gaat van ontwikkeling over naar beoordeling en testen. Vanaf hier kun je de volledige cyclus van codebeoordeling en CI/CD analyseren.
Waar vind je dit?
Dit is een expliciete gebeurtenis, vastgelegd met de timestamp
Vastleggen
Gebruik de timestamp
Gebeurtenistype
explicit
|
|||
|
Merge request samengevoegd
|
Deze activiteit markeert de succesvolle afronding van de codebeoordeling en integratie. Het is een expliciete gebeurtenis die plaatsvindt wanneer een gebruiker de branch van het merge request samenvoegt met de doelbranch. | ||
|
Waarom dit belangrijk is
Dit is een belangrijke mijlpaal: de ontwikkeling en beoordeling zijn afgerond. Het is het eindpunt voor het meten van de ontwikkelcyclus en het startpunt voor het meten van de doorlooptijd tot implementatie.
Waar vind je dit?
Dit is een expliciete gebeurtenis, vastgelegd met de timestamp
Vastleggen
Gebruik de timestamp
Gebeurtenistype
explicit
|
|||
|
Naar productie geïmplementeerd
|
Deze activiteit markeert de succesvolle implementatie van code in de productieomgeving, waar eindgebruikers de code kunnen gebruiken. Dit wordt vastgelegd wanneer een specifieke job voor implementatie naar productie in een GitLab CI/CD-pipeline succesvol is afgerond. | ||
|
Waarom dit belangrijk is
Dit is de belangrijkste eindgebeurtenis van het proces en geeft aan dat de waarde is geleverd. Deze gebeurtenis is nodig om de totale doorlooptijd van de SDLC en de releasefrequentie te meten.
Waar vind je dit?
Dit wordt vastgelegd met de timestamp
Vastleggen
Gebruik de timestamp
Gebeurtenistype
explicit
|
|||
|
Codebeoordeling gestart
|
Dit markeert het begin van de collegiale beoordeling van een merge request. De gebeurtenis wordt afgeleid van de eerste actie rond de beoordeling, zoals de eerste opmerking of thread van iemand anders dan de auteur. | ||
|
Waarom dit belangrijk is
De tijd tussen het aanmaken van een MR en de start van de beoordeling laat wachtrijen zien. Minder wachttijd is belangrijk om de totale codebeoordelingscyclus te verkorten.
Waar vind je dit?
Dit wordt afgeleid van de timestamp van de eerste opmerking of beoordelingsthread op het merge request van iemand anders dan de auteur van de MR. Deze data is beschikbaar via systeemnotities of de Notes API.
Vastleggen
Zoek de timestamp van de eerste opmerking op een MR van iemand die niet de auteur is.
Gebeurtenistype
inferred
|
|||
|
Goedkeuring toegevoegd
|
Dit is de formele goedkeuring van codewijzigingen in een merge request door een beoordelaar. GitLab legt deze gebeurtenis expliciet vast wanneer een gebruiker op de knop 'Approve' klikt. | ||
|
Waarom dit belangrijk is
Goedkeuringen zijn belangrijke kwaliteitscontroles. Door ze bij te houden, kun je zien hoelang het duurt om de vereiste goedkeuringen te krijgen en controleren of het beoordelingsbeleid wordt nageleefd.
Waar vind je dit?
Dit wordt vastgelegd als gebeurtenis voor goedkeuring van een merge request. De gegevens zijn beschikbaar via de Approvals API of in de geschiedenis van de MR.
Vastleggen
Gebruik de timestamp uit het gebeurtenislogboek voor goedkeuringen van merge requests.
Gebeurtenistype
explicit
|
|||
|
Implementatie gestart
|
Dit markeert het begin van het proces om code naar een specifieke omgeving uit te brengen, zoals staging of productie. In GitLab komt dit overeen met de start van een `deploy`-job in een CI/CD-pipeline. | ||
|
Waarom dit belangrijk is
Door de start van de implementatie bij te houden, kun je de duur van deze fase afzonderlijk meten. Dat is belangrijk om de doorlooptijd tot implementatie te meten en te verbeteren.
Waar vind je dit?
Dit wordt vastgelegd met de timestamp
Vastleggen
Gebruik de timestamp
Gebeurtenistype
explicit
|
|||
|
Issue gesloten
|
Dit is de definitieve administratieve afsluiting van het werkitem, meestal nadat de wijzigingen zijn geïmplementeerd en gecontroleerd. GitLab legt deze gebeurtenis expliciet vast wanneer een gebruiker het issue sluit. | ||
|
Waarom dit belangrijk is
Het sluiten van een issue markeert vaak het einde van al het bijbehorende werk. Door dit tijdstip met de implementatietijd te vergelijken, kun je vertragingen bij controles na implementatie of administratieve taken opsporen.
Waar vind je dit?
Dit is een expliciete gebeurtenis, vastgelegd met de timestamp
Vastleggen
Gebruik de timestamp
Gebeurtenistype
explicit
|
|||
|
Issue toegewezen
|
Dit geeft aan dat een issue aan een specifieke ontwikkelaar of een team is toegewezen en dat er een eigenaar voor het werk is aangewezen. GitLab registreert deze gebeurtenis expliciet wanneer het veld voor toegewezen personen van een issue wordt ingevuld of gewijzigd. | ||
|
Waarom dit belangrijk is
Het bijhouden van toewijzingen is belangrijk om de verdeling van werk, de teamwerklast en overdrachtstijden te analyseren. Zo zie je hoeveel tijd er zit tussen het aanmaken van werk en het moment waarop iemand ermee aan de slag gaat.
Waar vind je dit?
Dit wordt vastgelegd in de systeemnotities van het issue. Daarin staat wanneer een
Vastleggen
Haal gebeurtenissen met de wijziging
Gebeurtenistype
explicit
|
|||
|
Ontwikkeling gestart
|
Deze activiteit markeert het begin van het actieve programmeerwerk aan het issue. Meestal wordt dit afgeleid van de eerste codecommit naar een branch die aan het issue is gekoppeld. GitLab heeft namelijk geen expliciete knop om de ontwikkeling te starten. | ||
|
Waarom dit belangrijk is
Hiermee bepaal je precies wanneer het ontwikkelwerk dat waarde toevoegt begint. Zo kun je de programmeerfase nauwkeurig meten en onderscheiden van planning en wachttijd.
Waar vind je dit?
Dit wordt afgeleid door de timestamp van de eerste commit op een featurebranch te vinden die aan het issue is gekoppeld. Daarvoor moeten issues aan branches worden gekoppeld, vaak met naamgevingsconventies of metadata.
Vastleggen
Zoek de timestamp van de eerste commit op een branch die aan het issue-ID is gekoppeld.
Gebeurtenistype
inferred
|
|||
|
Pipeline gestart
|
Dit markeert de start van een geautomatiseerde CI/CD-pipeline, die meestal builds, tests en beveiligingsscans uitvoert. GitLab maakt expliciet een pipelinerecord met een starttijd aan wanneer een pipeline wordt gestart, bijvoorbeeld na een commit of het aanmaken van een MR. | ||
|
Waarom dit belangrijk is
Het bijhouden van pipeline-uitvoeringen is belangrijk om de werking en efficiëntie van geautomatiseerde tests en integratieprocessen te volgen. Zo zie je hoeveel tijd aan geautomatiseerde controles wordt besteed.
Waar vind je dit?
Dit wordt vastgelegd met de timestamp
Vastleggen
Gebruik de timestamp uit het record van de pipeline-uitvoering die bij de branch van de MR hoort.
Gebeurtenistype
explicit
|
|||
|
Pipeline mislukt
|
Deze activiteit vindt plaats wanneer een CI/CD-pipeline in een fase mislukt, bijvoorbeeld door een buildfout of een mislukte test. GitLab registreert expliciet de eindstatus van elke pipeline, zodat mislukte uitvoeringen eenvoudig te vinden zijn. | ||
|
Waarom dit belangrijk is
Mislukte pipelines leiden vaak tot herstelwerk. Door de frequentie, duur en oorzaken ervan te analyseren, kun je kwaliteitsproblemen, onbetrouwbare tests en bottlenecks in de feedbackloop naar ontwikkelaars opsporen.
Waar vind je dit?
Dit is te herkennen aan de status
Vastleggen
Filter op pipelinerecords met de status
Gebeurtenistype
explicit
|
|||
Extractiegidsen
Klaar om te beginnen?
Gebruik deze template om je data voor te bereiden en de softwareontwikkelingscyclus te optimaliseren. Begin vandaag met verbeteren.
Verbeter de softwareontwikkelingscyclus: ga nu aan de slag met optimaliseren
Verwijder bottlenecks in de softwareontwikkelingscyclus, verkort de doorlooptijd met 30% en verbeter de kwaliteit.
Geen creditcard nodig. Je kunt meteen beginnen met optimaliseren.