Ihr Software Development Life Cycle (SDLC) Daten-Template
Ihr Software Development Life Cycle (SDLC) Daten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten für das Tracking
- Extraktionsanleitung
Software Development Life Cycle (SDLC) Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
`Development Item`
DevelopmentItem
|
Der eindeutige Identifikator für eine Arbeitseinheit, wie ein Funktion, Bug Fix oder Aufgabe, der als primärer Case-ID dient. | ||
|
Beschreibung
Das Development Item repräsentiert eine einzelne, verfolgbare Arbeitseinheit, die den Software Development Life Cycle (SDLC) durchläuft. Es verbindet alle zugehörigen Aktivitäten, von der Erstellung bis zum finalen Deployment, zu einem kohärenten Fall. In GitLab wird dies in der Regel 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 Durchlaufzeit, die Identifizierung von Engpässe 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-ID, der alle Process Ereignisse miteinander verknüpft und es so ermöglicht, den gesamten Lebenszyklus jedes beliebigen Work Items nachzuvollziehen.
Datenquelle
Dies ist in der Regel die interne ID (IID) eines GitLab Issue. Sie kann in der Issues API-Antwort als 'iid'-Feld gefunden werden.
Beispiele
1024512PRJ-2345
|
|||
|
Aktivität
Activity
|
Der Name des spezifischen Prozessschritts oder Ereignisse, das aufgetreten ist, wie 'Issue Created' oder 'Merge Request Merged'. | ||
|
Beschreibung
Das Attribut Activity erfasst die einzelnen Ereignisse, die ein Development Item durchläuft. Diese sind in GitLab nicht als einzelnes Feld gespeichert, sondern werden aus verschiedenen Aktionen und Zeitstempel-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 den Antrag bearbeitet.ie Genehmigung eines Merge Request allesamt separate Aktivitäten. Dieses Attribut ist die Basis für den Aufbau der Prozessdarstellung (Process Map), die Visualisierung des Workflows und die Analyse der Sequenz und Häufigkeit von Ereignisse. Es wird verwendet, um Abweichungen, Engpässe zwischen Schritten und gängige Prozesspfade zu identifizieren.
Bedeutung
Es definiert die Schritte in der Prozessdarstellung (Process Map) und ermöglicht die Visualisierung und Analyse des End-to-End Development Workflows.
Datenquelle
Abgeleitet von Event-Typn und State Changes im GitLab Event Stream oder den Antrag bearbeitet.urch die Interpretation von Zeitstempel-Feldern wie 'created_at', 'merged_at' und 'closed_at' bei Issues und Merge Requests.
Beispiele
Problem erstelltEntwicklung gestartetMerge Request gemergtPipeline fehlgeschlagenIn Produktion bereitgestellt
|
|||
|
Startzeit
StartTime
|
Der `Zeitstempel`, 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 Ereignisse in GitLab wird dies in verschiedenen Zeitstempel-Feldern erfasst. Zum Beispiel wäre die StartTime der Aktivität 'Issue Created' der Dieser Zeitstempel ist das zentrale zeitliche Element im Process Mining. Er wird verwendet, um Ereignisse chronologisch zu ordnen, Zeitspannen zwischen Aktivitäten zu berechnen, Durchlaufzeits zu messen und die Prozess-Performance über die Zeit zu analysierenn.
Bedeutung
Dieses Attribut liefert die chronologische Sequenz von Ereignisse, die essenziell für die Berechnung aller zeitbasierten Metriken und das Verständnis des Prozessfluss ist.
Datenquelle
Extrahiert aus verschiedenen Zeitstempel-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 den Antrag bearbeitet.em Issue oder Merge Request zum Zeitpunkt des Ereignisse 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 maßgeblich für das Dashboard 'Developer Workload & Allocation'. Sie hilft, die Ressourcenauslastung zu verstehen, überlastete Einzelpersonen oder Teams zu identifizieren und Übergaben zwischen verschiedenen Personen zu analysierenn.
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
|
|||
|
Development-Item-Typ
DevelopmentItemType
|
Die Klassifizierung des Development Items, wie 'Funktion', 'Bug', 'Aufgabe' 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, Fehlerbehebung, technische Schulden und anderen Work Typs zu unterscheiden. Die Analyse nach Development Item Typ ermöglicht den Vergleich von Prozessflusss und Durchlaufzeits 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 Typ hilft zu identifizieren, ob bestimmte Arten von Arbeit anfälliger für Verzögerungen, Nacharbeiten oder Abweichungen sind.
Datenquelle
Wird in der Regel von den 'Labels' eines GitLab
Beispiele
`Funktion`BugAufgabeTechnische Schulden
|
|||
|
Endzeit
EndTime
|
Der Zeitstempel, 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 Ereignisse 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-Zeitstempel 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 (Bearbeitungszeit). Es hilft bei der den Antrag bearbeitet.etaillierten 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 (Bearbeitungszeiten), was wichtig ist, um ineffiziente Schritte im Prozess zu identifizieren.
Datenquelle
Bei atomaren Ereignisse ist dies identisch mit StartTime. Für dauerhafte Aktivitäten muss es durch das Auffinden eines entsprechenden Abschluss-Ereignisse in den Daten abgeleitet werden.
Beispiele
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Projektname
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 Leistungsfähigkeit-Vergleiche über verschiedene Produkte, Komponenten oder Dienste 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 vereinfacht.
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, in der Regel 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 wichtig für das Dashboard 'Severity Escalation Trends' und den zugehörigen KPI. Die Analyse von Severity-Änderungen über den Lebenszyklus 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
|
|||
|
Dev Item Status
DevelopmentItemStatus
|
Der Status des Development Items zum Zeitpunkt des Ereignisse, wie 'Open', 'In Progress' oder 'Closed'. | ||
|
Beschreibung
Dieses Attribut reflektiert den Status des primären Work Items, in der Regel eines Issue in GitLab. GitLab Issues haben einen Das Tracking von Statusänderungen ist maßgeblich für das Verständnis des Case Lebenszyklus. Es hilft zu identifizieren, wie lange Elemente in jedem Status verbleiben, und kann verwendet werden, um in Dashboards wie 'SDLC End-to-End Durchlaufzeit' nach aktiver oder abgeschlossener Arbeit zu filtern.
Bedeutung
Bietet einen Momentaufnahme 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 Durchlaufzeit ist eine berechnete Metrik, die die Gesamtdauer eines Fälle misst. Sie wird in der Regel 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 Durchlaufzeit' und wird verwendet, um Verbesserungen zu verfolgen und langwierige Fälle zu identifizieren, die auf systemische Probleme hinweisen können.
Bedeutung
Dies ist ein zentraler Process Mining KPI, der den Antrag bearbeitet.ie End-to-End-Effizienz des Development Lebenszyklus 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 in der Regel 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 vereinfacht.
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
JaNein
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Zeitstempel, 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 den Antrag bearbeitet.ie Event-Daten zuletzt im Process Mining Datenset extrahiert oder aktualisiert wurden. Es repräsentiert nicht den Zeitpunkt des Ereignisse, sondern den Zeitpunkt der letzten Synchronisierung des Event-Datensatzes. Diese Information ist maßgeblich 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 Hinweisrmiert 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 Hinweisrmiert sind.
Datenquelle
Dieser Zeitstempel 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-Leistungsfähigkeit im Kontext spezifischer Sprints oder Planungsperioden. Es kann verwendet werden, um zu sehen, ob sich die Durchlaufzeits 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 Leistungsfähigkeit 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 den Antrag bearbeitet.em Event zugeordnet ist, wie 'Opened', 'Merged' oder 'Closed'. | ||
|
Beschreibung
Dieses Attribut erfasst den Status eines Merge Request (MR) zum Zeitpunkt eines Ereignisse. GitLab MRs haben verschiedene Status: 'opened', 'closed', 'merged' oder 'locked'. Dies ist vom allgemeinen Development Item Status getrennt. Das Tracking des MR-Status ist maßgeblich für die Analyse der Code-Integrationsphase des SDLC. Es unterstützt Dashboards wie 'Code Review Durchlaufzeit & 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 maßgeblich für die Verbesserung der Entwicklungseffizienz und Code-Qualität.
Bedeutung
Verfolgt den Erfolg und Misserfolg automatisierter Builds und Tests, hebt Nacharbeitsschleifen 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 maßgeblich 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 wichtig ist für die Daten 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 den Antrag bearbeitet.em 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 Funktion zugeordnet werden. Dies ist wichtig 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 wichtig 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 den Antrag bearbeitet.em 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 den Antrag bearbeitet.as Squad, das für das Development Item verantwortlich ist. Diese Information ist in der Regel kein Standardfeld in GitLab und wird oft aus Projekt-Namenskonventionen, Gruppenstrukturen oder den Antrag bearbeitet.urch die Zuordnung von Assignees zu ihren jeweiligen Teams mittels einer externen Referenztabelle abgeleitet. Dieses Attribut wird verwendet, um die Prozess-Performance auf Teamebene zu analysierenn. 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 Leistungsfähigkeit-Analysen und Prozessvergleiche über verschiedene Teams hinweg und hilft so, teamspezifische Engpässe 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 den Antrag bearbeitet.urch Ableitung aus GitLab-Gruppenhierarchien.
Beispiele
Frontend-AlphaBackend-DienstePlatform-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 Übergaben zwischen verschiedenen Personen oder Teams und deckt versteckte Verzögerungen und Kommunikations-Engpässe auf.
Datenquelle
Berechnet vom Process-Mining-Tool. Es erfordert die Analyse aufeinanderfolgender Ereignisse innerhalb eines Fälle, 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 Durchlaufzeits haben als Merges in einen Funktion 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 Life Cycle (SDLC) Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
In Produktion bereitgestellt
|
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 wichtig für die Messung der gesamten End-to-End SDLC Durchlaufzeit und der Release-Frequenz.
Datenquelle
Erfasst aus dem 'finished_at'-Zeitstempel eines erfolgreichen CI/CD Jobs, der speziell für das Production Deployment vorgesehen ist. GitLab's Environments Funktion 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 Antrag bearbeitet.en 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' Zeitstempel 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 Durchlaufzeit und als Startpunkt für die Messung der Deployment Lead Time.
Datenquelle
Dies ist ein explizites Event, das vom 'merged_at' Zeitstempel 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 Lebenszyklus und repräsentiert die Erstellung eines neuen Work Items, wie eines Funktion, Bug oder Aufgabe. Sie wird explizit erfasst, wenn ein Benutzer ein neues Issue in GitLab erstellt, welches den Creation Zeitstempel 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 Durchlaufzeit.
Datenquelle
Dies ist ein explizites Event, das vom 'created_at' Zeitstempel 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 maßgeblich für die Verkürzung des gesamten Code Review Zyklus.
Datenquelle
Abgeleitet vom Zeitstempel des ersten Kommentars oder Review-Threads zum Merge Request, der nicht vom MR-Autor stammt. Diese Daten sind über Systemnotizen oder den Antrag bearbeitet.ie Notes API verfügbar.
Erfassen
Finden Sie den Zeitstempel 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 maßgeblich für die Messung und Optimierung der Deployment Lead Time.
Datenquelle
Erfasst aus dem 'started_at'-Zeitstempel eines CI/CD Jobs, der als Deployment Job konfiguriert ist. Dies ist Teil von GitLab's Environments und Deployments Funktion.
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 in der Regel 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 Zeitstempel des ersten Commits auf einem Funktion 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 Zeitstempel des ersten Commits auf einem Branch, der mit der Issue ID verknüpft ist.
Ereignistyp
inferred
|
|||
|
Freigabe 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 analysierenn und stellt die Einhaltung der Review-Richtlinien sicher.
Datenquelle
Erfasst aus Merge Request Approval Ereignisse. 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 Fehler oder einem fehlgeschlagenen Test. GitLab zeichnet explizit den finalen Status jeder Pipeline auf, wodurch Fehler leicht zu identifizieren sind. | ||
|
Bedeutung
Pipeline-Fehler sind ein zentrale Faktor für Nacharbeiten. Die Analyse ihrer Häufigkeit, Dauer und Ursache hilft, Qualitätsprobleme, instabile Tests und Engpässe 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' Zeitstempel gibt an, wann der Fehler aufgetreten ist.
Erfassen
Filtern Sie nach Pipeline-Datensätzen mit dem Status 'failed' und verwenden Sie den 'finished_at' Zeitstempel.
Ereignistyp
explicit
|
|||
|
Pipeline gestartet
|
Stellt die Initiierung einer automatisierten CI/CD Pipeline dar, die in der Regel Builds, Tests und Security Scans durchführt. GitLab erstellt explizit einen Pipeline-Datensatz mit einem Start-Zeitstempel, wann immer eine Pipeline ausgelöst wird, zum Beispiel durch einen Commit oder den Antrag bearbeitet.ie MR-Erstellung. | ||
|
Bedeutung
Das Tracking von Pipeline-Ausführungen ist wichtig 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'-Zeitstempel 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, in der Regel 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' Zeitstempel 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 maßgeblich 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 Zeitstempel wird in der Notiz aufgezeichnet.
Erfassen
Extrahieren Sie 'Assignee Changed'-Ereignisse aus den System Notes des Issues.
Ereignistyp
explicit
|
|||