Ihr Software Development Lifecycle Daten-Template
Ihr Software Development Lifecycle Daten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung
Software Development Lifecycle Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
Activity
|
Der Name des spezifischen Prozessschritts oder Events, das aufgetreten ist, wie 'Issue Created' oder 'Merge Request Merged'. | ||
|
Beschreibung
Das Attribut Activity erfasst die einzelnen Events, die ein Development Item durchläuft. Diese sind in GitLab nicht als einzelnes Feld gespeichert, sondern werden aus verschiedenen Aktionen und Timestamp-Feldern in Issues, Merge Requests und CI/CD Pipelines abgeleitet. Zum Beispiel sind die Erstellung eines Issue, das Pushen eines Commits, das Fehlschlagen einer Pipeline oder die Genehmigung eines Merge Request allesamt separate Aktivitäten. Dieses Attribut ist grundlegend für den Aufbau der Process Map, die Visualisierung des Workflows und die Analyse der Sequenz und Häufigkeit von Events. Es wird verwendet, um Abweichungen, Bottlenecks zwischen Schritten und gängige Prozesspfade zu identifizieren.
Bedeutung
Es definiert die Schritte in der Process Map und ermöglicht die Visualisierung und Analyse des End-to-End Development Workflows.
Datenquelle
Abgeleitet von Event-Typen und State Changes im GitLab Event Stream oder durch die Interpretation von Timestamp-Feldern wie 'created_at', 'merged_at' und 'closed_at' bei Issues und Merge Requests.
Beispiele
Problem erstelltEntwicklung gestartetMerge Request gemergtPipeline fehlgeschlagenIn Produktion deployed
|
|||
|
Development Item
DevelopmentItem
|
Der eindeutige Identifier für eine Arbeitseinheit, wie ein Feature, Bug Fix oder Task, der als primärer Case Identifier dient. | ||
|
Beschreibung
Das Development Item repräsentiert eine einzelne, verfolgbare Arbeitseinheit, die den Software Development Lifecycle durchläuft. Es verbindet alle zugehörigen Aktivitäten, von der Erstellung bis zum finalen Deployment, zu einem kohärenten Case. In GitLab wird dies typischerweise durch die interne ID (IID) des Issue dargestellt, die innerhalb eines Projekts eindeutig ist. Die Analyse nach Development Item ermöglicht die Messung der End-to-End Cycle Time, die Identifizierung von Bottlenecks und die Überprüfung der Prozesskonformität. Sie bildet die Grundlage für das Verständnis, wie effizient Arbeit vom Konzept bis zur Produktion geliefert wird.
Bedeutung
Dies ist der essenzielle Case Identifier, der alle Process Events miteinander verknüpft und es so ermöglicht, den gesamten Lifecycle jedes beliebigen Work Items nachzuvollziehen.
Datenquelle
Dies ist typischerweise die interne ID (IID) eines GitLab Issue. Sie kann in der Issues API-Antwort als 'iid'-Feld gefunden werden.
Beispiele
1024512PRJ-2345
|
|||
|
Startzeit
StartTime
|
Der `Timestamp`, der anzeigt, wann eine `Aktivität` oder ein `Event` begann. | ||
|
Beschreibung
StartTime markiert das genaue Datum und die Uhrzeit, zu der eine spezifische Aktivität aufgetreten ist. Für Events in GitLab wird dies in verschiedenen Timestamp-Feldern erfasst. Zum Beispiel wäre die StartTime der Aktivität 'Issue Created' der Dieser Timestamp ist das zentrale zeitliche Element im Process Mining. Er wird verwendet, um Events chronologisch zu ordnen, Dauern zwischen Aktivitäten zu berechnen, Cycle Times zu messen und die Prozessperformance über die Zeit zu analysieren.
Bedeutung
Dieses Attribut liefert die chronologische Sequenz von Events, die essenziell für die Berechnung aller zeitbasierten Metriken und das Verständnis des Process Flow ist.
Datenquelle
Extrahiert aus verschiedenen Timestamp-Feldern in GitLab, wie 'created_at', 'updated_at', 'closed_at' bei Issues und 'merged_at' bei Merge Requests.
Beispiele
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
Assignee
Assignee
|
Der Benutzer, der dem Issue oder Merge Request zum Zeitpunkt des Events zugewiesen war. | ||
|
Beschreibung
Der Assignee ist der einzelne Developer oder Nutzer, der zu einem bestimmten Zeitpunkt im Prozess für das Work Item verantwortlich ist. In GitLab wird dies im Feld Die Analyse nach Assignee ist entscheidend für das Dashboard 'Developer Workload & Allocation'. Sie hilft, die Ressourcenauslastung zu verstehen, überlastete Einzelpersonen oder Teams zu identifizieren und Handoffs zwischen verschiedenen Personen zu analysieren.
Bedeutung
Verfolgt, wer die Arbeit ausgeführt hat, ermöglicht die Analyse der Arbeitslast, die Effizienz der Ressourcenallokation und die Identifizierung von Verzögerungen durch Übergaben.
Datenquelle
Abgerufen aus den Feldern 'assignee.username' oder 'assignees' in den GitLab Issues und Merge Requests API-Antworten.
Beispiele
jdoeasmithr.williams
|
|||
|
Dev Item Typ
DevelopmentItemType
|
Die Klassifizierung des Development Items, wie 'Feature', 'Bug', 'Task' oder 'Maintenance'. | ||
|
Beschreibung
Dieses Attribut kategorisiert die Art der ausgeführten Arbeit. In GitLab wird dies üblicherweise durch Labels an einem Issue implementiert. Teams verwenden Labels, um zwischen neuen Funktionalitäten, Defect-Behebung, Technical Debt und anderen Work Types zu unterscheiden. Die Analyse nach Development Item Type ermöglicht den Vergleich von Process Flows und Cycle Times für verschiedene Arbeitsarten. So kann beispielsweise analysiert werden, ob Bugs schneller behoben werden als Funktionen entwickelt, oder ob Technical Debt Aufgaben einem anderen Review-Prozess folgen.
Bedeutung
Die Segmentierung des Prozesses nach Work Type hilft zu identifizieren, ob bestimmte Arten von Arbeit anfälliger für Verzögerungen, Nacharbeiten oder Abweichungen sind.
Datenquelle
Wird typischerweise von den 'Labels' eines GitLab
Beispiele
FeatureBugAufgabeTechnische Schuld
|
|||
|
Endzeit
EndTime
|
Der Timestamp, der anzeigt, wann eine Aktivität oder ein Event abgeschlossen wurde. | ||
|
Beschreibung
EndTime markiert das genaue Datum und die Uhrzeit, zu der eine Aktivität abgeschlossen wurde. Für viele atomare Events in GitLab, wie z.B. 'Issue Created', ist die EndTime dieselbe wie die StartTime. Für Aktivitäten, die eine Dauer haben, wie 'Code Review', stellt es den Abschluss-Timestamp dar, zum Beispiel, wenn die endgültige Genehmigung erteilt wird. Dieses Attribut ist unerlässlich für die genaue Berechnung der Dauer einzelner Aktivitäten (Processing Time). Es hilft bei der detaillierten Engpassanalyse, indem es zwischen der Zeit, die aktiv an einer Aufgabe gearbeitet wurde, und der Wartezeit zwischen Aufgaben unterscheidet.
Bedeutung
Ermöglicht die Berechnung präziser Aktivitätsdauern (Processing Times), was entscheidend ist, um ineffiziente Schritte im Prozess zu identifizieren.
Datenquelle
Bei atomaren Events ist dies identisch mit StartTime. Für dauerhafte Aktivitäten muss es durch das Auffinden eines entsprechenden Abschluss-Events in den Daten abgeleitet werden.
Beispiele
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Projekt Name
ProjectName
|
Der Name des GitLab-Projekts, zu dem das Development Item gehört. | ||
|
Beschreibung
Dieses Attribut identifiziert das spezifische Code-Repository oder Projekt, in dem die Arbeit ausgeführt wird. In GitLab ist jedes Issue und jeder Merge Request in einem Projekt enthalten. Die Analyse nach Project Name ermöglicht Performance-Vergleiche über verschiedene Produkte, Komponenten oder Services hinweg. Es kann helfen zu identifizieren, ob bestimmte Projekte gesündere SDLC-Prozesse aufweisen als andere, und ist nützlich für das Filtern von Dashboards auf einen spezifischen Interessensbereich.
Bedeutung
Ermöglicht die Segmentierung der Prozessanalyse nach Produkt, Anwendung oder Komponente, was gezielte Verbesserungsmaßnahmen erleichtert.
Datenquelle
Abgerufen aus den Feldern 'name' oder 'path_with_namespace' in der Project API, verknüpft über die 'project_id' in Issues und Merge Requests.
Beispiele
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Schweregrad
Severity
|
Der Severity-Level des Development Items, typischerweise für Bugs oder Incidents. | ||
|
Beschreibung
Severity gibt den Impact eines Bugs oder Issue an, von kritisch bis geringfügig. GitLab verfügt über kein natives Severity-Feld, daher wird dies fast immer mit Labels implementiert (z.B. 'severity::1', 'severity::2'). Dieses Attribut ist essenziell für das Dashboard 'Severity Escalation Trends' und den zugehörigen KPI. Die Analyse von Severity-Änderungen über den Lifecycle kann Probleme aufzeigen, die anfänglich unterschätzt wurden, oder Prozesse, die Probleme verschärfen.
Bedeutung
Hilft bei der Priorisierung von Aufgaben und der Analyse, ob Elemente mit hoher Severity schneller bearbeitet werden. Die Verfolgung von Änderungen unterstützt den KPI 'Severity Escalation Frequency'.
Datenquelle
Abgeleitet von den 'Labels', die auf ein GitLab Issue angewendet werden. Eine Zuordnung ist erforderlich, um Labels wie 'S1', 'S2' als Severity Levels zu interpretieren.
Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
|
|||
|
Bearbeitungszeit
ProcessingTime
|
Die Dauer einer einzelnen Aktivität, berechnet als die Differenz zwischen ihrer End- und Startzeit. | ||
|
Beschreibung
Processing Time misst die aktive Arbeitszeit für eine spezifische Aktivität, getrennt von der Wartezeit zwischen den Aktivitäten. Sie wird als EndTime minus StartTime für einen einzelnen Event-Datensatz berechnet. Bei sofortigen Events ist die Processing Time null. Diese Metrik ist entscheidend für die Stage-Specific Bottleneck Analysis. Durch die Aggregation der Processing Times von Aktivitäten innerhalb einer Phase, wie dem Code Review, können Analysten genau bestimmen, wie viel Zeit aktiv gearbeitet wird, und so ineffiziente Prozessschritte aufzeigen.
Bedeutung
Misst die Dauer einzelner Aktivitäten und hilft dabei, aktive Arbeitszeit von Leerlauf-Wartezeit für eine präzise Bottleneck-Analyse zu unterscheiden.
Datenquelle
Berechnet vom Process Mining Tool als Differenz zwischen der EndTime und StartTime einer Aktivität.
Beispiele
2 Stunden 30 Minuten0 Minuten3 Tage 8 Stunden
|
|||
|
Dev Item Status
DevelopmentItemStatus
|
Der Status des Development Items zum Zeitpunkt des Events, wie 'Open', 'In Progress' oder 'Closed'. | ||
|
Beschreibung
Dieses Attribut reflektiert den Status des primären Work Items, typischerweise eines Issue in GitLab. GitLab Issues haben einen Das Tracking von Statusänderungen ist entscheidend für das Verständnis des Case Lifecycle. Es hilft zu identifizieren, wie lange Elemente in jedem Status verbleiben, und kann verwendet werden, um in Dashboards wie 'SDLC End-to-End Cycle Time' nach aktiver oder abgeschlossener Arbeit zu filtern.
Bedeutung
Bietet einen Snapshot des Case-Status, ermöglicht die Analyse der in verschiedenen Phasen verbrachten Zeit und das Filtern nach laufender versus abgeschlossener Arbeit.
Datenquelle
Der primäre Status stammt aus dem 'state'-Feld eines GitLab Issue ('opened', 'closed'). Feiner granulierte Status werden oft von Labels abgeleitet.
Beispiele
openedgeschlossenIn BearbeitungIn Prüfung
|
|||
|
Durchlaufzeit
CycleTime
|
Die gesamte Zeitspanne von der ersten bis zur letzten Aktivität eines Development Items. | ||
|
Beschreibung
Die Cycle Time ist eine berechnete Metrik, die die Gesamtdauer eines Cases misst. Sie wird typischerweise als die Zeitdifferenz zwischen dem allerersten Event (z.B. 'Issue Created') und dem allerletzten Event (z.B. 'Deployed to Production') für ein einzelnes Development Item berechnet. Dies ist ein primärer KPI zur Messung der gesamten Prozesseffizienz. Sie ist die Schlüsselmetrik in Dashboards wie 'SDLC End-to-End Cycle Time' und wird verwendet, um Verbesserungen zu verfolgen und langwierige Cases zu identifizieren, die auf systemische Probleme hinweisen können.
Bedeutung
Dies ist ein zentraler Process Mining KPI, der die End-to-End-Effizienz des Development Lifecycle misst.
Datenquelle
Berechnet vom Process Mining Tool durch Subtraktion des minimalen StartTime vom maximalen StartTime für jede eindeutige CaseId.
Beispiele
10 Tage 4 Stunden23 Stunden 15 Minuten35 Tage
|
|||
|
Ist Nacharbeit
IsRework
|
Ein Boolescher Flag, der anzeigt, ob eine Aktivität Teil einer Nacharbeitsschleife ist. | ||
|
Beschreibung
Dieses berechnete Attribut kennzeichnet Aktivitäten, die einen Rückschritt im Prozess darstellen, wie die Rückkehr zur Entwicklung, nachdem das Testing bereits begonnen hat. Die Logik für dieses Flag beinhaltet typischerweise das Erkennen spezifischer Abfolgen von Aktivitäten, zum Beispiel ein 'Development Started'-Event, das nach einem 'Pipeline Failed'- oder 'QA Testing Started'-Event für denselben Case auftritt. Dieses Attribut treibt direkt das Dashboard 'Rework & Rerun Analysis' und den KPI 'Rework Rate After Testing' an. Es ermöglicht das einfache Filtern und Quantifizieren von Nacharbeiten und hilft Teams, deren Häufigkeit, Ursachen und Auswirkungen auf Projektzeitpläne zu verstehen.
Bedeutung
Kennzeichnet und quantifiziert Nacharbeiten direkt, was die Analyse der Ursachen und Auswirkungen von Prozessineffizienzen und Qualitätsproblemen erleichtert.
Datenquelle
Berechnet vom Process Mining Tool durch Analyse der Abfolge von Aktivitäten für jeden Case und Identifizierung von Mustern, die auf Nacharbeit hinweisen.
Beispiele
truefalsch
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der angibt, wann die Daten für dieses Event zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut zeichnet Datum und Uhrzeit auf, zu der die Event-Daten zuletzt im Process Mining Dataset extrahiert oder aktualisiert wurden. Es repräsentiert nicht den Zeitpunkt des Events, sondern den Zeitpunkt der letzten Synchronisierung des Event-Datensatzes. Diese Information ist entscheidend für das Verständnis der Datenfrische und die Validierung der Aktualität der Prozessanalyse. Sie hilft Nutzern, darauf zu vertrauen, dass die Dashboards und KPIs auf aktuellen Daten basieren, und informiert sie über die potenzielle Verzögerung zwischen Quellsystem und Analyse.
Bedeutung
Schafft Transparenz über die Datenfrische und stellt sicher, dass Nutzer über den Aktualitätsgrad der Prozessanalyse informiert sind.
Datenquelle
Dieser Timestamp wird vom Datenextraktionstool oder ETL-Prozess zum Zeitpunkt eines Daten-Refreshes generiert und aufgezeichnet.
Beispiele
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Meilenstein Titel
MilestoneTitle
|
Der Titel des Milestones oder Sprints, dem das Development Item zugewiesen ist. | ||
|
Beschreibung
Ein Milestone in GitLab wird verwendet, um die Arbeit an einem bestimmten Ziel oder innerhalb eines Zeitrahmens, wie z.B. einem Sprint oder einer Release-Version, zu verfolgen. Dieses Attribut erfasst den Namen oder Titel dieses Milestones. Dieses Attribut ermöglicht die Analyse der Prozess-Performance im Kontext spezifischer Sprints oder Planungsperioden. Es kann verwendet werden, um zu sehen, ob sich die Cycle Times von einem Sprint zum nächsten verbessern oder um die Prozessansicht so zu filtern, dass nur Arbeiten angezeigt werden, die sich auf ein bevorstehendes Release beziehen.
Bedeutung
Verknüpft Entwicklungsarbeit mit Planungszyklen wie Sprints oder Releases und ermöglicht die Analyse der Performance im Vergleich zu geplanten Timeboxes.
Datenquelle
Abgerufen aus dem Feld 'milestone.title' in den GitLab Issues oder Merge Requests API-Antworten.
Beispiele
Q4-2023 ReleaseSprint 23.11Phase 1: MVP
|
|||
|
Merge Request Status
MergeRequestStatus
|
Der Status des Merge Request, der dem Event zugeordnet ist, wie 'Opened', 'Merged' oder 'Closed'. | ||
|
Beschreibung
Dieses Attribut erfasst den Status eines Merge Request (MR) zum Zeitpunkt eines Events. GitLab MRs haben verschiedene Status: 'opened', 'closed', 'merged' oder 'locked'. Dies ist vom allgemeinen Development Item Status getrennt. Das Tracking des MR-Status ist entscheidend für die Analyse der Code-Integrationsphase des SDLC. Es unterstützt Dashboards wie 'Code Review Cycle Time & Throughput' direkt und hilft, Verzögerungen zwischen MR-Erstellung, Review, Genehmigung und Merging genau zu bestimmen.
Bedeutung
Bietet Transparenz in den Code Review und Merging Prozess, der oft ein kritischer Bottleneck im SDLC ist.
Datenquelle
Abgerufen aus dem Feld 'state' in der GitLab Merge Requests API-Antwort.
Beispiele
openedmergedgeschlossenlocked
|
|||
|
Pipeline Status
PipelineStatus
|
Der Status des CI/CD Pipeline-Laufs, wie 'Success', 'Failed' oder 'Running'. | ||
|
Beschreibung
Dieses Attribut zeigt das Ergebnis einer CI/CD Pipeline-Ausführung an, die einem Commit oder Merge Request zugeordnet ist. Gängige Status in GitLab sind 'running', 'pending', 'success', 'failed', 'canceled' und 'skipped'. Diese Daten sind essenziell für das Dashboard 'Rework & Rerun Analysis'. Häufige Pipeline-Fehler können eine erhebliche Quelle für Nacharbeiten und Verzögerungen sein, und die Analyse ihrer Häufigkeit, ihres Standorts und ihrer Auswirkungen ist entscheidend für die Verbesserung der Entwicklungseffizienz und Code-Qualität.
Bedeutung
Verfolgt den Erfolg und Misserfolg automatisierter Builds und Tests, hebt Nacharbeitschleifen sowie Probleme mit der Codequalität oder Testautomatisierung hervor.
Datenquelle
Abgerufen aus dem Feld 'status' in der GitLab CI/CD Pipelines API-Antwort.
Beispiele
successfehlgeschlagenrunningstorniert
|
|||
|
Quellsystem
SourceSystem
|
Identifiziert das System, aus dem die Daten stammen. | ||
|
Beschreibung
Dieses Attribut spezifiziert den Ursprung der Prozessdaten. Für dieses Datenmodell wird der Wert konsistent 'GitLab' sein. Die Aufnahme dieses Attributs ist entscheidend in Umgebungen, in denen Prozessdaten aus mehreren Systemen kombiniert werden können, wie Jira für die Planung und GitLab für die Ausführung. Es ermöglicht das Filtern, die Segmentierung und hilft, die Datenherkunft zu erhalten.
Bedeutung
Gewährleistet Klarheit über die Datenherkunft, was entscheidend ist für die Data Governance und beim Integrieren von Daten aus mehreren Enterprise-Systemen.
Datenquelle
Dies ist ein statischer Wert, 'GitLab', der während des Datentransformationsprozesses hinzugefügt wird.
Beispiele
GitLab
|
|||
|
Release Version
ReleaseVersion
|
Der geplante oder tatsächliche Software Version Tag, der dem Deployment zugeordnet ist. | ||
|
Beschreibung
Dieses Attribut identifiziert die spezifische Software Release, zu der ein Development Item gehört. In GitLab kann dies über einen Milestone, einen geschützten Tag oder einen Eintrag im Releases Feature zugeordnet werden. Dies ist essenziell für das Dashboard 'Release Schedule Adherence Tracking'. Durch den Vergleich des tatsächlichen Deployment-Datums mit einem geplanten Datum, das der Release Version zugeordnet ist, können Organisationen ihre Fähigkeit zur Einhaltung von Zeitplänen messen und die Ursachen von Release-Verzögerungen diagnostizieren.
Bedeutung
Verbindet Development Items mit einem spezifischen Software-Release, was entscheidend ist für die Verfolgung des Release-Fortschritts und die Einhaltung des Zeitplans.
Datenquelle
Dies kann aus GitLab Releases, dem Namen eines Git Tags oder dem Titel eines Milestones bezogen werden, der für die Release-Planung verwendet wird.
Beispiele
v1.2.0v3.0.0-beta2023.4.1
|
|||
|
Teamname
TeamName
|
Das Entwicklungsteam, das dem Projekt oder Assignee zugeordnet ist. | ||
|
Beschreibung
Team Name repräsentiert die Gruppe oder das Squad, das für das Development Item verantwortlich ist. Diese Information ist typischerweise kein Standardfeld in GitLab und wird oft aus Projekt-Namenskonventionen, Gruppenstrukturen oder durch die Zuordnung von Assignees zu ihren jeweiligen Teams mittels einer externen Referenztabelle abgeleitet. Dieses Attribut wird verwendet, um die Prozessperformance auf Teamebene zu analysieren. Es hilft, Effizienz, Workload und Prozesseinhaltung über verschiedene Teams hinweg zu vergleichen und unterstützt Dashboards wie die 'Stage-Specific Bottleneck Analysis' aus einer teambasierten Perspektive.
Bedeutung
Ermöglicht Performance-Analysen und Prozessvergleiche über verschiedene Teams hinweg und hilft so, teamspezifische Bottlenecks oder Best Practices zu identifizieren.
Datenquelle
Oftmals abgeleitet durch die Zuordnung des Project Name oder Assignee zu einer außerhalb von GitLab definierten Teamstruktur oder durch Ableitung aus GitLab-Gruppenhierarchien.
Beispiele
Frontend-AlphaBackend-ServicesPlatform-Infra
|
|||
|
Übergabe-Wartezeit
HandoffWaitTime
|
Berechnete Leerlaufzeit zwischen zwei aufeinanderfolgenden Aktivitäten, die von verschiedenen Assignees durchgeführt wurden. | ||
|
Beschreibung
Diese Metrik berechnet die Dauer der Lücke zwischen dem Abschluss einer Aktivität und dem Beginn der nächsten, insbesondere wenn der Assignee wechselt. Zum Beispiel misst sie die Zeit, von dem Zeitpunkt, an dem ein Developer seine Arbeit beendet, bis ein Reviewer den Code Review beginnt. Dies ist die Schlüsselmetrik für den KPI 'Average Handoff Wait Time'. Sie hilft, versteckte Ineffizienzen in der Ressourcenzuweisung und Kommunikation zwischen Teams oder Einzelpersonen aufzudecken und hebt Verzögerungen hervor, die nicht Teil einer aktiven Arbeit sind.
Bedeutung
Quantifiziert die Leerlaufzeit bei Handoffs zwischen verschiedenen Personen oder Teams und deckt versteckte Verzögerungen und Kommunikations-Bottlenecks auf.
Datenquelle
Berechnet vom Process Mining Tool. Es erfordert die Analyse aufeinanderfolgender Events innerhalb eines Cases, die Überprüfung, ob der 'Assignee' unterschiedlich ist, und dann die Berechnung der Zeitdifferenz.
Beispiele
1 Tag 2 Stunden15 Minuten8 Stunden
|
|||
|
Ziel-Branch
TargetBranch
|
Der Name des Ziel-Branch für einen Merge Request. | ||
|
Beschreibung
Der Target Branch ist der Branch, in den Änderungen gemergt werden sollen, zum Beispiel 'main', 'develop' oder ein Release Branch wie 'release/1.5'. Dies ist eine zentrale Information für jeden Merge Request. Die Analyse nach Target Branch kann unterschiedliche Prozessverhaltensweisen für Code aufzeigen, der in verschiedene Ziele gemergt wird. Zum Beispiel können Merges in 'main' einen rigoroseren Genehmigungsprozess und längere Cycle Times haben als Merges in einen Feature Branch. Sie kann auch helfen, Production Deployments von anderen Arten der Code-Integration zu unterscheiden.
Bedeutung
Hilft bei der Unterscheidung zwischen verschiedenen Development- und Release-Workflows, da Prozesse je nach Ziel-Branch erheblich variieren können.
Datenquelle
Abgerufen aus dem Feld 'target_branch' in der GitLab Merge Requests API-Antwort.
Beispiele
maindeveloprelease/v2.1.0hotfix/user-auth-bug
|
|||
Software Development Lifecycle Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
In Produktion deployed
|
Diese Aktivität markiert das erfolgreiche Deployment des Codes in die Live Production Umgebung und macht ihn für Endnutzer verfügbar. Dies wird erfasst, wenn ein spezifischer 'deploy to production' Job in einer GitLab CI/CD Pipeline erfolgreich abgeschlossen wird. | ||
|
Bedeutung
Dies ist das primäre End-Event für den Prozess, das anzeigt, dass Wert geliefert wurde. Es ist essenziell für die Messung der gesamten End-to-End SDLC Cycle Time und der Release-Frequenz.
Datenquelle
Erfasst aus dem 'finished_at'-Timestamp eines erfolgreichen CI/CD Jobs, der speziell für das Production Deployment vorgesehen ist. GitLab's Environments Feature verfolgt dies explizit.
Erfassen
Verwenden Sie den 'finished_at'
Ereignistyp
explicit
|
|||
|
Merge Request erstellt
|
Zeigt an, dass die initiale Entwicklungsarbeit abgeschlossen ist und der Code bereit für Review und Integration ist. Dies ist ein explizites, zentrales Event im GitLab Workflow, das erfasst wird, wenn ein Entwickler einen neuen Merge Request (MR) öffnet. | ||
|
Bedeutung
Dies ist ein kritischer Milestone, der den Handoff von der Entwicklung zum Review und Testing markiert. Es ist der Einstiegspunkt für die Analyse des gesamten Code Review und CI/CD Pipeline-Zyklus.
Datenquelle
Dies ist ein explizites Event, das vom 'created_at' Timestamp in der Tabelle 'merge_requests' oder über die Merge Requests API erfasst wird.
Erfassen
Verwenden Sie den 'created_at'
Ereignistyp
explicit
|
|||
|
Merge Request gemergt
|
Diese Aktivität kennzeichnet den erfolgreichen Abschluss des Code Review und Integrationsprozesses. Es ist ein explizites Event, das auftritt, wenn ein Benutzer den Branch des Merge Request in den Target Branch mergt. | ||
|
Bedeutung
Dies ist ein wichtiger Milestone, der anzeigt, dass Entwicklung und Review abgeschlossen sind. Er dient als Endpunkt für die Messung der Development Cycle Time und als Startpunkt für die Messung der Deployment Lead Time.
Datenquelle
Dies ist ein explizites Event, das vom 'merged_at' Timestamp in der Tabelle 'merge_requests' erfasst wird. Eine Systemnotiz wird ebenfalls beim Merging generiert.
Erfassen
Verwenden Sie den 'merged_at'
Ereignistyp
explicit
|
|||
|
Problem erstellt
|
Diese Aktivität markiert den Beginn des Development Lifecycle und repräsentiert die Erstellung eines neuen Work Items, wie eines Feature, Bug oder Task. Sie wird explizit erfasst, wenn ein Benutzer ein neues Issue in GitLab erstellt, welches den Creation Timestamp aufzeichnet. | ||
|
Bedeutung
Dies ist das primäre Start-Event für den End-to-End-Prozess. Die Analyse der Zeit von der Issue-Erstellung bis zum Deployment bietet ein vollständiges Bild der SDLC Cycle Time.
Datenquelle
Dies ist ein explizites Event, das vom 'created_at' Timestamp in der Tabelle 'issues' oder über die Issues API erfasst wird. Systemnotizen zeichnen das Creation Event ebenfalls auf.
Erfassen
Verwenden Sie den 'created_at'
Ereignistyp
explicit
|
|||
|
Code Review gestartet
|
Markiert den Beginn des Peer Review Prozesses für einen Merge Request. Dieses Event wird aus der ersten Review-bezogenen Aktion abgeleitet, wie dem ersten Kommentar oder Thread, der von einer anderen Person als dem Autor gepostet wurde. | ||
|
Bedeutung
Das Messen der Zeit von der MR-Erstellung bis zum Beginn des Reviews hebt Warteschlangenverzögerungen hervor. Die Reduzierung dieser Wartezeit ist entscheidend für die Verkürzung des gesamten Code Review Zyklus.
Datenquelle
Abgeleitet vom Timestamp des ersten Kommentars oder Review-Threads zum Merge Request, der nicht vom MR-Autor stammt. Diese Daten sind über Systemnotizen oder die Notes API verfügbar.
Erfassen
Finden Sie den Timestamp des ersten Nutzerkommentars zu einem MR von einem Nicht-Autor.
Ereignistyp
inferred
|
|||
|
Deployment gestartet
|
Stellt den Beginn des Prozesses dar, Code in eine spezifische Umgebung, wie Staging oder Production, freizugeben. In GitLab entspricht dies dem Start eines 'deploy'-Jobs innerhalb einer CI/CD Pipeline. | ||
|
Bedeutung
Das Tracking des Deployment-Starts hilft, die Dauer der Deployment-Phase zu isolieren. Es ist entscheidend für die Messung und Optimierung der Deployment Lead Time.
Datenquelle
Erfasst aus dem 'started_at'-Timestamp eines CI/CD Jobs, der als Deployment Job konfiguriert ist. Dies ist Teil von GitLab's Environments und Deployments Feature.
Erfassen
Verwenden Sie den 'started_at'
Ereignistyp
explicit
|
|||
|
Entwicklung gestartet
|
Diese Aktivität kennzeichnet den Beginn der aktiven Coding-Arbeit an dem Issue. Dies wird typischerweise vom ersten Code Commit abgeleitet, der an einen mit dem Issue verbundenen Branch gepusht wird, da GitLab keinen expliziten 'start development'-Button hat. | ||
|
Bedeutung
Identifiziert den genauen Beginn der wertschöpfenden Entwicklungsarbeit, was eine präzise Messung der reinen Coding-Phase ermöglicht und diese von Planungs- oder Wartezeiten trennt.
Datenquelle
Abgeleitet durch den Timestamp des ersten Commits auf einem Feature Branch, der mit dem Issue verknüpft ist. Dies erfordert die Verknüpfung von Issues mit Branches, oft über Namenskonventionen oder Metadaten.
Erfassen
Finden Sie den Timestamp des ersten Commits auf einem Branch, der mit der Issue ID verknüpft ist.
Ereignistyp
inferred
|
|||
|
Genehmigung hinzugefügt
|
Stellt eine formelle Genehmigung der Code-Änderungen in einem Merge Request durch einen Reviewer dar. Dies ist ein explizites Event, das von GitLab erfasst wird, wenn ein Benutzer auf den 'Approve'-Button klickt. | ||
|
Bedeutung
Genehmigungen sind zentrale Quality Gates. Ihre Verfolgung hilft, die benötigte Zeit für erforderliche Freigaben zu analysieren und stellt die Einhaltung der Review-Richtlinien sicher.
Datenquelle
Erfasst aus Merge Request Approval Events. Diese sind über die Approvals API verfügbar oder können in der Historie der MR eingesehen werden.
Erfassen
Verwenden Sie den
Ereignistyp
explicit
|
|||
|
Pipeline fehlgeschlagen
|
Diese Aktivität tritt auf, wenn eine CI/CD Pipeline-Ausführung in irgendeiner Phase fehlschlägt, z.B. bei einem Build Error oder einem fehlgeschlagenen Test. GitLab zeichnet explizit den finalen Status jeder Pipeline auf, wodurch Fehler leicht zu identifizieren sind. | ||
|
Bedeutung
Pipeline-Fehler sind ein Haupttreiber für Nacharbeiten. Die Analyse ihrer Häufigkeit, Dauer und Ursache hilft, Qualitätsprobleme, instabile Tests und Bottlenecks in der Feedback-Schleife zu Entwicklern zu identifizieren.
Datenquelle
Identifiziert durch den Status 'failed' in einem Pipeline-Datensatz in der Tabelle 'ci_pipelines'. Der 'finished_at' Timestamp gibt an, wann der Fehler aufgetreten ist.
Erfassen
Filtern Sie nach Pipeline-Datensätzen mit dem Status 'failed' und verwenden Sie den 'finished_at' Timestamp.
Ereignistyp
explicit
|
|||
|
Pipeline gestartet
|
Stellt die Initiierung einer automatisierten CI/CD Pipeline dar, die typischerweise Builds, Tests und Security Scans durchführt. GitLab erstellt explizit einen Pipeline-Datensatz mit einem Start-Timestamp, wann immer eine Pipeline ausgelöst wird, zum Beispiel durch einen Commit oder die MR-Erstellung. | ||
|
Bedeutung
Das Tracking von Pipeline-Ausführungen ist essenziell für die Überwachung der Gesundheit und Effizienz automatisierter Testing- und Integrationsprozesse. Es hilft zu identifizieren, wie viel Zeit in der automatisierten Validierung verbracht wird.
Datenquelle
Erfasst aus dem 'created_at'- oder 'started_at'-Timestamp eines Pipeline-Datensatzes in der 'ci_pipelines'-Tabelle oder über die Pipelines API.
Erfassen
Verwenden Sie den
Ereignistyp
explicit
|
|||
|
Sachverhalt abgeschlossen
|
Stellt den finalen administrativen Abschluss des Work Items dar, typischerweise nachdem seine Änderungen deployed und verifiziert wurden. Dies ist ein explizites Event, das erfasst wird, wenn ein Benutzer das Issue in GitLab schließt. | ||
|
Bedeutung
Das Schließen eines Issues bedeutet oft das endgültige Ende aller damit verbundenen Arbeiten. Der Vergleich mit der Bereitstellungszeit kann Verzögerungen bei der Post-Deployment-Validierung oder administrativen Prozessen aufdecken.
Datenquelle
Dies ist ein explizites Event, das vom 'closed_at' Timestamp in der Tabelle 'issues' oder aus der entsprechenden Systemnotiz erfasst wird.
Erfassen
Verwenden Sie den 'closed_at'
Ereignistyp
explicit
|
|||
|
Sachverhalt zugewiesen
|
Stellt die Zuweisung eines Issue an einen spezifischen Developer oder ein Team dar und zeigt an, dass die Verantwortung für die Arbeit festgelegt wurde. Dies ist ein explizites Event, das von GitLab protokolliert wird, sobald das Assignee-Feld eines Issues ausgefüllt oder geändert wird. | ||
|
Bedeutung
Das Tracking von Zuweisungen ist entscheidend für die Analyse von Ressourcenzuweisung, Team Workload und Handoff-Zeiten. Es hilft, Verzögerungen zwischen der Erstellung und der Übernahme von Arbeit zu identifizieren.
Datenquelle
Erfasst aus GitLab's System Notes für den Issue, die protokollieren, wann ein 'Assignee' hinzugefügt oder geändert wird. Der Event Timestamp wird in der Notiz aufgezeichnet.
Erfassen
Extrahieren Sie 'Assignee Changed'-Events aus den System Notes des Issues.
Ereignistyp
explicit
|
|||