Uw Softwareontwikkelingscyclus datatemplate

GitHub
Uw Softwareontwikkelingscyclus datatemplate

Uw Softwareontwikkelingscyclus datatemplate

Deze template is een volledige gids voor het verzamelen en voorbereiden van uw Softwareontwikkelingscyclus data van GitHub. U vindt aanbevolen attributen om op te nemen, essentiële activiteiten om te volgen en praktische begeleiding voor data-extractie. Gebruik dit hulpmiddel om een accurate event log te bouwen voor effectieve procesanalyse 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.

Attributen van de Softwareontwikkelingscyclus

Dit zijn de aanbevolen velden om op te nemen in uw event log voor volledige Softwareontwikkelingscyclus analyse en process discovery.
3 Verplicht 5 Aanbevolen 15 Optioneel
Naam Omschrijving
Activiteit
ActivityName
De naam van een specifieke gebeurtenis of taak die plaatsvond binnen de softwareontwikkeling levenscyclus.
Omschrijving

De activiteitsnaam beschrijft een enkele stap in het ontwikkelproces, zoals 'Issue Created', 'Code Pushed to PR', 'Pull Request Approved', of 'Deployment Succeeded'. Deze gebeurtenissen vormen de volgorde van stappen die het end-to-end proces voor een development item vormen.\n\nDit attribuut is onmisbaar voor process mining, omdat het wordt gebruikt om de procesmap te construeren. Het analyseren van de volgorde, frequentie en duur van deze activiteiten onthult de werkelijke processtroom, identificeert common paths, belicht deviations en wijst knelpunten aan.

Het belang

Dit attribuut vormt de basis van de procesmap, waardoor de visualisatie en analyse van de volgorde van gebeurtenissen in de development levenscyclus mogelijk is.

Vindplaats

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

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

De Development Item ID volgt een work item van de creatie tot de uiteindelijke deployment. Het koppelt alle geassocieerde activiteiten, zoals branch creation, commits, pull requests, reviews en deployments, in één enkele, duidelijk beeld van het proces.\n\nIn analyse wordt deze ID gebruikt om de end-to-end doorlooptijd van een development taak te berekenen. Het maakt de reconstructie mogelijk van de gehele klantreis van een feature of bug fix, waardoor gedetailleerde analyse van knelpunten, herstelwerk-loops en procesvariaties voor individuele work items mogelijk is.

Het belang

Het is de onmisbaar voor process mining, die alle gerelateerde ontwikkelings-gebeurtenissen in één enkele case verbindt om de end-to-end softwareontwikkelings-levenscyclus nauwkeurig te visualiseren en te analyseren.

Vindplaats

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

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

Deze timestamp markeert het begin van een activity. Het is belangrijk voor het chronologisch ordenen van gebeurtenissen om de processtroom voor elk development item te reconstrueren. De volgorde en het tijdsverschil tussen deze tijdstempels worden gebruikt om procesprestaties te analyseren.\n\nIn analyse is dit attribuut belangrijk voor het berekenen van alle tijdgebonden meetwaarden, inclusief doorlooptijden, verwerkingstijds en wachttijden. Het maakt de identificatie van vertragingen tussen stappen mogelijk en levert de data die nodig is voor bottleneck analysis en prestaties monitoring dashboards.

Het belang

Deze timestamp is belangrijk voor het correct ordenen van gebeurtenissen en het berekenen van alle prestaties meetwaarden, zoals doorlooptijden en bottleneck duurs.

Vindplaats

Doorgaans te vinden als 'created_at' of 'updated_at' velden in de JSON payloads van GitHub API's 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 gebeurtenis werd voltooid.
Omschrijving

De end timestamp markeert de voltooiing van een activity. Hoewel veel gebeurtenissen in GitHub direct zijn (bijv. 'Issue Created'), hebben sommige activiteiten een meetbare duur (bijv. een CI check die draait). Het verschil tussen de End Time en Starttijd levert de verwerkingstijd voor een activity op.\n\nDit attribuut wordt gebruikt om de 'ProcessingTime' metriek te berekenen, wat belangrijk is voor het begrijpen hoeveel actieve inspanning wordt besteed aan verschillende taken zoals code reviews of automated checks. Het analyseren van verwerkingstijds helpt inefficiënte activiteiten te vinden 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 gebeurtenis.

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 attribuut is belangrijk voor 'Priority-Based Flow Analysis'. Het stelt analysesten in staat om te verifiëren of hoge prioriteit items daadwerkelijk sneller worden verwerkt dan lage prioriteit items en om de doorlooptijd variance te meten op basis van prioriteit. Het helpt bij het ewaarderen van de effectiviteit van het prioriteringsproces.

Het belang

Maakt analyse mogelijk of hoge prioriteit 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 productkenmerk, 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 attribuut filtering en vergelijking van procesprestaties over verschillende projecten mogelijk. Het helpt vragen te beantwoorden zoals 'Welk project heeft de langste doorlooptijd?' of 'Hoe verhoudt het bug fix proces in Project A zich tot Project B?'. Het is belangrijk 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 mogelijk maakt.

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/datapijplijn
Toegewezen Gebruiker
Assignee
De gebruiker of developer die is toegewezen aan het development item of een specifieke taak, zoals een pull request review.
Omschrijving

Dit attribuut 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 belangrijk voor het begrijpen van bron allocation en workload.\n\nDit attribuut wordt gebruikt in analyse om de developer workload te monitoren, bron knelpunten te vinden en handoff efficiëntie tussen verschillende teamleden te analyseren. Dashboards kunnen worden gefilterd op assignee om individuele of team prestaties te beoordelen en een gebalanceerde distributie van werk te zorgen.

Het belang

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

Vindplaats

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

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

Dit attribuut 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 belangrijk voor het stellen van passende prestaties expectations, aangezien een bug fix een veel kortere verwachte doorlooptijd kan hebben dan een nieuwe feature.\n\nDit attribuut maakt comparative analysis tussen verschillende work types mogelijk. Het helpt te analyseren of bug fixes sneller worden verwerkt dan nieuwe features, of om de bron 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. Verplicht een consistente labelconventie (bijv. 'type:bug', 'type:feature').

Voorbeelden
BugFeatureTaskTechnische schuld
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 ontwikkelproces. 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 zichtbaar maken 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 rework, 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.leeautomatisering-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 belangrijk voor het analyseren van het code review proces. Het helpt bij het vinden van knelpunten 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 gebeurtenis 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 attribuut 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 herstelwerk nodig is. Andere statussen kunnen 'COMMENTED' of 'PENDING' zijn.\n\nDit is een kritiek attribuut voor het analyseren van herstelwerk en quality. Een hoge frequentie van 'CHANGES_REQUESTED' gebeurtenissen kan duiden op issues met de initiële code quality of onduidelijke requirements. Het ondersteunt direct het 'Rework and Regression Loops' dashboard door te vinden wanneer een development item wordt teruggestuurd voor modificatie.

Het belang

Geeft direct rework-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
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 gebeurtenissen, 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 procesdata is opgehaald.
Omschrijving

Dit attribuut identificeert de oorsprong van de gebeurtenis data. Voor dit proces zou de waarde consistent 'GitHub' zijn. In een complexere omgeving waar development activiteiten meerdere systemen omvatten (bijv. Jira voor planning, GitHub voor code, Jenkins voor deployment), wordt dit veld gebruikt om de bron van elke gebeurtenis te onderscheiden.\n\nIn analyse helpt het bij het traceren van data terug naar de oorsprong voor validatie en probleemoplossing. 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 belangrijk is voor datavalidatie en voor het analyseren van processen die meerdere geïntegreerde systemen kunnen omvatten.

Vindplaats

Dit is doorgaans een static waarde die wordt toegevoegd tijdens het ETL-proces (data-extractie, transformation, and loading) om de bron van het 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 attribuut geeft weer 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 attribuut 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 omgeving. Het ondersteunt de 'CI Checks Passed' en 'CI Checks Failed' activiteiten 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 pijplijn.

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 kenmerk (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 analysesten in staat om een proces-gebeurtenis direct te koppelen aan de exacte codewijziging die is aangebracht. Dit kan zeer waardevol 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 traceerbaarheid voor audits en debugging mogelijk maakt.

Vindplaats

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

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

Dit attribuut specificeert waar de code wordt gedeployed. Het volgen van deployments naar verschillende omgevings is belangrijk voor het begrijpen van de volledige levenscyclus, van development tot production release.\n\nDit attribuut 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 omgevings te volgen. Het is belangrijk voor het weten wanneer een development item echt 'done' is en is geleverd aan gebruikers.

Het belang

Maakt onderscheid tussen pre-productie en producpakketeleases, wat belangrijk 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 pijplijns of andere automatisering.

Voorbeelden
developmentstagingproduction
Development Cycle Time
DevelopmentCycleTime
De totale verstreken tijd vanaf de creatie van een development item tot de uiteindelijke deployment of sluiting.
Omschrijving

Dit is een case-level metriek, berekend als het tijdsverschil tussen de allereerste gebeurtenis (bijv. 'Issue Created') en de finale gebeurtenis (bijv. 'Deployment Succeeded' of 'Issue Closed') voor een enkel development item.\n\nDit is een van de belangrijkste KPI's voor het meten van de algehele efficiëntie van het ontwikkelproces. Het ondersteunt direct het 'Overall Development Cycle Time' dashboard en de 'Average Development Cycle Time' KPI. Het verminderen van deze metriek 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
Handoff Wachttijd
HandoffWaitingTime
De berekende wachttijd die een development item doorbrengt tussen activiteiten uitgevoerd door verschillende personen.
Omschrijving

Deze metriek 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' gebeurtenis en een 'Changes Requested in Review' gebeurtenis door een andere gebruiker.\n\nDit is een kritieke metriek voor het vinden van communicatiekloven en coördinatieproblemen. Het ondersteunt het 'Critical Handoff Efficiency' dashboard en de 'Average Handoff Wachttijd' KPI. Hoge wachttijden bij handoff punten zijn vaak een teken van bron constraints of inefficiënte notification processes.

Het belang

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

Vindplaats

Berekend door sequentiële activiteiten te vinden waarbij het attribuut 'Assignee' of 'Gebruiker' 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 volgorde van activiteiten te analyseren.\n\nDit attribuut is belangrijk 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 analysesten de oorzaken van herstelwerk isoleren en onderzoeken.

Het belang

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

Vindplaats

Dit is een derived attribuut. De logica omvat het definiëren van een standaard processtroom 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 attribuut 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 vinden. Het is belangrijk 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 levenscyclus 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
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 bekijken 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, hoge prioriteitfeature, backend, needs-docstech-debt, refactor
Pull Request Number
PullRequestNumber
De unique kenmerk 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 belangrijk voor het volgen van de code-integratie en het review-subproces binnen de bredere ontwikkelingslevenscyclus. Het maakt gedetailleerde analyse van het code review proces mogelijk, inclusief reviewtijden, rework-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-kenmerk van de Pull Requests API.

Voorbeelden
12345678910
Tijdstip van extractie
LastDataUpdate
De timestamp die aangeeft wanneer de gegevens voor dit record het laatst zijn ververst vanuit het bronsysteem.
Omschrijving

Dit attribuut registreert de datum en tijd van de meest recente data-extractie of update. Het biedt metadata over hoe actueel de geanalyseerde data is. Dit is onderscheidend van de gebeurtenis timestamp, die vastlegt wanneer de business gebeurtenis plaatsvond.\n\nIn analyse is dit veld belangrijk voor het begrijpen van de relevantie 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 relevantie van de data aan, wat belangrijk 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 Laden van data).

Voorbeelden
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Verplicht Aanbevolen Optioneel

Activiteiten in de Softwareontwikkelingscyclus

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 gebeurtenis wordt afgeleid uit de status van checks gerapporteerd door systemen zoals GitHub Actions.
Het belang

Deze automated quality gate is belangrijk voor het garanderen van code stability. Failures of lange run times kunnen aanzienlijke knelpunten zijn in de delivery pijplijn.

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 levenscyclus van een development item, wat staat voor de formele creatie van een taak, bug of feature request. Deze gebeurtenis wordt expliciet vastgelegd wanneer een gebruiker een nieuwe issue aanmaakt in een GitHub repository.
Het belang

Dit is de primaire startactiviteit voor het proces, belangrijk voor het meten van de totale development doorlooptijd en het begrijpen van de initiële bronnen van werk.

Vindplaats

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

Vastleggen

Luister naar de 'opened' gebeurtenis 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 belangrijk voor het berekenen van end-to-end doorlooptijden.

Vindplaats

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

Vastleggen

Luister naar de 'closed' gebeurtenis 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 mijlpaal 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 gebeurtenis stream of webhooks. De gebeurtenis 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 gebeurtenis in GitHub.
Het belang

Dit is een kritieke mijlpaal die het einde van de initiële development fase en het begin van de review- en integration pijplijn markeert. Het is belangrijk voor het afzonderlijk analyseren van development en review doorlooptijden.

Vindplaats

Vastgelegd vanuit de GitHub Pull Request API gebeurtenis stream of webhooks. De gebeurtenis 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 mijlpaal vóór merging. De tijd die nodig is om deze state te bereiken vanaf PR creation is een kritieke KPI voor review procesefficiëntie.

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-gebeurtenissen voor de status 'APPROVED'.

Gebeurtenistype explicit
Branch aangemaakt
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 gebeurtenis 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 gebeurtenis 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' gebeurtenissen 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 gebeurtenissen 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 herstelwerk 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 gebeurtenis 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 gebeurtenissen is belangrijk voor het vinden van herstelwerk-loops. Meerdere pushes na een review geven aan dat er wijzigingen nodig waren, wat de algehele doorlooptijd beïnvloedt.

Vindplaats

Dit is een expliciete gebeurtenis 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' gebeurtenissen op een branch die is geassocieerd met een open pull request.

Gebeurtenistype explicit
Deployment succesvol
De code changes zijn succesvol gedeployed naar een specifieke omgeving, zoals staging of production. Deze gebeurtenis 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 belangrijk 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 gebeurtenissen 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 gebeurtenis die de levenscyclus voor het development item opnieuw start.
Het belang

Dit signaleert een significante herstelwerk 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 gebeurtenis vastgelegd vanuit de GitHub Issues API gebeurtenis stream. De gebeurtenis type is 'reopened'.

Vastleggen

Luister naar de 'reopened' gebeurtenis 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 knelpunten te meten.

Vindplaats

Vastgelegd vanuit de GitHub Pull Request API gebeurtenis stream of webhooks. De gebeurtenis 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 gebeurtenis signaleert expliciet een herstelwerk loop. Het analyseren van de frequentie helpt bij het vinden 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-gebeurtenissen voor de status 'CHANGES_REQUESTED'.

Gebeurtenistype explicit
Aanbevolen Optioneel

Extractiegidsen

Hoe u je data van GitHub haalt