Uw Software Development Lifecycle Data Template

GitHub
Uw Software Development Lifecycle Data Template

Uw Software Development Lifecycle Data Template

Deze template biedt een uitgebreide gids voor het verzamelen en voorbereiden van uw Software Development Lifecycle data van GitHub. U vindt aanbevolen attributes om op te nemen, essentiële activities om te volgen en praktische begeleiding voor data extraction. Gebruik deze resource om een accurate event log te bouwen voor effectieve process analysis en optimization.
  • 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 attributes

Dit zijn de aanbevolen data fields om op te nemen in uw event log voor uitgebreide Software Development Lifecycle analyse en process discovery.
3 Verplicht 5 Aanbevolen 16 Optioneel
Naam Omschrijving
Activiteit
ActivityName
De naam van een specifieke event of task die plaatsvond binnen de software development lifecycle.
Omschrijving

De Activity Name beschrijft een enkele stap in het development proces, zoals 'Issue Created', 'Code Pushed to PR', 'Pull Request Approved', of 'Deployment Succeeded'. Deze events vormen de sequentie van stappen die het end-to-end proces voor een development item vormen.\n\nDit attribute is fundamenteel voor process mining, omdat het wordt gebruikt om de process map te construeren. Het analyseren van de sequentie, frequentie en duur van deze activities onthult de werkelijke proces flow, identificeert common paths, belicht deviations en wijst bottlenecks aan.

Het belang

Dit attribute vormt de ruggengraat van de process map, waardoor de visualisatie en analyse van de sequentie van events in de development lifecycle mogelijk is.

Vindplaats

Afgeleid van het 'action' veld van webhook event payloads (bijv. 'opened', 'closed' voor een issue) of van het event type zelf (bijv. 'PushEvent', 'PullRequestReviewEvent').

Voorbeelden
Issue AangemaaktPull Request GeopendCode Gepusht naar PRReview AangevraagdPull Request Gemerged
Development Item
DevelopmentItemId
De unique identifier voor een enkele unit van development werk, zoals een feature, bug fix of task. Dit dient als de primaire case identifier.
Omschrijving

De Development Item ID volgt een work item van de creatie tot de uiteindelijke deployment. Het koppelt alle geassocieerde activities, zoals branch creation, commits, pull requests, reviews en deployments, in één enkele, coherente process instance.\n\nIn analyse wordt deze ID gebruikt om de end-to-end cycle time van een development task te berekenen. Het maakt de reconstructie mogelijk van de gehele journey van een feature of bug fix, waardoor gedetailleerde analyse van bottlenecks, rework loops en procesvariaties voor individuele work items mogelijk is.

Het belang

Het is de essentiële sleutel voor process mining, die alle gerelateerde ontwikkelings-events in één enkele case verbindt om de end-to-end softwareontwikkelings-lifecycle nauwkeurig te visualiseren en te analyseren.

Vindplaats

Dit is doorgaans het Issue Number of Pull Request Number van GitHub. Het kan worden geëxtraheerd uit het 'number' veld in de payload van issue- of pull request-gerelateerde webhook events of API responses.

Voorbeelden
101PR-2345TASK-812
Starttijd
EventTimestamp
De exacte datum en tijd waarop een specifieke development activity of event plaatsvond.
Omschrijving

Deze timestamp markeert het begin van een activity. Het is cruciaal voor het chronologisch ordenen van events om de process flow voor elk development item te reconstrueren. De sequentie en het tijdsverschil tussen deze timestamps worden gebruikt om procesperformance te analyseren.\n\nIn analyse is dit attribute essentieel voor het berekenen van alle tijdgebaseerde metrics, inclusief cycle times, processing times en waiting times. Het maakt de identificatie van vertragingen tussen stappen mogelijk en levert de data die nodig is voor bottleneck analysis en performance monitoring dashboards.

Het belang

Deze timestamp is cruciaal voor het correct ordenen van events en het berekenen van alle performance metrics, zoals cycle times en bottleneck durations.

Vindplaats

Doorgaans te vinden als 'created_at' of 'updated_at' fields in de JSON payloads van GitHub APIs en webhooks voor verschillende objects zoals issues, pull requests en commits.

Voorbeelden
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Eindtijd
EndTimestamp
De exacte datum en tijd waarop een specifieke development activity of event werd voltooid.
Omschrijving

De end timestamp markeert de voltooiing van een activity. Hoewel veel events in GitHub direct zijn (bijv. 'Issue Created'), hebben sommige activities een meetbare duur (bijv. een CI check die draait). Het verschil tussen de End Time en Start Time levert de processing time voor een activity op.\n\nDit attribute wordt gebruikt om de 'ProcessingTime' metric te berekenen, wat essentieel is voor het begrijpen hoeveel actieve inspanning wordt besteed aan verschillende tasks zoals code reviews of automated checks. Het analyseren van processing times helpt inefficiënte activities te identificeren die te veel tijd in beslag nemen.

Het belang

Maakt de berekening van nauwkeurige verwerkingstijden voor activiteiten mogelijk, wat helpt onderscheid te maken tussen actieve werktijd en inactieve wachttijd.

Vindplaats

Kan worden gevonden als 'completed_at' in check run objecten of afgeleid van de timestamp van een volgende, logisch afsluitende event.

Voorbeelden
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Prioriteit
Priority
Het prioriteitsniveau toegewezen aan een development item, zoals 'High', 'Medium' of 'Low'.
Omschrijving

Prioriteit geeft de urgentie of het zakelijk belang van een work item aan. In GitHub is prioriteit geen native veld en wordt het doorgaans beheerd met behulp van labels (bijv. 'P1-High', 'P2-Medium'). Een consistent labelingschema is vereist om deze informatie betrouwbaar te extraheren.\n\nDit attribute is essentieel voor 'Priority-Based Flow Analysis'. Het stelt analisten in staat om te verifiëren of high-priority items daadwerkelijk sneller worden verwerkt dan low-priority items en om de cycle time variance te meten op basis van prioriteit. Het helpt bij het evalueren van de effectiviteit van het prioriteringsproces.

Het belang

Maakt analyse mogelijk of high-priority items sneller worden verwerkt dan items met lagere prioriteit, wat de effectiviteit van de prioriteringsstrategie valideert.

Vindplaats

Afgeleid van GitHub labels die zijn toegepast op issues of pull requests. Het vereist een gestandaardiseerde conventie voor prioriteitslabels.

Voorbeelden
HoogGemiddeldLaagKritiek
Repository
RepositoryName
De naam van de code repository waar de development activity plaatsvindt.
Omschrijving

De repository fungeert als een project- of productidentifier, met daarin alle code, issues en pull requests voor een specifieke applicatie of component. Het biedt een manier om development processen te segmenteren en te vergelijken tussen verschillende producten of teams.\n\nIn analyse maakt dit attribute filtering en vergelijking van procesperformance over verschillende projecten mogelijk. Het helpt vragen te beantwoorden zoals 'Welk project heeft de langste cycle time?' of 'Hoe verhoudt het bug fix proces in Project A zich tot Project B?'. Het is essentieel voor het 'Throughput by Project and Type' dashboard.

Het belang

Maakt de segmentatie en vergelijking van ontwikkelingsprocessen over verschillende projecten, producten of teams mogelijk, wat een gerichtere analyse faciliteert.

Vindplaats

Beschikbaar in het 'repository' object in bijna alle GitHub webhook- en API-payloads. Het specifieke veld is meestal 'repository.full_name' of 'repository.name'.

Voorbeelden
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Toegewezen Gebruiker
Assignee
De gebruiker of developer die is toegewezen aan het development item of een specifieke task, zoals een pull request review.
Omschrijving

Dit attribute identificeert de persoon die verantwoordelijk is voor het werk in een gegeven stage. Dit kan de assignee van een issue zijn, de author van een pull request, of de reviewer die is aangevraagd voor een code review. Het volgen van de assignee is essentieel voor het begrijpen van resource allocation en workload.\n\nDit attribute wordt gebruikt in analyse om de developer workload te monitoren, resource bottlenecks te identificeren en handoff efficiëntie tussen verschillende teamleden te analyseren. Dashboards kunnen worden gefilterd op assignee om individuele of team performance te beoordelen en een gebalanceerde distributie van werk te garanderen.

Het belang

Cruciaal voor het analyseren van de ontwikkelaarswerklast, teamprestaties en de efficiëntie van handoffs tussen verschillende teamleden.

Vindplaats

Beschikbaar in het 'assignee' of 'user' object binnen de JSON payloads voor issues, pull requests en review events van de GitHub API.

Voorbeelden
john.doejane.smithdev-team-lead
Type Development Item
DevelopmentItemType
De classificatie van het development work item, zoals een feature, bug, task of epic.
Omschrijving

Dit attribute categoriseert de aard van het uitgevoerde werk. Deze informatie wordt doorgaans beheerd via labels of specifieke issue templates binnen GitHub. Het begrijpen van het type werk is cruciaal voor het stellen van passende performance expectations, aangezien een bug fix een veel kortere verwachte cycle time kan hebben dan een nieuwe feature.\n\nDit attribute maakt comparative analysis tussen verschillende work types mogelijk. Het helpt te analyseren of bug fixes sneller worden verwerkt dan nieuwe features, of om de resource allocation voor technical debt versus new development te begrijpen. Het is een belangrijke dimensie in het 'Throughput by Project and Type' dashboard.

Het belang

Categoriseert werkitems, maakt prestatievergelijkingen en analyse mogelijk van hoe verschillende soorten werk (bijv. bugs versus features) door het proces stromen.

Vindplaats

Doorgaans afgeleid van GitHub labels die zijn toegepast op issues of pull requests. Vereist een consistente labeling convention (bijv. 'type:bug', 'type:feature').

Voorbeelden
BugFeatureTaskTechnical Debt
Auteur
Author
De gebruiker die de issue, pull request of commit heeft aangemaakt.
Omschrijving

De author is de initiator van een specifiek artifact in het development proces. Bijvoorbeeld, de author van een issue is de persoon die de bug rapporteerde of de feature aanvroeg. De author van een pull request is de developer die de code schreef.\n\nIn analyse kan de author worden gebruikt om de bronnen van werk te begrijpen. Bijvoorbeeld, het analyseren van de authors van bug reports kan patronen onthullen die verband houden met specifieke teams of features. Het kan ook worden gebruikt in combinatie met de assignee om handoff patronen te analyseren.

Het belang

Identificeert de initiator van een werkitem of codewijziging, wat nuttig kan zijn voor het analyseren van de bronnen van herwerk, bugrapporten of feature requests.

Vindplaats

Beschikbaar in het 'user' object binnen het hoofdobject van API-responses voor issues, pull requests en commits. Het veld is typisch 'user.login'.

Voorbeelden
sara.jonesmike.leeautomation-bot
Beoordelaar
Reviewer
De gebruiker die is gevraagd om een code review uit te voeren op een pull request.
Omschrijving

Een reviewer is een ontwikkelaar of teamlid dat is toegewezen om codewijzigingen in een pull request te inspecteren op kwaliteit, correctheid en naleving van standaarden. Een pull request kan meerdere reviewers hebben.

Dit attribuut is essentieel voor het analyseren van het code review proces. Het helpt bij het identificeren van bottlenecks gerelateerd aan specifieke reviewers, het begrijpen van de verdeling van review-werklast, en het meten van de tijd die reviewers nodig hebben om te reageren op verzoeken. Het is een belangrijk onderdeel voor het berekenen van de 'Average Code Review Cycle Time' KPI.

Het belang

Identificeert de personen die betrokken zijn bij het kwaliteitsborgingsproces, wat analyse mogelijk maakt van review-werklast, vertragingen en de algehele efficiëntie van code reviews.

Vindplaats

Beschikbaar in de 'requested_reviewers' array of het 'user' object van een pull request review event van de GitHub API.

Voorbeelden
alex.chenmaria.garciasenior-dev-team
Beoordelingsstatus
ReviewState
De uitkomst van een code review op een pull request, zoals 'Approved' of 'Changes Requested'.
Omschrijving

Dit attribute legt de beslissing vast die door een reviewer is genomen. Veelvoorkomende statussen zijn onder andere 'APPROVED', wat aangeeft dat de code klaar is om te mergen, en 'CHANGES_REQUESTED', wat aangeeft dat rework nodig is. Andere statussen kunnen 'COMMENTED' of 'PENDING' zijn.\n\nDit is een kritiek attribute voor het analyseren van rework en quality. Een hoge frequentie van 'CHANGES_REQUESTED' events kan duiden op issues met de initiële code quality of onduidelijke requirements. Het ondersteunt direct het 'Rework and Regression Loops' dashboard door te identificeren wanneer een development item wordt teruggestuurd voor modificatie.

Het belang

Geeft direct herwerk-loops en kwaliteitspoorten binnen het code review proces aan, wat helpt bij het opsporen van bronnen van inefficiëntie en kwaliteitsproblemen.

Vindplaats

Beschikbaar als het 'state' veld binnen een pull request review object van de GitHub API. Bijvoorbeeld, in een 'PullRequestReviewEvent' payload.

Voorbeelden
APPROVEDCHANGES_REQUESTEDCOMMENTED
Bewerkingstijd
ProcessingTime
De berekende duur van een activity, die de actieve werktijd vertegenwoordigt.
Omschrijving

Processing Time is de verstreken tijd tussen het begin en einde van een activity. Het wordt berekend als 'EndTimestamp' min 'EventTimestamp'. Deze metric meet hoe lang het duurt om een task te voltooien, exclusief de tijd die is besteed aan het wachten tot de task begint.\n\nHet analyseren van processing time helpt om te identificeren welke activities het meest tijdrovend zijn qua actieve inspanning. Dit verschilt van cycle time, die wachttijd omvat. Een code review kan bijvoorbeeld een lange cycle time hebben, maar een korte processing time, wat aangeeft dat de reviewer bezig is en de PR in een queue wacht.

Het belang

Meet de actieve werkduur, helpt onderscheid te maken tussen de tijd besteed aan een task en de tijd besteed aan het wachten erop, wat cruciaal is voor gerichte efficiëntieverbeteringen.

Vindplaats

Berekend door de 'EventTimestamp' af te trekken van de 'EndTimestamp' voor één activiteitsrecord.

Voorbeelden
PT5M15SPT2H30MP1DT12H
Branch Naam
BranchName
De naam van de Git branch waar de code changes voor het development item werden gemaakt.
Omschrijving

Een branch is een onafhankelijke ontwikkelingslijn, gecreëerd om aan een nieuwe feature of bug fix te werken zonder de hoofdcodebasis te beïnvloeden. De branchename bevat vaak nuttige informatie, zoals het issue nummer of een korte beschrijving van het werk.

Het analyseren van branchenames kan helpen bij het begrijpen van branching-strategieën en het naleven van ontwikkelconventies. Het helpt ook bij het koppelen van specifieke code commits aan een development item, wat een compleet beeld geeft van de codeeractiviteit.

Het belang

Biedt context over de specifieke development lijn en helpt bij het afdwingen en analyseren van branching strategies en naming conventions.

Vindplaats

Beschikbaar in het 'ref' veld voor push events, of in de 'head' en 'base' objecten binnen een pull request API-response.

Voorbeelden
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Bronsysteem
SourceSystem
Het systeem waaruit de development process data is geëxtraheerd.
Omschrijving

Dit attribute identificeert de oorsprong van de event data. Voor dit proces zou de waarde consistent 'GitHub' zijn. In een complexere environment waar development activities meerdere systemen omvatten (bijv. Jira voor planning, GitHub voor code, Jenkins voor deployment), wordt dit veld gebruikt om de bron van elke event te onderscheiden.\n\nIn analyse helpt het bij het traceren van data terug naar de oorsprong voor validatie en troubleshooting. Het maakt ook het analyseren van processen mogelijk die verschillende platforms overspannen, wat een duidelijke context biedt voor elke activity.

Het belang

Identificeert de oorsprong van de data, wat essentieel is voor data validatie en voor het analyseren van processen die meerdere geïntegreerde systemen kunnen omvatten.

Vindplaats

Dit is doorgaans een static value die wordt toegevoegd tijdens het data extraction, transformation, and loading (ETL) proces om de bron van de records te labelen.

Voorbeelden
GitHubGitHub Enterprise
CI Check Status
CiCheckStatus
De status van een geautomatiseerde Continuous Integration (CI) check, zoals 'passed' of 'failed'.
Omschrijving

Dit attribute reflecteert de uitkomst van automated builds, tests en scans die worden uitgevoerd op code changes in een pull request. CI checks zijn een kritieke quality gate in moderne development workflows.\n\nHet analyseren van dit attribute helpt om de effectiviteit van geautomatiseerd testen te begrijpen. Een hoge failure rate kan duiden op problemen met code stability, de testing suite of de development environment. Het ondersteunt de 'CI Checks Passed' en 'CI Checks Failed' activities en helpt bij het analyseren van vertragingen veroorzaakt door broken builds.

Het belang

Geeft het succes of falen aan van geautomatiseerde kwaliteitspoorten, en biedt inzicht in codekwaliteit en de effectiviteit van de CI pipeline.

Vindplaats

Verkregen uit het 'state' of 'conclusion' veld van check run of status objects via de GitHub Checks of Statuses API.

Voorbeelden
successfailurependingerror
Commit Hash
CommitHash
De unique identifier (SHA) voor een specifieke code commit.
Omschrijving

Een commit hash is een 40-karakter SHA-1 hash die een commit in Git uniek identificeert. Het fungeert als een permanente ID voor een specifieke versie van de code. Commits zijn de atomaire eenheden van verandering in het ontwikkelproces.

Hoewel zeer gedetailleerd, biedt de commit hash het ultieme niveau van traceerbaarheid. Het stelt analisten in staat om een proces-event direct te koppelen aan de exacte codewijziging die is aangebracht. Dit kan van onschatbare waarde zijn voor auditing, compliance, of gedetailleerde oorzaakanalyse van productie-incidenten.

Het belang

Biedt de meest granulaire link tussen een processtap en de exacte code change, wat volledige traceability voor audits en debugging mogelijk maakt.

Vindplaats

Beschikbaar in push event payloads ('head_commit.id') of via de Commits API voor een pull request of branch.

Voorbeelden
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Deployment Environment
DeploymentEnvironment
De target environment voor een deployment, zoals 'Staging' of 'Production'.
Omschrijving

Dit attribute specificeert waar de code wordt gedeployed. Het volgen van deployments naar verschillende environments is essentieel voor het begrijpen van de volledige lifecycle, van development tot production release.\n\nDit attribute maakt analyse van het deployment sub-process mogelijk. Het kan worden gebruikt om de tijd te meten die nodig is om code van staging naar production te promoten en om de success rate van deployments naar verschillende environments te volgen. Het is essentieel voor het weten wanneer een development item echt 'done' is en is geleverd aan gebruikers.

Het belang

Maakt onderscheid tussen pre-productie en productiereleases, wat cruciaal is voor het meten van de werkelijke 'time-to-market' en het analyseren van deployment patronen.

Vindplaats

Deze informatie wordt opgehaald via de GitHub Deployments API, die vaak wordt getriggerd door CI/CD pipelines of andere automation.

Voorbeelden
developmentstagingproduction
Handoff Wachttijd
HandoffWaitingTime
De berekende wachttijd die een development item doorbrengt tussen activities uitgevoerd door verschillende personen.
Omschrijving

Deze metric meet de tijd tussen de voltooiing van de ene activity en de start van de volgende, maar alleen wanneer de verantwoordelijke persoon verandert. Bijvoorbeeld, de tijd tussen een 'Review Requested' event en een 'Changes Requested in Review' event door een andere gebruiker.\n\nDit is een kritieke metric voor het identificeren van communicatiekloven en coördinatieproblemen. Het ondersteunt het 'Critical Handoff Efficiency' dashboard en de 'Average Handoff Waiting Time' KPI. Hoge wachttijden bij handoff punten zijn vaak een teken van resource constraints of inefficiënte notification processes.

Het belang

Lokaliseert vertragingen veroorzaakt door slechte coördinatie of onbeschikbaarheid van resources tijdens handoffs tussen verschillende teams of rollen, die vaak belangrijke bronnen van inefficiëntie zijn.

Vindplaats

Berekend door sequentiële activiteiten te identificeren waarbij het attribuut 'Assignee' of 'User' verandert, en vervolgens de tijdsspanne daartussen te meten.

Voorbeelden
PT1H15MP2DT4HPT25M
Is herstelwerk
IsRework
Een booleaanse vlag die aangeeft dat een activiteit een regressie naar een vorige procesfase betreft.
Omschrijving

Deze flag wordt op true gezet wanneer een development item achteruitgaat in het proces, bijvoorbeeld wanneer een pull request een 'Changes Requested' review ontvangt, of wanneer een issue wordt heropend nadat deze is gesloten. Het wordt afgeleid door de sequentie van activities te analyseren.\n\nDit attribute is essentieel voor het kwantificeren van verspilling en inefficiëntie. Het ondersteunt direct het 'Rework and Regression Loops' dashboard en de 'Rework Rate' KPI. Door te filteren op 'IsRework = true', kunnen analisten de oorzaken van rework isoleren en onderzoeken.

Het belang

Vlagt expliciet activiteiten die herwerk vormen, waardoor het eenvoudig wordt om de oorzaken van procesinefficiënties te kwantificeren, visualiseren en analyseren.

Vindplaats

Dit is een derived attribute. De logica omvat het definiëren van een standaard process flow en vervolgens het markeren van elke activity die afwijkt door terug te keren naar een eerdere logische stage.

Voorbeelden
truefalse
Item Status
State
De huidige status van een issue of pull request, zoals 'open', 'closed' of 'merged'.
Omschrijving

Dit attribute geeft de high-level status van een development item aan. Voor issues zijn de typische statussen 'open' en 'closed'. Voor pull requests omvatten statussen 'open', 'closed' en 'merged'. Dit geeft een snapshot van de voortgang van het item.\n\nIn analyse wordt de state gebruikt om actief versus voltooid werk te identificeren. Het is essentieel voor dashboards zoals 'Active Development Progress' die doorlopend werk monitoren. Het wordt ook gebruikt om het einde van een proces te definiëren, bijvoorbeeld een state van 'merged' of 'closed' kan de voltooiing van een case betekenen.

Het belang

Geeft een duidelijke indicatie of een work item momenteel in uitvoering of voltooid is, wat fundamenteel is voor lifecycle analyse en het monitoren van actief werk.

Vindplaats

Direct beschikbaar als het 'state' veld in de JSON payloads voor issues en pull requests van de GitHub API.

Voorbeelden
openclosedmerged
Laatste data-update
LastDataUpdate
De tijdstempel die aangeeft wanneer de gegevens voor dit record het laatst zijn ververst vanuit het bronsysteem.
Omschrijving

Dit attribute registreert de datum en tijd van de meest recente data extractie of update. Het biedt metadata over de versheid van de geanalyseerde data. Dit is onderscheidend van de event timestamp, die vastlegt wanneer de business event plaatsvond.\n\nIn analyse is dit veld cruciaal voor het begrijpen van de actualiteit van de procesweergave. Het helpt gebruikers te weten of ze naar real-time data kijken of een snapshot van een specifiek tijdstip, wat belangrijk is voor operational dashboards en monitoring.

Het belang

Geeft de actualiteit van de data aan, wat cruciaal is om ervoor te zorgen dat analyses en dashboards gebaseerd zijn op actuele informatie.

Vindplaats

Deze timestamp wordt gegenereerd en toegevoegd tijdens het ETL-proces (Extractie, Transformatie en Loading van data).

Voorbeelden
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Labels
Labels
Een lijst met tags of labels die zijn toegepast op een issue of pull request voor categorisatie.
Omschrijving

Labels in GitHub zijn een flexibele manier om metadata toe te voegen aan issues en pull requests. Ze kunnen worden gebruikt om prioriteit, werktype, componenten, teams of status aan te duiden. De onbewerkte lijst met labels biedt een rijke, ongestructureerde context.

Hoewel specifieke attributen zoals Priority en Type zijn afgeleid van labels, kan het behouden van de volledige lijst nuttig zijn voor ad-hoc analyse en het ontdekken van andere procespatronen. Het maakt flexibele filtering en segmentatie van cases mogelijk op basis van elke combinatie van labels.

Het belang

Biedt een flexibele, rijke bron van metadata voor het categoriseren van work items, wat diepe en gevarieerde dimensional analysis mogelijk maakt.

Vindplaats

Beschikbaar als de 'labels' array in de JSON payload voor issues en pull requests van de GitHub API. Elk item in de array is een object met een 'name' veld.

Voorbeelden
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Ontwikkelingsdoorlooptijd
DevelopmentCycleTime
De totale verstreken tijd vanaf de creatie van een development item tot de uiteindelijke deployment of sluiting.
Omschrijving

Dit is een case-level metric, berekend als het tijdsverschil tussen de allereerste event (bijv. 'Issue Created') en de finale event (bijv. 'Deployment Succeeded' of 'Issue Closed') voor een enkel development item.\n\nDit is een van de belangrijkste KPIs voor het meten van de algehele efficiëntie van het development proces. Het ondersteunt direct het 'Overall Development Cycle Time' dashboard en de 'Average Development Cycle Time' KPI. Het verminderen van deze metric is vaak een primair doel van process improvement initiatieven.

Het belang

Vertegenwoordigt de end-to-end 'time-to-market' voor een development item, waardoor het een kritieke KPI is voor het meten van de algehele procesnelheid en efficiëntie.

Vindplaats

Berekend op casusniveau door de timestamp van de eerste activiteit af te trekken van de timestamp van de laatste activiteit.

Voorbeelden
P5DT6H30MP14DT12HP1DT2H
Pull Request Number
PullRequestNumber
De unique identifier voor een pull request geassocieerd met het development item.
Omschrijving

Een pull request (PR) is een voorstel om een reeks codewijzigingen samen te voegen tot een specifieke branch. Het Pull Request Nummer koppelt ontwikkelactiviteiten, zoals code pushes en reviews, terug aan het primaire development item of issue.

Deze ID is cruciaal voor het volgen van de code-integratie en het review-subproces binnen de bredere ontwikkelingslifecycle. Het maakt gedetailleerde analyse van het code review proces mogelijk, inclusief reviewtijden, herwerk-cycli geïdentificeerd tijdens de review, en merge-percentages. Het verbindt de planningsfase (issue) met de implementatiefase (PR).

Het belang

Koppelt issues aan de specifieke codewijzigingen en reviewprocessen, wat een gedetailleerde analyse van de code review cyclus en de impact ervan op de totale levertijd mogelijk maakt.

Vindplaats

Beschikbaar als het 'number' veld binnen het 'pull_request' object in veel GitHub API-responses, of als de hoofd-identifier van de Pull Requests API.

Voorbeelden
12345678910
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.
6 Aanbevolen 7 Optioneel
Activiteit Omschrijving
CI Checks Geslaagd
Vertegenwoordigt de succesvolle voltooiing van geautomatiseerde checks, zoals builds, unit tests of static analysis, uitgevoerd op de code in een pull request. Deze event wordt afgeleid uit de status van checks gerapporteerd door systemen zoals GitHub Actions.
Het belang

Deze automated quality gate is cruciaal voor het garanderen van code stability. Failures of lange run times kunnen aanzienlijke bottlenecks zijn in de delivery pipeline.

Vindplaats

Afgeleid van de GitHub Checks API of Statuses API. Een check run of status update rapporteert een 'success' of 'completed' met een 'success' conclusie.

Vastleggen

Monitor de Checks API op een 'success' conclusie van de relevante check suites.

Gebeurtenistype inferred
Issue Aangemaakt
Markeert het begin van de lifecycle van een development item, wat staat voor de formele creatie van een task, bug of feature request. Deze event wordt expliciet vastgelegd wanneer een gebruiker een nieuwe issue aanmaakt in een GitHub repository.
Het belang

Dit is de primaire start activity voor het proces, essentieel voor het meten van de totale development cycle time en het begrijpen van de initiële bronnen van werk.

Vindplaats

Dit is een expliciete event vastgelegd vanuit de GitHub Issues API event stream. De event type is doorgaans 'opened' voor een gegeven issue nummer.

Vastleggen

Luister naar de 'opened' event op een issue via webhooks of API polling.

Gebeurtenistype explicit
Probleem afgesloten
Het development item wordt als voltooid beschouwd en de corresponderende issue wordt formeel gesloten. Dit kan automatisch gebeuren wanneer een gelinkte pull request wordt gemerged of handmatig worden uitgevoerd door een teamlid.
Het belang

Deze activity dient als het definitieve einde van het proces voor een development item. Het is cruciaal voor het berekenen van end-to-end cycle times.

Vindplaats

Dit is een expliciete event vastgelegd vanuit de GitHub Issues API event stream. De event type is 'closed'.

Vastleggen

Luister naar de 'closed' event op een issue via webhooks of API polling.

Gebeurtenistype explicit
Pull Request Gemerged
De goedgekeurde code changes van de pull request worden officieel geïntegreerd in de target branch, zoals main of develop. Dit is een expliciete, finale actie op een pull request die de nieuwe code incorporeert.
Het belang

Dit is een kritieke milestone die de voltooiing van development en review vertegenwoordigt. Voor veel teams is dit de laatste stap voor automated deployment.

Vindplaats

Vastgelegd vanuit de GitHub Pull Request API event stream of webhooks. De event action is 'closed' en het 'merged' attribuut van de pull request payload is 'true'.

Vastleggen

Luister naar de 'closed' actie op een pull request en controleer of de 'merged' flag true is.

Gebeurtenistype explicit
Pull Request Geopend
Geeft aan dat een eerste blok code klaar is voor review en integratie. Een developer creëert een pull request (PR) om wijzigingen voor te stellen van hun feature branch naar een main branch. Dit is een expliciete event in GitHub.
Het belang

Dit is een kritieke milestone die het einde van de initiële development fase en het begin van de review- en integration pipeline markeert. Het is essentieel voor het afzonderlijk analyseren van development en review cycle times.

Vindplaats

Vastgelegd vanuit de GitHub Pull Request API event stream of webhooks. De event action is 'opened'.

Vastleggen

Luister naar de 'opened' actie voor een pull request via webhooks of API polling.

Gebeurtenistype explicit
Pull Request Goedgekeurd
Een reviewer heeft de wijzigingen in een pull request formeel goedgekeurd, wat aangeeft dat deze voldoen aan kwaliteits- en functionele standaarden. Dit wordt vastgelegd wanneer een reviewer zijn review indient met een 'approve' status.
Het belang

Dit is een belangrijke quality gate en een belangrijke milestone vóór merging. De tijd die nodig is om deze state te bereiken vanaf PR creation is een kritieke KPI voor review process efficiency.

Vindplaats

Vastgelegd vanuit de GitHub Pull Request API of webhooks wanneer een review wordt ingediend met de status 'APPROVED'.

Vastleggen

Filter pull request review indienings-events voor de status 'APPROVED'.

Gebeurtenistype explicit
Branch Gecreëerd
Vertegenwoordigt de start van actief development werk voor een issue, waarbij een developer een nieuwe branch aanmaakt vanuit de main codebase. Dit is een expliciete event die wordt vastgelegd wanneer een nieuwe branch naar de repository wordt gepusht, vaak met het issue nummer in de naam.
Het belang

Geeft de overgang aan van planning naar actief coderen. Het meten van de tijd tussen het aanmaken van een issue en deze event helpt bij het analyseren van de 'developer pickup time' en initiële backlog-vertragingen.

Vindplaats

Vastgelegd via de GitHub Git API of webhooks die luisteren naar 'create' events van het type 'branch'. Het is vaak nodig om de branchename te koppelen aan een issue via naamgevingsconventies, zoals 'feature/issue-123'.

Vastleggen

Parseer 'create' webhook events voor nieuwe branches en koppel deze aan een issue.

Gebeurtenistype explicit
CI Checks Mislukt
Vertegenwoordigt het falen van een geautomatiseerde check, zoals een build error of mislukte unit test, uitgevoerd op de code in een pull request. Dit wordt afgeleid uit een failure status gerapporteerd door een systeem zoals GitHub Actions.
Het belang

Deze activity belicht technische quality issues die developer interventie vereisen, waardoor een rework loop ontstaat. Het analyseren van de failure frequency kan verbeteringen in local testing of code quality sturen.

Vindplaats

Afgeleid van de GitHub Checks API of Statuses API. Een check run of status update rapporteert een 'failure' of 'completed' met een 'failure' conclusie.

Vastleggen

Monitor de Checks API op een 'failure' conclusie van de relevante check suites.

Gebeurtenistype inferred
Code Gepusht naar PR
Vertegenwoordigt een update van de code die ter review is ingediend, hetzij als onderdeel van de initiële PR of als reactie op review feedback. Deze event wordt vastgelegd telkens wanneer een nieuwe commit wordt gepusht naar de branch die geassocieerd is met een open pull request.
Het belang

Het volgen van deze events is cruciaal voor het identificeren van rework loops. Meerdere pushes na een review geven aan dat er wijzigingen nodig waren, wat de algehele cycle time beïnvloedt.

Vindplaats

Dit is een expliciete event in de pull request timeline, vaak gelabeld als een commit die wordt toegevoegd. Het kan worden vastgelegd vanuit de 'push' webhook of door de commits te monitoren die zijn geassocieerd met een PR.

Vastleggen

Volg 'push' events op een branch die is geassocieerd met een open pull request.

Gebeurtenistype explicit
Deployment Geslaagd
De code changes zijn succesvol gedeployed naar een specifieke environment, zoals staging of production. Deze event wordt doorgaans vastgelegd via de GitHub Deployments API, vaak getriggerd door een GitHub Action na een merge.
Het belang

Markeert de overgang van code van de repository naar een live omgeving. Het volgen hiervan is essentieel voor het meten van de totale lead time van idee tot productie.

Vindplaats

Vastgelegd via de Deployments API. Een externe service of GitHub Action creëert een deployment en update vervolgens de status naar 'success'.

Vastleggen

Monitor deployment status events via webhooks voor een status van 'success'.

Gebeurtenistype inferred
Issue Heropend
Een eerder gesloten issue wordt opnieuw geactiveerd, meestal omdat de oplossing onvoldoende was of er een regressie werd gevonden. Dit is een expliciete event die de lifecycle voor het development item opnieuw start.
Het belang

Dit signaleert een significante rework loop, wat duidt op een potentiële 'production defect escape' of onvolledige fix. Het volgen van de frequentie ervan is een belangrijke maatstaf voor de algehele software quality.

Vindplaats

Dit is een expliciete event vastgelegd vanuit de GitHub Issues API event stream. De event type is 'reopened'.

Vastleggen

Luister naar de 'reopened' event op een issue via webhooks of API polling.

Gebeurtenistype explicit
Review Aangevraagd
De author van een pull request vraagt formeel specifieke teamleden of teams om hun code te reviewen. Dit is een expliciete actie binnen de GitHub UI of API die notifications triggert naar de aangevraagde reviewers.
Het belang

Deze activity markeert de officiële start van de handoff naar het code review proces. De tijd tussen dit en een review submission helpt de responsiveness van de reviewer en potentiële bottlenecks te meten.

Vindplaats

Vastgelegd vanuit de GitHub Pull Request API event stream of webhooks. De event action is 'review_requested'.

Vastleggen

Luister naar de 'review_requested' actie voor een pull request.

Gebeurtenistype explicit
Wijzigingen Aangevraagd in Review
Een reviewer heeft hun code review voltooid en vastgesteld dat er aanpassingen nodig zijn voordat de pull request kan worden goedgekeurd. De reviewer dient formeel hun review in met de status 'request_changes'.
Het belang

Deze event signaleert expliciet een rework loop. Het analyseren van de frequentie helpt bij het aanwijzen van quality issues, onduidelijke requirements of gebieden voor developer training.

Vindplaats

Vastgelegd vanuit de GitHub Pull Request API of webhooks wanneer een review wordt ingediend met de status 'CHANGES_REQUESTED'.

Vastleggen

Filter pull request review indienings-events voor de status 'CHANGES_REQUESTED'.

Gebeurtenistype explicit
Aanbevolen Optioneel

Extractie Guides

Hoe u uw data van GitHub haalt