Ihr Daten-Template für den Softwareentwicklungslebenszyklus

GitLab
Ihr Daten-Template für den Softwareentwicklungslebenszyklus

Ihr Daten-Template für den Softwareentwicklungslebenszyklus

Dieses umfassende Template führt Sie durch die wichtigsten Datenpunkte für die Analyse Ihres Softwareentwicklungslebenszyklus. Es zeigt, welche zentralen Attribute Sie erfassen und welche Aktivitäten Sie verfolgen sollten. Außerdem enthält es praktische Hinweise dazu, wie Sie diese Informationen direkt aus GitLab extrahieren. Damit können Sie Ihre Daten gezielt für aussagekräftiges Process Mining vorbereiten.
  • Empfohlene Attribute für die Datenerfassung
  • Wichtige Aktivitäten für die Nachverfolgung
  • Anleitung zur Datenextraktion
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute des Softwareentwicklungslebenszyklus

Dies sind die empfohlenen Datenfelder für Ihr Event Log, damit Sie den Softwareentwicklungslebenszyklus umfassend analysieren und optimieren können.
3 Erforderlich 5 Empfohlen 12 Optional
Name Beschreibung
Aktivität
Activity
Die Bezeichnung des konkreten Prozessschritts oder Ereignisses, etwa „Issue erstellt“ oder „Merge Request zusammengeführt“.
Beschreibung

Das Attribut Aktivität erfasst die einzelnen Ereignisse, die bei einem Entwicklungselement auftreten. In GitLab sind diese nicht in einem einzelnen Feld gespeichert, sondern werden aus verschiedenen Aktionen und Timestamp-Feldern in Issues, Merge Requests und CI/CD-Pipelines abgeleitet. Dazu zählen beispielsweise das Erstellen eines Issues, das Übertragen eines Commits, das Fehlschlagen einer Pipeline oder die Freigabe eines Merge Requests.

Dieses Attribut ist grundlegend für den Aufbau der Prozesslandkarte, die Visualisierung des Workflows und die Analyse der Reihenfolge und Häufigkeit von Ereignissen. Es dient dazu, Abweichungen, Engpässe zwischen Prozessschritten und häufige Prozessabläufe zu erkennen.

Warum das wichtig ist

Das Attribut legt die Schritte in der Prozesslandkarte fest und ermöglicht so die Visualisierung und Analyse des Entwicklungs-Workflows von Anfang bis Ende.

Woher beziehen

Abgeleitet aus Ereignistypen und Statusänderungen im GitLab-Ereignisstrom oder durch Auswertung von Timestamp-Feldern wie created_at, merged_at und closed_at in Issues und Merge Requests.

Beispiele
Issue erstelltEntwicklung begonnenMerge Request zusammengeführtPipeline fehlgeschlagenIn Produktion bereitgestellt
Entwicklungselement
DevelopmentItem
Der eindeutige Bezeichner einer Arbeitseinheit, etwa einer Funktion, Fehlerbehebung oder Aufgabe. Er dient als primäre Case-ID.
Beschreibung

Das Entwicklungselement steht für eine einzelne, nachverfolgbare Arbeitseinheit, die den Softwareentwicklungslebenszyklus durchläuft. Es verknüpft alle zugehörigen Aktivitäten von der Erstellung bis zur endgültigen Bereitstellung zu einem zusammenhängenden Case. In GitLab wird es üblicherweise durch die interne ID (IID) des Issues dargestellt, die innerhalb eines Projekts eindeutig ist.

Die Analyse nach Entwicklungselement ermöglicht die Messung der Zykluszeit von Anfang bis Ende, die Ermittlung von Engpässen und die Konformitätsprüfung. Sie bildet die Grundlage dafür, zu verstehen, wie effizient Arbeit vom Konzept bis zur Produktion bereitgestellt wird.

Warum das wichtig ist

Dies ist die erforderliche Case-ID, die alle Prozessereignisse miteinander verknüpft. So lässt sich der gesamte Lebenszyklus eines Arbeitselements nachvollziehen.

Woher beziehen

Dabei handelt es sich üblicherweise um die interne ID (IID) eines GitLab-Issues. Sie ist in der Antwort der Issues API im Feld iid zu finden.

Beispiele
1024512PRJ-2345
Startzeit
StartTime
Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis begonnen hat.
Beschreibung

StartTime bezeichnet das genaue Datum und die Uhrzeit, zu der eine bestimmte Aktivität stattgefunden hat. Bei Ereignissen in GitLab wird dieser Wert in verschiedenen Timestamp-Feldern erfasst. Für die Aktivität „Issue erstellt“ ist StartTime beispielsweise der Timestamp created_at des Issues. Bei „Merge Request zusammengeführt“ entspricht StartTime dem Timestamp merged_at des Merge Requests.

Dieser Timestamp ist die zentrale Zeitangabe im Process Mining. Er dient dazu, Ereignisse chronologisch zu ordnen, Zeitspannen zwischen Aktivitäten zu berechnen, Zykluszeiten zu messen und die Prozessleistung im Zeitverlauf zu analysieren.

Warum das wichtig ist

Dieses Attribut gibt die chronologische Reihenfolge der Ereignisse an. Das ist entscheidend, um alle zeitbasierten Kennzahlen zu berechnen und den Prozessablauf zu verstehen.

Woher beziehen

Extrahiert aus verschiedenen Timestamp-Feldern in GitLab, etwa created_at, updated_at und closed_at bei Issues sowie merged_at bei Merge Requests.

Beispiele
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
Endzeit
EndTime
Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis abgeschlossen wurde.
Beschreibung

EndTime bezeichnet das genaue Datum und die Uhrzeit, zu der eine Aktivität abgeschlossen wurde. Bei vielen einzelnen Ereignissen in GitLab, etwa „Issue erstellt“, entspricht EndTime der StartTime. Bei Aktivitäten mit einer Dauer, etwa einem Code-Review, gibt EndTime den Abschlusszeitpunkt an, zum Beispiel den Zeitpunkt der letzten Freigabe.

Dieses Attribut ist wichtig, um die Dauer einzelner Aktivitäten (Verarbeitungszeit) präzise zu berechnen. Es unterstützt eine detaillierte Engpassanalyse, indem es die aktive Bearbeitungszeit einer Aufgabe von der Wartezeit zwischen Aufgaben unterscheidet.

Warum das wichtig ist

Ermöglicht die präzise Berechnung der Aktivitätsdauer (Verarbeitungszeit), die entscheidend ist, um ineffiziente Prozessschritte zu erkennen.

Woher beziehen

Bei einzelnen Ereignissen entspricht dieser Wert der StartTime. Bei Aktivitäten mit einer Dauer muss er anhand eines passenden Abschlussereignisses 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 Entwicklungselement gehört.
Beschreibung

Dieses Attribut identifiziert das Code-Repository oder Projekt, in dem die Arbeit ausgeführt wird. In GitLab gehört jedes Issue und jeder Merge Request zu einem Projekt.

Die Analyse nach Projektname ermöglicht Leistungsvergleiche zwischen verschiedenen Produkten, Komponenten oder Services. Sie kann zeigen, ob die SDLC-Prozesse bestimmter Projekte besser funktionieren als andere. Außerdem lassen sich Dashboards auf einen bestimmten Bereich eingrenzen.

Warum das wichtig ist

Ermöglicht die Segmentierung der Prozessanalyse nach Produkt, Anwendung oder Komponente und unterstützt so gezielte Verbesserungsmaßnahmen.

Woher beziehen

Abgerufen aus den Feldern name oder path_with_namespace der Projects API und über project_id mit Issues und Merge Requests verknüpft.

Beispiele
platform/api-gatewayfrontend/customer-portalmobile/ios-app
Schweregrad
Severity
Der Schweregrad des Entwicklungselements, üblicherweise bei Fehlern oder Vorfällen.
Beschreibung

Der Schweregrad gibt die Auswirkungen eines Fehlers oder Problems an und reicht von kritisch bis geringfügig. GitLab bietet kein eigenes Feld für den Schweregrad. Daher wird dieser fast immer über Labels abgebildet, etwa severity::1 oder severity::2.

Dieses Attribut ist wichtig für das Dashboard „Trends bei Eskalationen des Schweregrads“ und die zugehörige Kennzahl. Die Analyse von Änderungen des Schweregrads im Lebenszyklus kann Probleme aufdecken, deren Auswirkungen zunächst unterschätzt wurden, oder Prozesse, die Probleme verschärfen.

Warum das wichtig ist

Hilft dabei, Arbeit zu priorisieren und zu analysieren, ob Elemente mit hohem Schweregrad schneller bearbeitet werden. Die Erfassung von Änderungen unterstützt die Kennzahl „Häufigkeit von Eskalationen des Schweregrads“.

Woher beziehen

Abgeleitet aus den Labels eines GitLab-Issues. Eine Zuordnung ist erforderlich, um Labels wie S1 und S2 als Schweregrade zu interpretieren.

Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
Typ des Entwicklungselements
DevelopmentItemType
Die Klassifizierung des Entwicklungselements, etwa „Funktion“, „Fehler“, „Aufgabe“ oder „Wartung“.
Beschreibung

Dieses Attribut kategorisiert die Art der ausgeführten Arbeit. In GitLab wird es üblicherweise über Labels an einem Issue umgesetzt. Teams verwenden Labels, um neue Funktionen, Fehlerbehebungen, technische Schulden und andere Arbeitsarten zu unterscheiden.

Die Analyse nach Typ des Entwicklungselements ermöglicht den Vergleich von Prozessabläufen und Zykluszeiten für verschiedene Arbeitsarten. So lässt sich beispielsweise untersuchen, ob Fehler schneller behoben werden als Funktionen entwickelt werden oder ob Aufgaben zu technischen Schulden einem anderen Prüfprozess folgen.

Warum das wichtig ist

Die Segmentierung des Prozesses nach Arbeitsart hilft zu erkennen, ob bestimmte Arbeiten häufiger zu Verzögerungen, Nacharbeit oder Abweichungen führen.

Woher beziehen

Üblicherweise abgeleitet aus den Labels eines GitLab-Issues. Eine Zuordnungslogik ist erforderlich, um bestimmte Labels in standardisierte Typen zu überführen.

Beispiele
FunktionFehlerAufgabeTechnische Schulden
Zuständige Person
Assignee
Der Benutzer, dem das Issue oder der Merge Request zum Zeitpunkt des Ereignisses zugewiesen ist.
Beschreibung

Die zuständige Person ist der Entwickler oder Benutzer, der zu einem bestimmten Zeitpunkt im Prozess für das Arbeitselement verantwortlich ist. In GitLab wird dies im Feld assignee oder assignees eines Issues oder Merge Requests erfasst.

Die Analyse nach zuständiger Person ist entscheidend für das Dashboard „Arbeitslast und Ressourcenverteilung der Entwickler“. Sie hilft, die Ressourcenauslastung zu verstehen, überlastete Einzelpersonen oder Teams zu erkennen und Übergaben zwischen verschiedenen Personen zu analysieren.

Warum das wichtig ist

Erfasst, wer die Arbeit ausgeführt hat. Das ermöglicht die Analyse der Arbeitslast und der Effizienz der Ressourcenverteilung sowie die Ermittlung von Verzögerungen durch Übergaben.

Woher beziehen

Abgerufen aus den Feldern assignee.username oder assignees in den Antworten der GitLab-Issues- und Merge-Requests-APIs.

Beispiele
jdoeasmithr.williams
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp, der angibt, wann die Daten zu diesem Ereignis zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung

Dieses Attribut erfasst Datum und Uhrzeit, zu denen die Ereignisdaten zuletzt extrahiert oder im Process-Mining-Datensatz aktualisiert wurden. Es gibt nicht an, wann das Ereignis stattgefunden hat, sondern wann der Ereignisdatensatz zuletzt synchronisiert wurde.

Diese Information ist wichtig, um die Aktualität der Daten einzuschätzen und zu prüfen, ob die Prozessanalyse zeitnah erfolgt. Sie hilft Benutzern darauf zu vertrauen, dass Dashboards und Kennzahlen auf aktuellen Daten beruhen, und macht mögliche Verzögerungen zwischen Quellsystem und Analyse sichtbar.

Warum das wichtig ist

Macht die Aktualität der Daten transparent, damit Benutzer wissen, wie aktuell die Prozessanalyse ist.

Woher beziehen

Dieser Timestamp wird vom Datenextraktionstool oder ETL-Prozess bei der Datenaktualisierung erzeugt und gespeichert.

Beispiele
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Meilenstein-Titel
MilestoneTitle
Der Titel des Meilensteins oder Sprints, dem das Entwicklungselement zugeordnet ist.
Beschreibung

Ein Meilenstein in GitLab dient dazu, Arbeit an einem bestimmten Ziel oder innerhalb eines festgelegten Zeitraums zu verfolgen, etwa an einem Sprint oder einer Release-Version. Dieses Attribut erfasst den Namen oder Titel des Meilensteins.

Damit lässt sich die Prozessleistung im Kontext bestimmter Sprints oder Planungszeiträume analysieren. Sie können beispielsweise prüfen, ob sich die Zykluszeiten von Sprint zu Sprint verbessern, oder die Prozessansicht auf Arbeiten für ein bevorstehendes Release beschränken.

Warum das wichtig ist

Ordnet Entwicklungsarbeiten Planungszyklen wie Sprints oder Releases zu und ermöglicht so den Abgleich der Leistung mit geplanten Zeiträumen.

Woher beziehen

Wird aus dem Feld „milestone.title“ der Antworten der GitLab-Issues- oder Merge-Requests-API abgerufen.

Beispiele
Release für Q4 2023Sprint 23.11Phase 1: MVP
Merge-Request-Status
MergeRequestStatus
Der Status des zugehörigen Merge Requests, zum Beispiel „Opened“, „Merged“ oder „Closed“.
Beschreibung

Dieses Attribut erfasst den Status eines Merge Requests (MR) zum Zeitpunkt eines Ereignisses. GitLab-MRs haben die Status „opened“, „closed“, „merged“ oder „locked“. Dieser Status ist unabhängig vom Gesamtstatus des Entwicklungselements.

Der MR-Status ist entscheidend für die Analyse der Code-Integration im SDLC. Er unterstützt direkt Dashboards wie „Zykluszeit und Durchsatz bei Code Reviews“ und hilft, Verzögerungen zwischen dem Erstellen, Prüfen, Freigeben und Zusammenführen eines MR zu erkennen.

Warum das wichtig ist

Macht den Code-Review- und Merge-Prozess sichtbar, der im SDLC häufig einen kritischen Engpass darstellt.

Woher beziehen

Wird aus dem Feld „state“ der Antwort der GitLab-Merge-Requests-API abgerufen.

Beispiele
offenmergedgeschlossenlocked
Nacharbeit
IsRework
Ein boolesches Kennzeichen, das angibt, ob eine Aktivität Teil einer Nacharbeitsschleife ist.
Beschreibung

Dieses berechnete Attribut kennzeichnet Aktivitäten, die einen Rückschritt im Prozess darstellen, etwa wenn nach Beginn der Tests erneut Entwicklungsarbeit anfällt. Die Kennzeichnung basiert in der Regel auf der Erkennung bestimmter Aktivitätsfolgen. Ein Beispiel: Für denselben Case tritt „Entwicklung gestartet“ nach „Pipeline fehlgeschlagen“ oder „QA-Tests gestartet“ auf.

Dieses Attribut bildet die Grundlage für das Dashboard „Analyse von Nacharbeit und erneuten Pipeline-Ausführungen“ sowie die KPI „Nacharbeitsquote nach dem Testen“. Damit lässt sich Nacharbeit einfach filtern und quantifizieren. Teams können so Häufigkeit, Ursachen und Auswirkungen auf Projektzeitpläne besser verstehen.

Warum das wichtig ist

Kennzeichnet und quantifiziert Nacharbeit direkt. So lassen sich Ursachen und Auswirkungen ineffizienter Abläufe und Qualitätsprobleme leichter analysieren.

Woher beziehen

Das Process-Mining-Tool berechnet die Kennzahl, indem es die Aktivitätsfolge jedes Cases analysiert und Muster erkennt, die auf Nacharbeit hindeuten.

Beispiele
truefalse
Pipeline-Status
PipelineStatus
Der Status der CI/CD-Pipeline-Ausführung, zum Beispiel „Success“, „Failed“ oder „Running“.
Beschreibung

Dieses Attribut gibt das Ergebnis einer CI/CD-Pipeline-Ausführung an, die einem Commit oder Merge Request zugeordnet ist. Zu den gängigen Statuswerten in GitLab gehören „running“, „pending“, „success“, „failed“, „canceled“ und „skipped“.

Diese Daten sind für das Dashboard „Analyse von Nacharbeit und erneuten Pipeline-Ausführungen“ unverzichtbar. Häufige Pipeline-Fehler können erhebliche Nacharbeit und Verzögerungen verursachen. Um die Entwicklungseffizienz und Codequalität zu verbessern, müssen Häufigkeit, Auftreten und Auswirkungen dieser Fehler analysiert werden.

Warum das wichtig ist

Erfasst erfolgreiche und fehlgeschlagene automatisierte Builds und Tests. So werden Nacharbeitsschleifen sowie Probleme mit der Codequalität oder Testautomatisierung sichtbar.

Woher beziehen

Wird aus dem Feld „status“ der Antwort der GitLab-CI/CD-Pipelines-API abgerufen.

Beispiele
successfailedrunningcanceled
Quellsystem
SourceSystem
Gibt an, aus welchem System die Daten stammen.
Beschreibung

Dieses Attribut gibt die Herkunft der Prozessdaten an. In diesem Datenmodell lautet der Wert immer „GitLab“.

Das Attribut ist wichtig, wenn Prozessdaten aus mehreren Systemen zusammengeführt werden, etwa aus Jira für die Planung und GitLab für die Ausführung. Es ermöglicht Filterungen und Segmentierungen und hilft, die Datenherkunft nachzuvollziehen.

Warum das wichtig ist

Sorgt für Klarheit über die Datenherkunft. Das ist wichtig für die Data Governance und die Integration von Daten aus mehreren Unternehmenssystemen.

Woher beziehen

Dies ist ein statischer Wert, „GitLab“, der bei der Datentransformation hinzugefügt wird.

Beispiele
GitLab
Release-Version
ReleaseVersion
Das geplante oder tatsächliche Softwareversions-Tag der Bereitstellung.
Beschreibung

Dieses Attribut gibt an, zu welchem konkreten Software-Release ein Entwicklungselement gehört. In GitLab kann die Zuordnung über einen Meilenstein, ein geschütztes Tag oder einen Eintrag in der Releases-Funktion erfolgen.

Das Attribut ist für das Dashboard „Einhaltung des Release-Zeitplans verfolgen“ unverzichtbar. Durch den Vergleich des tatsächlichen Bereitstellungsdatums mit dem für die Release-Version geplanten Datum können Unternehmen messen, wie zuverlässig sie Zeitpläne einhalten, und die Ursachen für Release-Verzögerungen ermitteln.

Warum das wichtig ist

Ordnet Entwicklungselemente einem bestimmten Software-Release zu. Das ist entscheidend, um den Release-Fortschritt und die Einhaltung des Zeitplans zu verfolgen.

Woher beziehen

Die Datenquelle kann GitLab Releases, der Name eines Git-Tags oder der Titel eines für die Release-Planung verwendeten Meilensteins sein.

Beispiele
v1.2.0v3.0.0-beta2023.4.1
Status des Entwicklungselements
DevelopmentItemStatus
Der Status des Entwicklungselements zum Zeitpunkt des Ereignisses, etwa „Offen“, „In Bearbeitung“ oder „Geschlossen“.
Beschreibung

Dieses Attribut gibt den Status des primären Arbeitselements wieder, üblicherweise eines Issues in GitLab. GitLab-Issues haben einen state, der den Wert opened oder closed annehmen kann. Detailliertere Statusangaben werden häufig über bereichsbezogene Labels verwaltet, etwa Status::Triage, Status::In-Dev oder Status::In-Review.

Die Erfassung von Statusänderungen ist wichtig, um den Lebenszyklus eines Cases zu verstehen. Sie zeigt, wie lange Arbeitselemente in den einzelnen Status verbleiben, und ermöglicht es, in Dashboards wie „SDLC-Zykluszeit von Anfang bis Ende“ laufende oder abgeschlossene Arbeiten zu filtern.

Warum das wichtig ist

Zeigt den Status des Cases zu einem bestimmten Zeitpunkt. So lässt sich analysieren, wie lange Arbeit in den einzelnen Phasen verbleibt, und laufende Arbeit von abgeschlossener Arbeit unterscheiden.

Woher beziehen

Der primäre Status stammt aus dem Feld state eines GitLab-Issues (opened, closed). Detailliertere Statusangaben werden häufig aus Labels abgeleitet.

Beispiele
offengeschlossenIn BearbeitungIn Prüfung
Teamname
TeamName
Das Entwicklungsteam, das dem Projekt oder der zuständigen Person zugeordnet ist.
Beschreibung

Teamname bezeichnet die Gruppe oder das Squad, das für das Entwicklungselement verantwortlich ist. Diese Information ist in GitLab üblicherweise kein Standardfeld. Sie wird häufig aus Namenskonventionen für Projekte, Gruppenstrukturen oder einer externen Referenztabelle abgeleitet, die zuständige Personen ihren Teams zuordnet.

Mit diesem Attribut lässt sich die Prozessleistung auf Teamebene analysieren. Es hilft, Effizienz, Arbeitslast und Prozesseinhaltung verschiedener Teams zu vergleichen und unterstützt teambezogene Dashboards wie „Engpassanalyse nach Prozessphase“.

Warum das wichtig ist

Ermöglicht den Leistungsvergleich und die Prozessanalyse verschiedener Teams. So lassen sich teamspezifische Engpässe und bewährte Vorgehensweisen erkennen.

Woher beziehen

Wird häufig abgeleitet, indem der Projektname oder die zuständige Person einer außerhalb von GitLab definierten Teamstruktur zugeordnet wird. Alternativ kann die Zuordnung aus der GitLab-Gruppenhierarchie abgeleitet werden.

Beispiele
Frontend-AlphaBackend-ServicesPlattform-Infrastruktur
Wartezeit bei Übergaben
HandoffWaitTime
Berechnete Leerlaufzeit zwischen zwei aufeinanderfolgenden Aktivitäten, die von unterschiedlichen zuständigen Personen ausgeführt werden.
Beschreibung

Diese Kennzahl misst die Zeitspanne zwischen dem Abschluss einer Aktivität und dem Beginn der nächsten, sofern sich die zuständige Person ändert. Sie erfasst zum Beispiel die Zeit zwischen dem Abschluss der Entwicklungsarbeit und dem Beginn des Code Reviews.

Sie ist die zentrale Kennzahl für die KPI „Durchschnittliche Wartezeit bei Übergaben“. Damit lassen sich verborgene Ineffizienzen bei der Ressourcenzuteilung und der Kommunikation zwischen Teams oder einzelnen Personen aufdecken. Sichtbar werden Verzögerungen, in denen niemand aktiv an der Arbeit ist.

Warum das wichtig ist

Quantifiziert Leerlaufzeiten bei Übergaben zwischen Personen oder Teams und macht so verborgene Verzögerungen und Kommunikationsengpässe sichtbar.

Woher beziehen

Das Process-Mining-Tool berechnet die Kennzahl. Dazu analysiert es aufeinanderfolgende Ereignisse innerhalb eines Cases, prüft, ob sich die „Assignee“-Angabe unterscheidet, und berechnet anschließend die Zeitdifferenz.

Beispiele
1 Tag 2 Stunden15 Minuten8 Stunden
Ziel-Branch
TargetBranch
Der Name des Ziel-Branchs eines Merge Requests.
Beschreibung

Der Ziel-Branch ist der Branch, in den Änderungen übernommen werden sollen, zum Beispiel „main“, „develop“ oder ein Release-Branch wie „release/1.5“. Diese Angabe gehört zu den grundlegenden Informationen eines Merge Requests.

Eine Analyse nach Ziel-Branch kann unterschiedliche Prozessabläufe für Code aufzeigen, der in verschiedene Ziel-Branches übernommen wird. Für Merges in „main“ gelten möglicherweise strengere Freigabeprozesse und längere Zykluszeiten als für Merges in einen Feature-Branch. Außerdem lassen sich so Produktionsbereitstellungen von anderen Formen der Code-Integration unterscheiden.

Warum das wichtig ist

Ermöglicht den Vergleich verschiedener Entwicklungs- und Release-Workflows, da sich Prozesse je nach Ziel-Branch deutlich unterscheiden können.

Woher beziehen

Wird aus dem Feld „target_branch“ der Antwort der GitLab-Merge-Requests-API abgerufen.

Beispiele
maindeveloprelease/v2.1.0hotfix/user-auth-bug
Zykluszeit
CycleTime
Die gesamte Zeitspanne vom ersten bis zum letzten Ereignis eines Entwicklungselements.
Beschreibung

Die Zykluszeit ist eine berechnete Kennzahl für die Gesamtdauer eines Cases. Sie wird üblicherweise als Zeitdifferenz zwischen dem ersten Ereignis (z. B. „Issue erstellt“) und dem letzten Ereignis (z. B. „In Produktion bereitgestellt“) eines einzelnen Entwicklungselements berechnet.

Diese zentrale KPI misst die Effizienz des Gesamtprozesses. Sie ist die wichtigste Kennzahl in Dashboards wie „SDLC-Zykluszeit von Anfang bis Ende“ und dient dazu, Verbesserungen zu verfolgen sowie lang laufende Cases zu erkennen, die auf systemische Probleme hindeuten können.

Warum das wichtig ist

Diese zentrale Process-Mining-KPI misst die Effizienz des Entwicklungslebenszyklus von Anfang bis Ende.

Woher beziehen

Das Process-Mining-Tool berechnet die Kennzahl, indem es für jede eindeutige CaseId den kleinsten StartTime-Wert vom größten StartTime-Wert abzieht.

Beispiele
10 Tage 4 Stunden23 Stunden 15 Minuten35 Tage
Erforderlich Empfohlen Optional

Aktivitäten im Softwareentwicklungslebenszyklus

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um Prozesse zuverlässig zu erkennen und Engpässe zu identifizieren.
4 Empfohlen 8 Optional
Aktivität Beschreibung
In Produktion bereitgestellt
Diese Aktivität markiert die erfolgreiche Bereitstellung des Codes in der Produktivumgebung, sodass er für Endbenutzer verfügbar ist. Sie wird erfasst, wenn ein bestimmter Job zur Bereitstellung in der Produktion in einer GitLab-CI/CD-Pipeline erfolgreich abgeschlossen wird.
Warum das wichtig ist

Dies ist das primäre End-Event des Prozesses und zeigt an, dass der Nutzen bereitgestellt wurde. Es ist entscheidend, um die gesamte SDLC-Zykluszeit von Anfang bis Ende und die Release-Häufigkeit zu messen.

Woher beziehen

Das Ereignis wird anhand des Timestamps finished_at eines erfolgreichen CI/CD-Jobs erfasst, der ausdrücklich für die Bereitstellung in der Produktion vorgesehen ist. Die Environments-Funktion von GitLab erfasst dies explizit.

Erfassung

Verwenden Sie den Timestamp finished_at des erfolgreichen CI-Jobs zur Bereitstellung in der Produktion.

Ereignistyp explicit
Issue erstellt
Diese Aktivität markiert den Beginn des Entwicklungslebenszyklus: Ein neues Arbeitselement, etwa eine Funktion, ein Fehler oder eine Aufgabe, wird erstellt. Das Ereignis wird explizit erfasst, wenn ein Benutzer in GitLab ein neues Issue anlegt. Dabei wird der Erstellungszeitpunkt gespeichert.
Warum das wichtig ist

Dies ist das primäre Start-Event des End-to-End-Prozesses. Die Zeit zwischen der Erstellung des Issues und der Bereitstellung zeigt die Zykluszeit des gesamten SDLC.

Woher beziehen

Dieses explizite Ereignis wird anhand des Timestamps created_at in der Tabelle issues oder über die Issues API erfasst. Auch Systemnotizen halten die Erstellung fest.

Erfassung

Verwenden Sie den Timestamp created_at des Issues.

Ereignistyp explicit
Merge Request erstellt
Dieses Ereignis zeigt an, dass die erste Entwicklungsarbeit abgeschlossen und der Code zur Prüfung und Integration bereit ist. Es ist ein explizites Kernelement des GitLab-Workflows und wird erfasst, wenn ein Entwickler einen neuen Merge Request (MR) öffnet.
Warum das wichtig ist

Dieser wichtige Meilenstein markiert die Übergabe von der Entwicklung an Prüfung und Tests. Er ist der Ausgangspunkt für die Analyse des gesamten Code-Review- und CI/CD-Pipeline-Zyklus.

Woher beziehen

Dieses explizite Ereignis wird anhand des Timestamps created_at in der Tabelle merge_requests oder über die Merge Requests API erfasst.

Erfassung

Verwenden Sie den Timestamp created_at des Merge Requests.

Ereignistyp explicit
Merge Request zusammengeführt
Diese Aktivität kennzeichnet den erfolgreichen Abschluss der Codeprüfung und Integration. Sie tritt als explizites Ereignis auf, wenn ein Benutzer den Branch des Merge Requests in den Ziel-Branch integriert.
Warum das wichtig ist

Dieser wichtige Meilenstein zeigt an, dass Entwicklung und Prüfung abgeschlossen sind. Er markiert das Ende der Entwicklungszykluszeit und den Beginn der Messung der Bereitstellungszeit.

Woher beziehen

Dieses explizite Ereignis wird anhand des Timestamps merged_at in der Tabelle merge_requests erfasst. Beim Zusammenführen wird außerdem eine Systemnotiz erstellt.

Erfassung

Verwenden Sie den Timestamp merged_at des Merge Requests.

Ereignistyp explicit
Bereitstellung gestartet
Dieses Ereignis bezeichnet den Beginn der Codebereitstellung in einer bestimmten Umgebung, etwa Staging oder Produktion. In GitLab entspricht dies dem Start eines `deploy`-Jobs innerhalb einer CI/CD-Pipeline.
Warum das wichtig ist

Die Erfassung des Bereitstellungsstarts hilft, die Dauer der Bereitstellungsphase zu bestimmen. Sie ist entscheidend, um die Bereitstellungszeit zu messen und zu optimieren.

Woher beziehen

Das Ereignis wird anhand des Timestamps started_at eines CI/CD-Jobs erfasst, der als Bereitstellungsjob konfiguriert ist. Dies ist Teil der Funktionen Environments und Deployments von GitLab.

Erfassung

Verwenden Sie den Timestamp started_at aus dem CI-Job-Protokoll für eine Bereitstellungsaufgabe.

Ereignistyp explicit
Code-Review begonnen
Dieses Ereignis markiert den Beginn des Peer-Review-Prozesses für einen Merge Request. Es wird anhand der ersten prüfungsbezogenen Aktion abgeleitet, etwa des ersten Kommentars oder Diskussionsbeitrags einer anderen Person als des Autors.
Warum das wichtig ist

Die Zeit zwischen der Erstellung des MR und dem Beginn der Prüfung zeigt Wartezeiten auf. Diese zu verkürzen ist entscheidend, um den gesamten Code-Review-Zyklus zu verkürzen.

Woher beziehen

Das Ereignis wird anhand des Timestamps des ersten Kommentars oder Diskussionsbeitrags zum Merge Request abgeleitet, der nicht vom Autor des MR stammt. Diese Daten sind über Systemnotizen oder die Notes API verfügbar.

Erfassung

Ermitteln Sie den Timestamp des ersten Kommentars eines anderen Benutzers als des Autors zu einem MR.

Ereignistyp inferred
Entwicklung begonnen
Diese Aktivität kennzeichnet den Beginn der aktiven Programmierarbeit am Issue. Sie wird üblicherweise anhand des ersten Code-Commits auf einem mit dem Issue verknüpften Branch abgeleitet, da GitLab keine explizite Schaltfläche zum Starten der Entwicklung bietet.
Warum das wichtig ist

Damit lässt sich der genaue Beginn der wertschöpfenden Entwicklungsarbeit bestimmen. So können Sie die reine Programmierphase präzise messen und von Planungs- oder Wartezeiten abgrenzen.

Woher beziehen

Das Ereignis wird abgeleitet, indem der Timestamp des ersten Commits auf einem mit dem Issue verknüpften Feature-Branch ermittelt wird. Dazu müssen Issues mit Branches verknüpft werden, häufig über Namenskonventionen oder Metadaten.

Erfassung

Ermitteln Sie den Timestamp des ersten Commits auf einem Branch, der mit der Issue-ID verknüpft ist.

Ereignistyp inferred
Freigabe hinzugefügt
Dieses Ereignis bezeichnet die formelle Freigabe der Codeänderungen in einem Merge Request durch einen Reviewer. GitLab erfasst es explizit, wenn ein Benutzer auf die Schaltfläche „Approve“ klickt.
Warum das wichtig ist

Freigaben sind wichtige Qualitätskontrollen. Ihre Erfassung hilft, die Zeit bis zu den erforderlichen Freigaben zu analysieren und die Einhaltung der Review-Richtlinien sicherzustellen.

Woher beziehen

Das Ereignis wird anhand der Freigabeereignisse des Merge Requests erfasst. Diese sind über die Approvals API verfügbar oder im Verlauf des MR einsehbar.

Erfassung

Verwenden Sie den Timestamp aus dem Freigabeereignis des Merge Requests.

Ereignistyp explicit
Issue geschlossen
Diese Aktivität bezeichnet den abschließenden administrativen Abschluss des Arbeitselements, üblicherweise nachdem die Änderungen bereitgestellt und überprüft wurden. GitLab erfasst dieses Ereignis explizit, wenn ein Benutzer das Issue schließt.
Warum das wichtig ist

Das Schließen eines Issues markiert häufig das endgültige Ende aller damit verbundenen Arbeiten. Ein Vergleich mit dem Bereitstellungszeitpunkt kann Verzögerungen bei der Validierung nach der Bereitstellung oder bei administrativen Abläufen aufdecken.

Woher beziehen

Dieses explizite Ereignis wird anhand des Timestamps closed_at in der Tabelle issues oder der entsprechenden Systemnotiz erfasst.

Erfassung

Verwenden Sie den Timestamp closed_at des Issues.

Ereignistyp explicit
Issue zugewiesen
Diese Aktivität bezeichnet die Zuweisung eines Issues an einen bestimmten Entwickler oder ein Team. Damit ist festgelegt, wer für die Arbeit verantwortlich ist. GitLab protokolliert dieses Ereignis explizit, sobald das Feld für die zuständige Person eines Issues ausgefüllt oder geändert wird.
Warum das wichtig ist

Die Erfassung von Zuweisungen ist wichtig, um die Ressourcenverteilung, die Arbeitslast der Teams und Übergabezeiten zu analysieren. Sie hilft, Verzögerungen zwischen der Erstellung und der Übernahme einer Aufgabe zu erkennen.

Woher beziehen

Das Ereignis wird aus den GitLab-Systemnotizen zum Issue ermittelt. Darin wird protokolliert, wann eine zuständige Person hinzugefügt oder geändert wird. Der Timestamp des Ereignisses steht in der Notiz.

Erfassung

Extrahieren Sie Ereignisse zur Änderung der zuständigen Person aus den Systemnotizen des Issues.

Ereignistyp explicit
Pipeline fehlgeschlagen
Diese Aktivität tritt auf, wenn eine CI/CD-Pipeline in einer beliebigen Phase fehlschlägt, etwa aufgrund eines Build-Fehlers oder eines fehlgeschlagenen Tests. GitLab erfasst den Endstatus jeder Pipeline explizit, sodass sich Fehler leicht erkennen lassen.
Warum das wichtig ist

Fehlgeschlagene Pipelines sind eine häufige Ursache für Nacharbeit. Die Analyse ihrer Häufigkeit, Dauer und Ursachen hilft, Qualitätsprobleme, instabile Tests und Engpässe in der Rückmeldung an Entwickler zu erkennen.

Woher beziehen

Das Ereignis wird anhand des Status failed eines Pipeline-Datensatzes in der Tabelle ci_pipelines erkannt. Der Timestamp finished_at gibt an, wann der Fehler auftrat.

Erfassung

Filtern Sie Pipeline-Datensätze mit dem Status failed und verwenden Sie den Timestamp finished_at.

Ereignistyp explicit
Pipeline gestartet
Dieses Ereignis bezeichnet den Start einer automatisierten CI/CD-Pipeline, die üblicherweise Builds, Tests und Sicherheitsprüfungen ausführt. GitLab erstellt bei jeder ausgelösten Pipeline explizit einen Pipeline-Datensatz mit Startzeitpunkt, zum Beispiel nach einem Commit oder beim Erstellen eines MR.
Warum das wichtig ist

Die Ausführung von Pipelines zu verfolgen ist wichtig, um Zustand und Effizienz automatisierter Tests und Integrationsprozesse zu überwachen. So lässt sich erkennen, wie viel Zeit die automatisierte Validierung beansprucht.

Woher beziehen

Das Ereignis wird anhand des Timestamps created_at oder started_at eines Pipeline-Datensatzes in der Tabelle ci_pipelines oder über die Pipelines API erfasst.

Erfassung

Verwenden Sie den Timestamp aus dem Pipeline-Ausführungsdatensatz, der dem Branch des MR zugeordnet ist.

Ereignistyp explicit
Empfohlen Optional

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus GitLab

Möchten Sie loslegen?

Bereiten Sie Ihre Daten mit diesem Template vor und beginnen Sie, Ihren Softwareentwicklungslebenszyklus zu optimieren. Verbessern Sie Ihren Prozess noch heute!

Verbessern Sie Ihren Softwareentwicklungslebenszyklus: Beginnen Sie jetzt mit der Optimierung

Beseitigen Sie SDLC-Engpässe, verkürzen Sie die Zykluszeit um 30 % und verbessern Sie die Qualität.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Beginnen Sie sofort mit der Optimierung.