Ihr Software Development Life Cycle (SDLC) Daten-Template

GitHub
Ihr Software Development Life Cycle (SDLC) Daten-Template

Ihr Software Development Life Cycle (SDLC) Daten-Template

Diese Datenvorlage bietet einen vollständigen Leitfaden zum Sammeln und Aufbereiten Ihrer Software Development Life Cycle (SDLC) Daten von GitHub. Sie finden empfohlene Attribute, wesentliche Aktivitäten zum Tracking und praktische Anleitungen zur Datenextraktion. Verwenden Sie diese Ressource, um einen präzisen Event Log für effektive Prozessanalyse und -optimierung zu erstellen.
  • Empfohlene Attribute zur Erfassung
  • Wichtige Aktivitäten für das Tracking
  • Extraktionsanleitung
Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Software Development Life Cycle (SDLC) Attribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihr Event Log (Event Log) aufnehmen sollten, für eine vollständige Software Development Life Cycle (SDLC) Analyse und Prozessentdeckung.
3 Erforderlich 5 Empfohlen 15 Optional
Name Beschreibung
`Development Item`
DevelopmentItemId
Der eindeutige Identifikator für eine einzelne Einheit der Entwicklungsarbeit, wie z. B. ein Funktion, Bug Fix oder Aufgabe. Dies dient als primärer Case-ID.
Beschreibung

Die Development Item ID verfolgt ein Work Item von seiner Erstellung bis zum finalen Deployment. Sie verknüpft alle zugehörigen Aktivitäten, wie Branch-Erstellung, Commits, Pull Requests, Reviews und Deployments, zu einer einzigen, zusammenhängenden Prozessinstanz.

In der Analyse wird diese ID verwendet, um die End-to-End Durchlaufzeit einer Entwicklungsaufgabe zu berechnen. Sie ermöglicht die Rekonstruktion der gesamten Reise eines Funktionen oder Bug Fixes und damit eine detaillierte Analyse von Engpässen, Nacharbeitsschleifen und Prozessvariationen für einzelne Work Items.

Bedeutung

Es ist der wesentliche Schlüssel für Process Mining, da es alle verwandten Entwicklungs-Ereignisse zu einem einzigen Case verbindet, um den End-to-End-Softwareentwicklungsprozess präzise zu visualisieren und zu analysierenn.

Datenquelle

Dies ist in der Regel die Issue Number oder Pull Request Number von GitHub. Sie kann aus dem 'number'-Feld im Payload von Issue- oder Pull Request-bezogenen Webhook-Ereignisse oder API-Responses extrahiert werden.

Beispiele
101PR-2345TASK-812
Aktivität
ActivityName
Der Name eines spezifischen Ereignisse oder einer Aufgabe, die innerhalb des Software Development Life Cycle (SDLC) aufgetreten ist.
Beschreibung

Der Aktivitätsname beschreibt einen einzelnen Schritt im Entwicklungsprozess, wie z. B. 'Issue Created', 'Code Pushed to PR', 'Pull Request Approved' oder 'Deployment Succeeded'. Diese Ereignisse bilden die Abfolge von Schritten, die den End-to-End-Prozess für ein Entwicklungselement darstellen.

Dieses Attribut ist die Basis für Process Mining, da es zur Konstruktion der Prozessablauf verwendet wird. Die Analyse der Reihenfolge, Häufigkeit und Dauer dieser Aktivitäten macht den tatsächlichen Prozessfluss sichtbar, identifiziert gängige Pfade, hebt Abweichungen hervor und identifiziert Engpässe.

Bedeutung

Dieses Attribut ist die Basis der Prozessablauf und ermöglicht die Visualisierung und Analyse der Ereignisabfolge im EntwicklungsLebenszyklus.

Datenquelle

Abgeleitet vom 'action'-Feld von Webhook-Event-Payloads (z. B. 'opened', 'closed' für ein Issue) oder vom Event-Typ selbst (z. B. 'PushEvent', 'PullRequestReviewEvent').

Beispiele
Problem erstelltPull Request geöffnetCode an PR gepushtReview angefordertPull Request zusammengeführt
Startzeit
EventTimestamp
Das genaue Datum und die Uhrzeit, zu der eine spezifische Entwicklungsaktivität oder ein Event stattgefunden hat.
Beschreibung

Dieser Zeitstempel markiert den Beginn einer Aktivität. Er ist maßgeblich für die chronologische Anordnung von Ereignisse, um den Prozessfluss für jedes Entwicklungselement zu rekonstruieren. Die Reihenfolge und Zeitdifferenz zwischen diesen Zeitstempels werden zur Analyse der Prozess-Performance verwendet.

In der Analyse ist dieses Attribut wichtig für die Berechnung aller zeitbasierten Metriken, einschließlich Durchlaufzeits, Bearbeitungszeiten und Wartezeiten. Es ermöglicht die Identifizierung von Verzögerungen zwischen den Schritten und liefert die Daten, die für die Engpassanalyse und Leistungsfähigkeit-Monitoring-Dashboards benötigt werden.

Bedeutung

Dieser Zeitstempel ist maßgeblich für die korrekte Reihenfolge von Ereignisse und die Berechnung aller Leistungsfähigkeit-Metriken, wie Durchlaufzeits und Engpass-Dauern.

Datenquelle

Typischerweise als 'created_at'- oder 'updated_at'-Felder in den JSON-Payloads von GitHub APIs und Webhooks für verschiedene Objekte wie Issues, Pull Requests und Commits gefunden.

Beispiele
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Endzeit
EndTimestamp
Das genaue Datum und die Uhrzeit, zu der eine spezifische Entwicklungsaktivität oder ein Event abgeschlossen wurde.
Beschreibung

Der End-Zeitstempel markiert den Abschluss einer Aktivität. Während viele Ereignisse in GitHub augenblicklich sind (z. B. 'Issue Created'), haben einige Aktivitäten eine messbare Dauer (z. B. ein laufender CI Check). Die Differenz zwischen End Time und Start Time ergibt die Bearbeitungszeit für eine Aktivität.

Dieses Attribut wird verwendet, um die Metrik 'Bearbeitungszeit' (ProcessingTime) zu berechnen, die wichtig ist, um zu verstehen, wie viel aktiver Aufwand für verschiedene Aufgaben wie Code Reviews oder automatisierte Checks aufgewendet wird. Die Analyse der Bearbeitungszeiten hilft, ineffiziente Aktivitäten zu identifizieren, die zu viel Zeit in Anspruch nehmen.

Bedeutung

Ermöglicht die Berechnung präziser Bearbeitungszeiten für Aktivitäten und hilft so, zwischen aktiver Arbeitszeit und untätiger Wartezeit zu unterscheiden.

Datenquelle

Kann als 'completed_at' in Check-Run-Objekten gefunden oder vom Zeitstempel eines nachfolgenden, logisch abschließenden Ereignisse abgeleitet werden.

Beispiele
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Priorität
Priority
Die Prioritätsstufe, die einem Entwicklungselement zugewiesen wurde, z. B. 'High', 'Medium' oder 'Low'.
Beschreibung

Priorität kennzeichnet die Dringlichkeit oder geschäftliche Bedeutung eines Work Items. In GitHub ist Priorität kein natives Feld und wird in der Regel über Labels (z. B. 'P1-High', 'P2-Medium') verwaltet. Ein konsistentes Labeling-Schema ist erforderlich, um diese Informationen leistungsstark zu extrahieren.

Dieses Attribut ist wichtig für die 'Priority-Based Flow Analysis'. Es ermöglicht Analysten zu überprüfen, ob hochpriorisierte Elemente tatsächlich schneller verarbeitet werden als niedrigpriorisierte, und die Durchlaufzeit-Varianz basierend auf der Priorität zu messen. Es hilft bei der Bewertung der Effektivität des Priorisierungsprozesses.

Bedeutung

Ermöglicht die Analyse, ob Elemente mit hoher Priorität schneller verarbeitet werden als solche mit niedrigerer Priorität, wodurch die Wirksamkeit der Priorisierungsstrategie validiert wird.

Datenquelle

Abgeleitet von GitHub-Labels, die auf Issues oder Pull Requests angewendet werden. Erfordert eine standardisierte Konvention für Prioritäts-Labels.

Beispiele
HochMittelNiedrigKritisch
Repository
RepositoryName
Der Name des Code-Repositorys, in dem die Entwicklungsaktivität stattfindet.
Beschreibung

Das Repository dient als Projekt- oder Produkt-Identifikator, der den Antrag bearbeitet.en gesamten Code, Issues und Pull Requests für eine spezifische Anwendung oder Komponente enthält. Es bietet eine Möglichkeit, Entwicklungsprozesse über verschiedene Produkte oder Teams hinweg zu segmentieren und zu vergleichen.

In der Analyse ermöglicht dieses Attribut das Filtern und Vergleichen der Prozess-Performance über verschiedene Projekte hinweg. Es hilft, Fragen zu beantworten wie: 'Welches Projekt hat die längste Durchlaufzeit?' oder 'Wie verhält sich der Bug-Fix-Prozess in Projekt A im Vergleich zu Projekt B?'. Es ist unerlässlich für das Dashboard 'Throughput by Project and Typ'.

Bedeutung

Ermöglicht die Segmentierung und den Vergleich von Entwicklungsprozessen über verschiedene Projekte, Produkte oder Teams hinweg und ermöglicht so eine gezieltere Analyse.

Datenquelle

Verfügbar im 'repository'-Objekt in fast allen GitHub-Webhook- und API-Payloads. Das spezifische Feld ist in der Regel 'repository.full_name' oder 'repository.name'.

Beispiele
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Typ des Entwicklungselements
DevelopmentItemType
Die Klassifizierung des Entwicklungselements, wie z. B. Funktion, Bug, Aufgabe oder Epic.
Beschreibung

Dieses Attribut kategorisiert die Art der ausgeführten Arbeit. Diese Informationen werden in der Regel über Labels oder spezifische Issue Templates innerhalb von GitHub verwaltet. Das Verständnis der Arbeitsart ist maßgeblich für die Festlegung angemessener Leistungsfähigkeit-Erwartungen, da ein Bug Fix eine viel kürzere erwartete Durchlaufzeit haben könnte als ein neues Funktion.

Dieses Attribut ermöglicht eine vergleichende Analyse zwischen verschiedenen Arbeitsarten. Es hilft zu analysierenn, ob Bug Fixes schneller verarbeitet werden als neue Funktionen, oder den Antrag bearbeitet.ie Ressourcenverteilung für Technical Debt gegenüber Neuentwicklungen zu verstehen. Es ist eine Schlüsseldimension im Dashboard 'Throughput by Project and Typ'.

Bedeutung

Kategorisiert Arbeitselemente und ermöglicht so Leistungsvergleiche und die Analyse, wie verschiedene Arten von Arbeit (z. B. Bugs vs. Funktionen) den Prozess durchlaufen.

Datenquelle

Typischerweise abgeleitet von GitHub Labels, die auf Issues oder Pull Requests angewendet werden. Erfordert eine konsistente Labeling-Konvention (z. B. 'type:bug', 'type:feature').

Beispiele
Bug`Funktion`AufgabeTechnische Schulden
Zugewiesener Benutzer
Assignee
Der Benutzer oder Entwickler, der für die Bearbeitung des Entwicklungselements oder einer spezifischen Aufgabe, wie einem Pull Request Review, zugewiesen ist.
Beschreibung

Dieses Attribut identifiziert die für die Arbeit in einer bestimmten Phase verantwortliche Person. Dies könnte der Assignee eines Issues, der Autor eines Pull Requests oder den Antrag bearbeitet.er für einen Code Review angeforderte Reviewer sein. Die Verfolgung des Assignees ist maßgeblich, um die Ressourcenverteilung und Workload zu verstehen.

Dieses Attribut wird in der Analyse verwendet, um die Entwickler-Workload zu überwachen, Ressourcenengpässe zu identifizieren und die Übergabeeffizienz zwischen verschiedenen Teammitgliedern zu analysierenn. Dashboards können nach Assignee gefiltert werden, um die individuelle oder Teamleistung zu bewerten und eine ausgewogene Arbeitsverteilung sicherzustellen.

Bedeutung

Wesentlich für die Analyse der Entwickler-Arbeitslast, der Teamleistung und der Effizienz von Übergaben zwischen verschiedenen Teammitgliedern.

Datenquelle

Verfügbar im 'assignee'- oder 'user'-Objekt innerhalb der JSON-Payloads für Issues, Pull Requests und Review-Ereignisse von der GitHub API.

Beispiele
john.doejane.smithdev-team-lead
Autor
Author
Der Benutzer, der den Antrag bearbeitet.as Issue, den Pull Request oder den Antrag bearbeitet.en Commit erstellt hat.
Beschreibung

Der Autor ist der Urheber eines spezifischen Artefakts im Entwicklungsprozess. Zum Beispiel ist der Autor eines Issues die Person, die den Bug gemeldet oder den Antrag bearbeitet.as Funktion angefordert hat. Der Autor eines Pull Requests ist der Entwickler, der den Antrag bearbeitet.en Code geschrieben hat.

In der Analyse kann der Autor verwendet werden, um die Ursprünge der Arbeit zu verstehen. Beispielsweise könnte die Analyse der Autoren von Bug-Reports Muster aufdecken, die mit bestimmten Teams oder Funktionen verknüpft. Sie kann auch in Verbindung mit dem Assignee verwendet werden, um Übergabemuster zu analysierenn.

Bedeutung

Identifiziert den Urheber eines Arbeitselements oder einer Codeänderung, was nützlich sein kann, um Quellen von Nacharbeit, Bug-Reports oder Funktion-Requests zu analysierenn.

Datenquelle

Verfügbar im 'user'-Objekt innerhalb des Hauptobjekts von API-Antworten für Issues, Pull Requests und Commits. Das Feld ist in der Regel 'user.login'.

Beispiele
sara.jonesmike.leeautomation-bot
Bereitstellungsumgebung
DeploymentEnvironment
Die Zielumgebung für ein Deployment, wie z. B. 'Staging' oder 'Production'.
Beschreibung

Dieses Attribut gibt an, wohin der Code deployed wird. Das Tracking von Deployments in verschiedene Umgebungen ist maßgeblich, um den gesamten Lebenszyklus, von der Entwicklung bis zum Production Release, zu verstehen.

Dieses Attribut ermöglicht die Analyse des Deployment-Subprozesses. Es kann verwendet werden, um die Zeit zu messen, die benötigt wird, um Code von Staging nach Production zu promoten, und um die Erfolgsrate von Deployments in verschiedene Umgebungen zu verfolgen. Es ist wichtig, um zu wissen, wann ein Entwicklungselement wirklich 'done' und an Benutzer ausgeliefert ist.

Bedeutung

Unterscheidet zwischen Pre-Production- und Produktions-Releases, was wichtig ist, um die tatsächliche 'Time-to-Market' zu messen und Bereitstellungsmuster zu analysierenn.

Datenquelle

Diese Informationen werden von der GitHub Deployments API abgerufen, die oft durch CI/CD Pipelines oder andere Automatisierungen ausgelöst wird.

Beispiele
developmentstagingproduction
Branch-Name
BranchName
Der Name des Git-Branchs, in dem die Code-Änderungen für das Entwicklungselement vorgenommen wurden.
Beschreibung

Ein Branch ist eine unabhängige Entwicklungslinie, die erstellt wird, um an einem neuen Funktion oder einem Bugfix zu arbeiten, ohne die Hauptcodebasis zu beeinflussen. Der Branch-Name enthält oft nützliche Informationen, wie die Issue-Nummer oder eine kurze Beschreibung der Arbeit.

Die Analyse von Branch-Namen kann dazu beitragen, Branching-Strategien und die Einhaltung von Entwicklungskonventionen zu verstehen. Es hilft auch, spezifische Code-Commits mit einem Entwicklungselement zu verknüpfen und so ein vollständiges Bild der Codierungsaktivität zu liefern.

Bedeutung

Bietet Kontext über die spezifische Entwicklungslinie und hilft bei der Durchsetzung und Analyse von Branching-Strategien und Namenskonventionen.

Datenquelle

Verfügbar im 'ref'-Feld für Push-Ereignisse oder in den 'head'- und 'base'-Objekten innerhalb einer Pull Request API-Antwort.

Beispiele
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
CI-Prüfstatus
CiCheckStatus
Der Status einer automatisierten Continuous Integration (CI) Prüfung, z. B. 'passed' oder 'failed'.
Beschreibung

Dieses Attribut spiegelt das Ergebnis automatisierter Builds, Tests und Scans wider, die gegen Code-Änderungen in einem Pull Request ausgeführt werden. CI Checks sind ein kritischer Qualitätssicherungsschritt in modernen Entwicklungs-Workflows.

Die Analyse dieses Attributs hilft, die Effektivität des automatisierten Testings zu verstehen. Eine hohe Fehlerquote kann auf Probleme mit der Code-Stabilität, der Testsuite oder den Antrag bearbeitet.er Entwicklungsumgebung hinweisen. Es unterstützt die Aktivitäten 'CI Checks Passed' und 'CI Checks Failed' und hilft bei der Analyse von Verzögerungen, die durch fehlerhafte Builds verursacht werden.

Bedeutung

Zeigt den Erfolg oder Misserfolg automatisierter Qualitätstore an und gibt Einblick in die Codequalität und die Effektivität der CI-Pipeline.

Datenquelle

Ermittelt aus dem 'state'- oder 'conclusion'-Feld von Check-Run- oder Status-Objekten über die GitHub Checks oder Statuses API.

Beispiele
successfailurependingerror
Commit Hash
CommitHash
Der eindeutige Identifikator (SHA) für einen spezifischen Code Commit.
Beschreibung

Ein Commit Hash ist ein 40-stelliger SHA-1-Hash, der einen Commit in Git eindeutig identifiziert. Er dient als permanente ID für eine spezifische Version des Codes. Commits sind die atomaren Einheiten der Änderung im Entwicklungsprozess.

Obwohl hochgranular, bietet der Commit Hash die ultimative Rückverfolgbarkeit. Er ermöglicht es Analysten, ein Prozessereignis direkt mit der exakten vorgenommenen Codeänderung zu verknüpfen. Dies kann für Audits, Compliance oder den Antrag bearbeitet.etaillierte Ursachenanalysen von Produktionsvorfällen von besonders wertvoll sein.

Bedeutung

Stellt die granularste Verknüpfung zwischen einem Prozessschritt und der exakten Codeänderung bereit, wodurch eine vollständige Nachvollziehbarkeit für Audits und Debugging ermöglicht wird.

Datenquelle

Verfügbar in Push-Event-Payloads ('head_commit.id') oder über die Commits API für einen Pull Request oder Branch.

Beispiele
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Elementstatus
State
Der aktuelle Status eines Issues oder Pull Requests, z. B. 'open', 'closed' oder 'merged'.
Beschreibung

Dieses Attribut gibt den übergeordneten Status eines Entwicklungselements an. Bei Issues sind die typischen Zustände 'open' und 'closed'. Bei Pull Requests umfassen die Zustände 'open', 'closed' und 'merged'. Dies bietet eine Momentaufnahme des Fortschritts des Elements.

In der Analyse wird der Zustand verwendet, um aktive von abgeschlossenen Arbeiten zu unterscheiden. Er ist unerlässlich für Dashboards wie 'Active Development Progress', die laufende Arbeiten überwachen. Er wird auch verwendet, um das Ende eines Prozesses zu definieren, zum Beispiel könnte ein Zustand von 'merged' oder 'closed' den Abschluss eines Case bedeuten.

Bedeutung

Bietet einen klaren Hinweis darauf, ob ein Work Item gerade in Bearbeitung oder abgeschlossen ist, was für die Lebenszyklusanalyse und die Überwachung aktiver Arbeiten von grundlegender Bedeutung ist.

Datenquelle

Direkt verfügbar als 'state'-Feld in den JSON-Payloads für Issues und Pull Requests von der GitHub API.

Beispiele
opengeschlossenmerged
Entwicklungs-`Durchlaufzeit`
DevelopmentCycleTime
Die gesamte verstrichene Zeit von der Erstellung eines Entwicklungselements bis zu dessen finalem Deployment oder Abschluss.
Beschreibung

Dies ist eine Case-Level-Metrik, berechnet als Zeitdifferenz zwischen dem allerersten Event (z. B. 'Issue Created') und dem finalen Event (z. B. 'Deployment Succeeded' oder 'Issue Closed') für ein einzelnes Entwicklungselement.

Dies ist einer der wichtigsten KPIs zur Messung der Gesamteffizienz des Entwicklungsprozesses. Er unterstützt direkt das Dashboard 'Overall Development Durchlaufzeit' und den KPI 'Average Development Durchlaufzeit'. Die Reduzierung dieser Metrik ist oft ein primäres Ziel von Prozessoptimierungsinitiativen.

Bedeutung

Repräsentiert die End-to-End 'Time-to-Market' für ein Entwicklungselement, was es zu einem kritischen KPI für die Messung der gesamten Prozessgeschwindigkeit und Effizienz macht.

Datenquelle

Berechnet auf Fallebene durch Subtraktion des Zeitstempels der ersten Aktivität vom Zeitstempel der letzten Aktivität.

Beispiele
P5DT6H30MP14DT12HP1DT2H
Ist Nacharbeit
IsRework
Ein boolesches Flag, das wahr ist, wenn eine Aktivität eine Regression zu einer vorherigen Prozessphase darstellt.
Beschreibung

Dieses Flag wird auf 'Ja' gesetzt, wenn ein Entwicklungselement im Prozess rückwärts bewegt wird, z. B. wenn ein Pull Request ein 'Changes Requested'-Review erhält oder wenn ein Issue nach dem Schließen wieder geöffnet wird. Es wird durch die Analyse der Abfolge von Aktivitäten abgeleitet.

Dieses Attribut ist wichtig für die Quantifizierung von Verschwendung und Ineffizienz. Es unterstützt direkt das Dashboard 'Rework and Regression Loops' und den KPI 'Rework Rate'. Durch das Filtern nach 'IsRework = Ja' können Analysten die Ursachen für Nacharbeit isolieren und untersuchen.

Bedeutung

Kennzeichnet explizit Aktivitäten, die Nacharbeit darstellen, wodurch es einfach wird, die Ursachen von Prozessineffizienzen zu quantifizieren, zu visualisieren und zu analysierenn.

Datenquelle

Dies ist ein abgeleitetes Attribut. Die Logik beinhaltet die Definition eines Standard-Prozessflusses und das Markieren jeder Aktivität, die durch die Rückkehr zu einer früheren logischen Phase abweicht.

Beispiele
JaNein
Labels
Labels
Eine Listee von Tags oder Labels, die einem Issue oder Pull Request zur Kategorisierung zugewiesen wurden.
Beschreibung

Labels in GitHub sind eine flexible Methode, um Issues und Pull Requests MetaDaten hinzuzufügen. Sie können verwendet werden, um Priorität, Arbeitsart, Komponenten, Teams oder Status zu kennzeichnen. Die Rohliste der Labels bietet einen reichhaltigen, unstrukturierten Kontext.

Während spezifische Attribute wie Priorität und Typ von Labels abgeleitet werden, kann die Beibehaltung der vollständigen Listee für Ad-hoc-Analysen und die Entdeckung anderer Prozessmuster nützlich sein. Sie ermöglicht eine flexible Filterung und Segmentierung von Fälle basierend auf jeder Kombination von Labels.

Bedeutung

Bietet eine flexible, reichhaltige Quelle für MetaDaten zur Kategorisierung von Work Items, die eine tiefe und vielfältige dimensionale Analyse ermöglicht.

Datenquelle

Verfügbar als 'labels'-Array im JSON-Payload für Issues und Pull Requests von der GitHub API. Jedes Element im Array ist ein Objekt mit einem 'name'-Feld.

Beispiele
bug, ui, high-priorityfeature, backend, needs-docstech-debt, refactor
Letzte Datenaktualisierung
LastDataUpdate
Der Zeitstempel, der angibt, wann die Daten für diesen Datensatz zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung

Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder -aktualisierung. Es liefert MetaDaten über die Aktualität der analysierten Daten. Dies unterscheidet sich vom Event-Zeitstempel, der aufzeichnet, wann das Geschäftsereignis stattfand.

In der Analyse ist dieses Feld wichtig, um die Aktualität der Prozessansicht zu verstehen. Es hilft Benutzern zu wissen, ob sie EchtzeitDaten oder eine Momentaufnahme zu einem bestimmten Zeitpunkt betrachten, was für operative Dashboards und das Monitoring wichtig ist.

Bedeutung

Zeigt die Aktualität der Daten an, was wichtig ist, um sicherzustellen, dass Analysen und Dashboards auf aktuellen Informationen basieren.

Datenquelle

Dieser Zeitstempel wird während des Daten-Extraktions-, Transformations- und Ladevorgangs (ETL-Prozess) generiert und hinzugefügt.

Beispiele
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Prüfer
Reviewer
Der Benutzer, der zur Durchführung eines Code Reviews für einen Pull Request angefordert wurde.
Beschreibung

Ein Reviewer ist ein Entwickler oder Teammitglied, das zugewiesen wird, um Codeänderungen in einem Pull Request auf Qualität, Korrektheit und Einhaltung von Standards zu prüfen. Ein Pull Request kann mehrere Reviewer haben.

Dieses Attribut ist maßgeblich für die Analyse des Code-Review-Prozesses. Es hilft, Engpässe im Zusammenhang mit spezifischen Reviewern zu identifizieren, die Verteilung der Review-Arbeitslast zu verstehen und die Zeit zu messen, die Reviewer benötigen, um auf Anfragen zu reagieren. Es ist eine Schlüsselkomponente für die Berechnung des KPIs 'Durchschnittliche Code-Review-Durchlaufzeit'.

Bedeutung

Identifiziert die Personen, die am Qualitätssicherungsprozess beteiligt sind, und ermöglicht so die Analyse von Review-Arbeitslasten, Verzögerungen und der Gesamteffizienz von Code-Reviews.

Datenquelle

Verfügbar im 'requested_reviewers'-Array oder den Antrag bearbeitet.em 'user'-Objekt eines Pull Request Review-Ereignisse von der GitHub API.

Beispiele
alex.chenmaria.garciasenior-dev-team
Prüfstatus
ReviewState
Das Ergebnis eines Code Reviews bei einem Pull Request, wie z. B. 'Approved' oder 'Changes Requested'.
Beschreibung

Dieses Attribut erfasst die Entscheidung eines Reviewers. Gängige Zustände sind 'APPROVED', was anzeigt, dass der Code zum Mergen bereit ist, und 'CHANGES_REQUESTED', was darauf hinweist, dass Nacharbeit erforderlich ist. Andere Zustände könnten 'COMMENTED' oder 'PENDING' sein.

Dies ist ein kritisches Attribut für die Analyse von Nacharbeit und Qualität. Eine hohe Häufigkeit von 'CHANGES_REQUESTED'-Ereignisse kann auf Probleme mit der initialen Codequalität oder unklare Anforderungen hindeuten. Es unterstützt direkt das Dashboard 'Rework and Regression Loops', indem es identifiziert, wann ein Entwicklungselement zur Änderung zurückgesendet wird.

Bedeutung

Zeigt direkt Nacharbeitsschleifen und Qualitätstore innerhalb des Code-Review-Prozesses an und hilft, die Quellen von Ineffizienz und Qualitätsproblemen genau zu bestimmen.

Datenquelle

Verfügbar als 'state'-Feld innerhalb eines Pull Request Review-Objekts von der GitHub API. Zum Beispiel in einem 'PullRequestReviewEvent'-Payload.

Beispiele
GENEHMIGTCHANGES_REQUESTEDCOMMENTED
Pull Request Nummer
PullRequestNumber
Der eindeutige Identifikator für einen Pull Request, der mit dem Entwicklungselement verknüpft ist.
Beschreibung

Ein Pull Request (PR) ist ein Vorschlag, eine Reihe von Codeänderungen in einen bestimmten Branch zusammenzuführen. Die Pull Request Nummer verknüpft Entwicklungsaktivitäten wie Code-Pushes und Reviews mit dem primären Entwicklungselement oder Issue.

Diese ID ist maßgeblich für die Verfolgung des Code-Integrations- und Review-Subprozesses innerhalb des gesamten EntwicklungsLebenszyklus. Sie ermöglicht eine detaillierte Analyse des Code-Review-Prozesses, einschließlich Review-Zeiten, während des Reviews identifizierter Nacharbeitszyklen und Merge-Raten. Sie verbindet die Planungsphase (Issue) mit der Implementierungsphase (PR).

Bedeutung

Verknüpft Issues mit den spezifischen Code-Änderungen und Review-Prozessen und ermöglicht so eine detaillierte Analyse des Code-Review-Zyklus und dessen Einfluss auf die gesamte Lieferzeit.

Datenquelle

Verfügbar als 'number'-Feld innerhalb des 'pull_request'-Objekts in vielen GitHub API-Antworten oder als Hauptidentifikator von der Pull Requests API.

Beispiele
12345678910
Quellsystem
SourceSystem
Das System, aus dem die Daten des Entwicklungsprozesses extrahiert wurden.
Beschreibung

Dieses Attribut identifiziert den Ursprung der Event-Daten. Für diesen Prozess wäre der Wert konsistent 'GitHub'. In einer komplexeren Umgebung, in der Entwicklungsaktivitäten mehrere Systeme umfassen (z. B. Jira für die Planung, GitHub für Code, Jenkins für Deployment), wird dieses Feld verwendet, um die Quelle jedes Ereignisse zu unterscheiden.

In der Analyse hilft es, Daten zur Validierung und Fehlerbehebung zu ihrem Ursprung zurückzuverfolgen. Es ermöglicht auch die Analyse von Prozessen, die verschiedene Plattformen überspannen, und bietet einen klaren Kontext für jede Aktivität.

Bedeutung

Identifiziert den Ursprung der Daten, was für die Datenvalidierung und die Analyse von Prozessen, die sich über mehrere integrierte Systeme erstrecken können, notwendig ist.

Datenquelle

Dies ist in der Regel ein statischer Wert, der während des Datenextraktions-, Transformations- und Ladevorgangs (ETL-Prozess) hinzugefügt wird, um die Quelle der Datensätze zu kennzeichnen.

Beispiele
GitHubGitHub Enterprise
Übergabe-Wartezeit
HandoffWaitingTime
Die berechnete Leerlaufzeit, die ein Entwicklungselement zwischen Aktivitäten verschiedener Personen wartet.
Beschreibung

Diese Metrik misst die Zeit zwischen dem Abschluss einer Aktivität und dem Beginn der nächsten, jedoch nur, wenn die verantwortliche Person wechselt. Zum Beispiel die Zeit zwischen einem 'Review Requested'-Event und einem 'Changes Requested in Review'-Event durch einen anderen Benutzer.

Dies ist eine kritische Metrik zur Identifizierung von Kommunikationslücken und Koordinationsproblemen. Sie unterstützt das Dashboard 'Critical Handoff Efficiency' und den KPI 'Average Handoff Wartezeit'. Hohe Wartezeiten an Übergabepunkten sind oft ein Zeichen für Ressourcenengpässe oder ineffiziente Benachrichtigungsprozesse.

Bedeutung

Zeigt Verzögerungen auf, die durch schlechte Koordination oder Ressourcenmangel bei Übergaben zwischen verschiedenen Teams oder Rollen entstehen, welche oft Hauptursachen für Ineffizienz sind.

Datenquelle

Berechnet durch die Identifizierung sequentieller Aktivitäten, bei denen sich das Attribut 'Assignee' oder 'Benutzer' ändert, und anschließende Messung der Zeitlücke dazwischen.

Beispiele
PT1H15MP2DT4HPT25M
Erforderlich Empfohlen Optional

Software Development Life Cycle (SDLC) Aktivitäten

Dies sind die wichtigen Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um eine präzise Prozessentdeckung und Engpasserkennung zu sicherstellen.
6 Empfohlen 7 Optional
Aktivität Beschreibung
CI-Checks bestanden
Repräsentiert den erfolgreichen Abschluss automatisierter Prüfungen, wie z. B. Builds, Unit Tests oder statische Analyse, die gegen den Code in einem Pull Request ausgeführt wurden. Dieses Event wird aus dem Status der Prüfungen abgeleitet, die von Systemen wie GitHub Actions gemeldet werden.
Bedeutung

Dieser automatisierte Qualitätssicherungsschritt ist maßgeblich für die Code-Stabilität. Fehler oder lange Laufzeiten können erhebliche Engpässe in der Delivery Pipeline darstellen.

Datenquelle

Abgeleitet von der GitHub Checks API oder Statuses API. Ein Check-Run oder Status-Update meldet einen 'success' oder 'completed' mit einem 'success'-Schluss.

Erfassen

Überwachen Sie die Checks API auf eine 'success'-Conclusion bei den relevanten Check-Suites.

Ereignistyp inferred
Problem erstellt
Dies markiert den Beginn des Lebenszyklus eines Entwicklungselements und stellt die formelle Erstellung einer Aufgabe, eines Bugs oder einer Funktion-Anfrage dar. Dieses Event wird explizit erfasst, wenn ein Benutzer ein neues Issue in einem GitHub Repository erstellt.
Bedeutung

Dies ist die primäre Startaktivität für den Prozess, die wichtig ist, um die gesamte Entwicklungs-Durchlaufzeit zu messen und die initialen Arbeitsquellen zu verstehen.

Datenquelle

Dies ist ein explizites Event, das aus dem GitHub Issues API Event Stream erfasst wird. Der Event-Typ ist in der Regel 'opened' für eine gegebene Issue-Nummer.

Erfassen

Überwachen Sie das 'opened'-Event eines Issues über Webhooks oder API-Polling.

Ereignistyp explicit
Pull Request genehmigt
Ein Reviewer hat die Änderungen in einem Pull Request formell genehmigt und damit bestätigt, dass dieser Qualitäts- und Funktionsstandards erfüllt. Dies wird erfasst, wenn ein Reviewer sein Review mit dem Status 'approve' einreicht.
Bedeutung

Dies ist ein wichtiger Qualitätssicherungsschritt und ein wichtiger Meilenstein vor dem Mergen. Die Zeit, die benötigt wird, um diesen Zustand ab der PR-Erstellung zu erreichen, ist ein kritischer KPI für die Effizienz des Review-Prozesses.

Datenquelle

Erfasst von der GitHub Pull Request API oder Webhooks, wenn ein Review mit dem Status 'APPROVED' eingereicht wird.

Erfassen

Filtern Sie Pull Request Review-Einreichungs-Ereignisse nach dem Status 'APPROVED'.

Ereignistyp explicit
Pull Request geöffnet
Zeigt an, dass ein initialer Codeblock zur Überprüfung und Integration bereit ist. Ein Entwickler erstellt einen Pull Request (PR), um Änderungen von seinem Funktion Branch in einen Main Branch vorzuschlagen. Dies ist ein explizites Event in GitHub.
Bedeutung

Dies ist ein kritischer Meilenstein, der den Antrag bearbeitet.as Ende der initialen Entwicklungsphase und den Beginn der Review- und Integrations-Pipeline markiert. Er ist maßgeblich für die separate Analyse von Entwicklungs- und Review-Durchlaufzeits.

Datenquelle

Erfasst aus dem GitHub Pull Request API Event-Stream oder Webhooks. Die Event-Aktion ist 'opened'.

Erfassen

Überwachen Sie die 'opened'-Aktion für einen Pull Request über Webhooks oder API-Polling.

Ereignistyp explicit
Pull Request zusammengeführt
Die genehmigten Code-Änderungen aus dem Pull Request werden offiziell in den Ziel-Branch, wie z. B. Main oder Develop, integriert. Dies ist eine explizite, finale Aktion bei einem Pull Request, die den neuen Code integriert.
Bedeutung

Dies ist ein kritischer Meilenstein, der den Antrag bearbeitet.en Abschluss von Entwicklung und Review darstellt. Für viele Teams ist dies der letzte Schritt vor dem automatisierten Deployment.

Datenquelle

Erfasst aus dem GitHub Pull Request API Event-Stream oder Webhooks. Die Event-Aktion ist 'closed' und das 'merged'-Attribut des Pull Request Payloads ist Ja.

Erfassen

Überwachen Sie die 'closed'-Aktion eines Pull Requests und prüfen Sie, ob das 'merged'-Flag auf 'Ja' gesetzt ist.

Ereignistyp explicit
Sachverhalt abgeschlossen
Das Entwicklungselement gilt als abgeschlossen, und das entsprechende Issue wird formell geschlossen. Dies kann automatisch geschehen, wenn ein verknüpfter Pull Request gemerged wird, oder manuell von einem Teammitglied durchgeführt werden.
Bedeutung

Diese Aktivität dient als definitives Ende des Prozesses für ein Entwicklungselement. Sie ist maßgeblich für die Berechnung der End-to-End Durchlaufzeits.

Datenquelle

Dies ist ein explizites Event, das aus dem GitHub Issues API Event Stream erfasst wird. Der Event-Typ ist 'closed'.

Erfassen

Überwachen Sie das 'closed'-Event eines Issues über Webhooks oder API-Polling.

Ereignistyp explicit
Änderungen im Review angefordert
Ein Reviewer hat seine Code-Überprüfung abgeschlossen und festgestellt, dass Änderungen erforderlich sind, bevor der Pull Request genehmigt werden kann. Der Reviewer reicht sein Review formell mit dem Status 'request_changes' ein.
Bedeutung

Dieses Event signalisiert explizit eine Nacharbeitsschleife. Die Analyse seiner Häufigkeit hilft, Qualitätsprobleme, unklare Anforderungen oder Bereiche für Entwicklerschulungen zu identifizieren.

Datenquelle

Erfasst von der GitHub Pull Request API oder Webhooks, wenn ein Review mit dem Status 'CHANGES_REQUESTED' eingereicht wird.

Erfassen

Filtern Sie Pull Request Review-Einreichungs-Ereignisse nach dem Status 'CHANGES_REQUESTED'.

Ereignistyp explicit
Branch erstellt
Repräsentiert den Beginn der aktiven Entwicklungsarbeit für ein Issue, bei dem ein Entwickler einen neuen Branch vom Main-Codebase erstellt. Dies ist ein explizites Event, das erfasst wird, wenn ein neuer Branch in das Repository gepusht wird und oft die Issue-Nummer im Namen enthält.
Bedeutung

Zeigt den Übergang von der Planung zur aktiven Codierung an. Die Messung der Zeit zwischen der Issue-Erstellung und diesem Event hilft, die Entwickler-Aufnahmezeit und anfängliche Backlog-Verzögerungen zu analysierenn.

Datenquelle

Erfasst über die GitHub Git API oder Webhooks, die auf 'create'-Ereignisse vom Typ 'branch' hören. Es ist oft notwendig, den Branch-Namen über Namenskonventionen, wie 'feature/issue-123', mit einem Issue zu verknüpfen.

Erfassen

Parsen Sie 'create'-Webhook-Ereignisse für neue Branches und verknüpfen Sie diese mit einem Issue.

Ereignistyp explicit
CI-Prüfungen fehlgeschlagen
Repräsentiert das Scheitern einer automatisierten Prüfung, wie z. B. ein Build-Fehler oder ein fehlgeschlagener Unit Test, der gegen den Code in einem Pull Request ausgeführt wurde. Dies wird von einem Fehlermeldungsstatus abgeleitet, der von einem System wie GitHub Actions gemeldet wird.
Bedeutung

Diese Aktivität hebt technische Qualitätsprobleme hervor, die ein Eingreifen des Entwicklers erfordern und eine Nacharbeitsschleife erzeugen. Die Analyse der Fehlerhäufigkeit kann Verbesserungen beim lokalen Testing oder den Antrag bearbeitet.er Codequalität leiten.

Datenquelle

Abgeleitet von der GitHub Checks API oder Statuses API. Ein Check-Run oder Status-Update meldet einen 'failure' oder 'completed' mit einem 'failure'-Schluss.

Erfassen

Überwachen Sie die Checks API auf eine 'failure'-Conclusion bei den relevanten Check-Suites.

Ereignistyp inferred
Code an PR gepusht
Stellt eine Aktualisierung des zur Überprüfung eingereichten Codes dar, entweder als Teil des initialen PRs oder als Reaktion auf Review-Feedback. Dieses Event wird jedes Mal erfasst, wenn ein neuer Commit auf den Branch gepusht wird, der mit einem offenen Pull Request verknüpft ist.
Bedeutung

Das Tracking dieser Ereignisse ist maßgeblich, um Nacharbeitsschleifen zu identifizieren. Mehrere Pushes nach einem Review deuten darauf hin, dass Änderungen erforderlich waren, was die gesamte Durchlaufzeit beeinflusst.

Datenquelle

Dies ist ein explizites Event in der Pull Request Timeline, oft als hinzugefügter Commit bezeichnet. Es kann vom 'push'-Webhook oder den Antrag bearbeitet.urch Überwachung der mit einem PR verknüpften Commits erfasst werden.

Erfassen

Verfolgen Sie 'push'-Ereignisse auf einem Branch, der mit einem offenen Pull Request verknüpft ist.

Ereignistyp explicit
Deployment erfolgreich
Die Code-Änderungen wurden erfolgreich in eine bestimmte Umgebung, wie Staging oder Production, deployed. Dieses Event wird in der Regel über die GitHub Deployments API erfasst, oft ausgelöst durch eine GitHub Action nach einem Merge.
Bedeutung

Dies kennzeichnet den Übergang von Code aus dem Repository in eine Live-Umgebung. Die Verfolgung ist maßgeblich, um die gesamte Lead Time von der Idee bis zur Produktion zu messen.

Datenquelle

Erfasst über die Deployments API. Ein externer Service oder eine GitHub Action erstellt ein Deployment und aktualisiert dann dessen Status auf 'success'.

Erfassen

Überwachen Sie Deployment-Status-Ereignisse über Webhooks auf den Status 'success'.

Ereignistyp inferred
Issue wiedereröffnet
Ein zuvor geschlossenes Issue wird reaktiviert, in der Regel weil der Fix unzureichend war oder eine Regression gefunden wurde. Dies ist ein explizites Event, das den Lebenszyklus des Entwicklungselements neu startet.
Bedeutung

Dies signalisiert eine signifikante Nacharbeitsschleife, die auf einen potenziellen 'Production Defect Escape' oder eine unvollständige Korrektur hindeutet. Die Verfolgung ihrer Häufigkeit ist ein Schlüsselmaß für die gesamte Softwarequalität.

Datenquelle

Dies ist ein explizites Event, das aus dem GitHub Issues API Event Stream erfasst wird. Der Event-Typ ist 'reopened'.

Erfassen

Überwachen Sie das 'reopened'-Event eines Issues über Webhooks oder API-Polling.

Ereignistyp explicit
Review angefordert
Der Autor eines Pull Requests fordert formell spezifische Teammitglieder oder Teams auf, seinen Code zu überprüfen. Dies ist eine explizite Aktion innerhalb der GitHub UI oder API, die Benachrichtigungen an die angeforderten Reviewer auslöst.
Bedeutung

Diese Aktivität markiert den offiziellen Beginn der Übergabe an den Code-Review-Prozess. Die Zeit zwischen diesem Schritt und einer Review-Einreichung hilft, die Reaktionsfähigkeit des Reviewers und potenzielle Engpässe zu messen.

Datenquelle

Erfasst aus dem GitHub Pull Request API Event-Stream oder Webhooks. Die Event-Aktion ist 'review_requested'.

Erfassen

Überwachen Sie die 'review_requested'-Aktion für einen Pull Request.

Ereignistyp explicit
Empfohlen Optional

Extraktionsanleitungen

So erhalten Sie Ihre Daten von GitHub