Uw Softwareontwikkelingscyclus datatemplate
Uw Softwareontwikkelingscyclus datatemplate
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen
- Richtlijnen voor data-extractie
Attributen van de Softwareontwikkelingscyclus
| 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
Voorbeelden
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
Activiteiten in de Softwareontwikkelingscyclus
| 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
|
|||