Your Software Development Lifecycle Data Template
Your Software Development Lifecycle Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance
Software Development Lifecycle Attributes
| Name | Description | ||
|---|---|---|---|
|
Activity
Activity
|
The name of the specific process step or event that occurred, such as 'Issue Created' or 'Merge Request Merged'. | ||
|
Description
The Activity attribute captures the distinct events that happen to a Development Item. These are not stored as a single field in GitLab but are derived from various actions and timestamp fields across Issues, Merge Requests, and CI/CD Pipelines. For example, the creation of an issue, a commit being pushed, a pipeline failing, or a merge request being approved are all distinct activities. This attribute is fundamental for building the process map, visualizing the workflow, and analyzing the sequence and frequency of events. It is used to identify deviations, bottlenecks between steps, and common process paths.
Why it matters
It defines the steps in the process map, allowing for the visualization and analysis of the end-to-end development workflow.
Where to get
Derived from event types and state changes in GitLab's event stream, or by interpreting timestamp fields like 'created_at', 'merged_at', and 'closed_at' on Issues and Merge Requests.
Examples
Issue CreatedDevelopment StartedMerge Request MergedPipeline FailedDeployed To Production
|
|||
|
Development Item
DevelopmentItem
|
The unique identifier for a unit of work, such as a feature, bug fix, or task, serving as the primary case identifier. | ||
|
Description
The Development Item represents a single, trackable piece of work flowing through the software development lifecycle. It connects all related activities, from creation to final deployment, into a coherent case. In GitLab, this is typically represented by the Issue's internal ID (IID), which is unique within a project. Analyzing by Development Item allows for end-to-end cycle time measurement, bottleneck identification, and process conformance checking. It forms the basis for understanding how efficiently work is delivered from concept to production.
Why it matters
This is the essential case identifier that links all process events together, making it possible to trace the full lifecycle of any given work item.
Where to get
This is typically the internal ID (IID) of a GitLab Issue. It can be found in the Issues API response as the 'iid' field.
Examples
1024512PRJ-2345
|
|||
|
Start Time
StartTime
|
The timestamp indicating when an activity or event began. | ||
|
Description
StartTime marks the precise date and time that a specific activity occurred. For events in GitLab, this is captured in various timestamp fields. For example, the 'Issue Created' activity's StartTime would be the This timestamp is the core temporal element in process mining. It is used to order events chronologically, calculate durations between activities, measure cycle times, and analyze process performance over time.
Why it matters
This attribute provides the chronological sequence of events, which is essential for calculating all time-based metrics and understanding the process flow.
Where to get
Extracted from various timestamp fields in GitLab, such as 'created_at', 'updated_at', 'closed_at' on issues, and 'merged_at' on merge requests.
Examples
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
Assignee
Assignee
|
The user assigned to the issue or merge request at the time of the event. | ||
|
Description
The Assignee is the individual developer or user responsible for the work item at a given point in the process. In GitLab, this is captured in the Analyzing by Assignee is critical for the 'Developer Workload & Allocation' dashboard. It helps in understanding resource utilization, identifying overloaded individuals or teams, and analyzing handoffs between different people.
Why it matters
Tracks who performed the work, enabling workload analysis, resource allocation efficiency, and identification of delays caused by handoffs.
Where to get
Retrieved from the 'assignee.username' or 'assignees' fields in the GitLab Issues and Merge Requests API responses.
Examples
jdoeasmithr.williams
|
|||
|
Dev Item Type
DevelopmentItemType
|
The classification of the development item, such as 'Feature', 'Bug', 'Task', or 'Maintenance'. | ||
|
Description
This attribute categorizes the nature of the work being performed. In GitLab, this is commonly implemented using labels on an issue. Teams use labels to distinguish between new functionality, defect resolution, technical debt, and other work types. Analyzing by Development Item Type allows for comparing process flows and cycle times for different kinds of work. For instance, one can analyze if bugs are resolved faster than features are developed, or if technical debt tasks follow a different review process.
Why it matters
Segmenting the process by work type helps identify if certain types of work are more prone to delays, rework, or deviations.
Where to get
Typically derived from the 'labels' applied to a GitLab Issue. A mapping logic is needed to translate specific labels into standardized types.
Examples
FeatureBugTaskTechnical Debt
|
|||
|
End Time
EndTime
|
The timestamp indicating when an activity or event was completed. | ||
|
Description
EndTime marks the precise date and time that an activity finished. For many atomic events in GitLab, such as 'Issue Created', the EndTime is the same as the StartTime. For activities that have a duration, like 'Code Review', it represents the completion timestamp, for example, when the final approval is given. This attribute is essential for accurately calculating the duration of individual activities (Processing Time). It helps in detailed bottleneck analysis by distinguishing between the time spent actively working on a task and the waiting time between tasks.
Why it matters
Enables the calculation of precise activity durations (processing times), which is key to identifying inefficient steps in the process.
Where to get
For atomic events, this is the same as StartTime. For durational activities, it must be derived by finding a corresponding completion event in the data.
Examples
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Project Name
ProjectName
|
The name of the GitLab project to which the development item belongs. | ||
|
Description
This attribute identifies the specific code repository or project where the work is being done. In GitLab, every issue and merge request is contained within a project. Analyzing by Project Name allows for performance comparisons across different products, components, or services. It can help identify if certain projects have healthier SDLC processes than others and is useful for filtering dashboards to a specific area of interest.
Why it matters
Enables process analysis to be segmented by product, application, or component, facilitating targeted improvement efforts.
Where to get
Retrieved from the 'name' or 'path_with_namespace' fields in the Project API, linked via the 'project_id' in Issues and Merge Requests.
Examples
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Severity
Severity
|
The severity level of the development item, typically for bugs or incidents. | ||
|
Description
Severity indicates the impact of a bug or issue, ranging from critical to minor. GitLab does not have a native severity field, so this is almost always implemented using labels (e.g., 'severity::1', 'severity::2'). This attribute is essential for the 'Severity Escalation Trends' dashboard and the associated KPI. Analyzing changes in severity over the lifecycle can highlight issues that were initially underestimated or processes that exacerbate problems.
Why it matters
Helps prioritize work and analyze if high-severity items are handled faster. Tracking changes supports the 'Severity Escalation Frequency' KPI.
Where to get
Derived from the 'labels' applied to a GitLab Issue. A mapping is required to interpret labels like 'S1', 'S2' as severity levels.
Examples
1 - Critical2 - High3 - Medium4 - Low
|
|||
|
Cycle Time
CycleTime
|
The total time elapsed from the first activity to the last activity for a development item. | ||
|
Description
Cycle Time is a calculated metric that measures the total duration of a case. It is typically calculated as the time difference between the very first event (e.g., 'Issue Created') and the very last event (e.g., 'Deployed to Production') for a single Development Item. This is a primary KPI for measuring overall process efficiency. It is the key metric in dashboards like 'SDLC End-to-End Cycle Time' and is used to track improvements and identify long-running cases that may indicate systemic problems.
Why it matters
This is a core process mining KPI that measures the end-to-end efficiency of the development lifecycle.
Where to get
Calculated by the process mining tool by subtracting the minimum StartTime from the maximum StartTime for each unique CaseId.
Examples
10 days 4 hours23 hours 15 minutes35 days
|
|||
|
Dev Item Status
DevelopmentItemStatus
|
The status of the development item at the time of the event, such as 'Open', 'In Progress', or 'Closed'. | ||
|
Description
This attribute reflects the state of the primary work item, typically an Issue in GitLab. GitLab Issues have a Tracking status changes is crucial for understanding the case lifecycle. It helps identify how long items spend in each state and can be used to filter for active or completed work in dashboards like 'SDLC End-to-End Cycle Time'.
Why it matters
Provides a snapshot of the case's state, enabling analysis of time spent in various stages and filtering for ongoing versus completed work.
Where to get
The primary status comes from the 'state' field of a GitLab Issue ('opened', 'closed'). Finer-grained statuses are often derived from labels.
Examples
openedclosedIn ProgressIn Review
|
|||
|
Handoff Wait Time
HandoffWaitTime
|
Calculated idle time between two consecutive activities performed by different assignees. | ||
|
Description
This metric calculates the duration of the gap between the completion of one activity and the start of the next, specifically when the assignee changes. For example, it measures the time from when a developer finishes their work to when a reviewer starts the code review. This is the key metric for the 'Average Handoff Wait Time' KPI. It helps uncover hidden inefficiencies in resource allocation and communication between teams or individuals, highlighting delays that are not part of any active work.
Why it matters
Quantifies idle time during handoffs between different people or teams, revealing hidden delays and communication bottlenecks.
Where to get
Calculated by the process mining tool. It requires analyzing consecutive events within a case, checking if the 'Assignee' is different, and then calculating the time difference.
Examples
1 day 2 hours15 minutes8 hours
|
|||
|
Is Rework
IsRework
|
A boolean flag indicating if an activity is part of a rework loop. | ||
|
Description
This calculated attribute flags activities that represent a step backward in the process, such as returning to development after testing has already begun. The logic for this flag typically involves detecting specific sequences of activities, for example, a 'Development Started' event occurring after a 'Pipeline Failed' or 'QA Testing Started' event for the same case. This attribute directly powers the 'Rework & Rerun Analysis' dashboard and the 'Rework Rate After Testing' KPI. It allows for easy filtering and quantification of rework, helping teams understand its frequency, causes, and impact on project timelines.
Why it matters
Directly flags and quantifies rework, making it easy to analyze the causes and impact of process inefficiencies and quality issues.
Where to get
Calculated by the process mining tool by analyzing the sequence of activities for each case and identifying patterns that indicate rework.
Examples
truefalse
|
|||
|
Last Data Update
LastDataUpdate
|
The timestamp indicating when the data for this event was last refreshed from the source system. | ||
|
Description
This attribute records the date and time the event data was last extracted or updated in the process mining dataset. It does not represent when the event happened, but rather when the record of the event was last synchronized. This information is vital for understanding data freshness and validating the timeliness of the process analysis. It helps users trust that the dashboards and KPIs are based on recent data and informs them of the potential lag between the source system and the analysis.
Why it matters
Provides transparency about data freshness, ensuring that users are aware of how up-to-date the process analysis is.
Where to get
This timestamp is generated and recorded by the data extraction tool or ETL process at the time of a data refresh.
Examples
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Merge Request Status
MergeRequestStatus
|
The status of the merge request associated with the event, such as 'Opened', 'Merged', or 'Closed'. | ||
|
Description
This attribute captures the state of a Merge Request (MR) at the time of an event. GitLab MRs have distinct states: 'opened', 'closed', 'merged', or 'locked'. This is separate from the overall Development Item Status. Tracking the MR status is crucial for analyzing the code integration phase of the SDLC. It directly supports dashboards like 'Code Review Cycle Time & Throughput' and helps pinpoint delays between MR creation, review, approval, and merging.
Why it matters
Provides visibility into the code review and merging process, which is often a critical bottleneck in the SDLC.
Where to get
Retrieved from the 'state' field in the GitLab Merge Requests API response.
Examples
openedmergedclosedlocked
|
|||
|
Milestone Title
MilestoneTitle
|
The title of the milestone or sprint to which the development item is assigned. | ||
|
Description
A Milestone in GitLab is used to track work against a specific goal or timebox, such as a sprint or a release version. This attribute captures the name or title of that milestone. This attribute allows for analyzing process performance within the context of specific sprints or planning periods. It can be used to see if cycle times are improving from one sprint to the next or to filter the process view to only show work related to an upcoming release.
Why it matters
Links development work to planning cycles like sprints or releases, enabling analysis of performance against planned timeboxes.
Where to get
Retrieved from the 'milestone.title' field in the GitLab Issues or Merge Requests API responses.
Examples
Q4-2023 ReleaseSprint 23.11Phase 1: MVP
|
|||
|
Pipeline Status
PipelineStatus
|
The status of the CI/CD pipeline run, such as 'Success', 'Failed', or 'Running'. | ||
|
Description
This attribute indicates the outcome of a CI/CD pipeline execution associated with a commit or merge request. Common statuses in GitLab include 'running', 'pending', 'success', 'failed', 'canceled', and 'skipped'. This data is essential for the 'Rework & Rerun Analysis' dashboard. Frequent pipeline failures can be a significant source of rework and delay, and analyzing their frequency, location, and impact is key to improving development efficiency and code quality.
Why it matters
Tracks the success and failure of automated builds and tests, highlighting rework loops and issues with code quality or test automation.
Where to get
Retrieved from the 'status' field in the GitLab CI/CD Pipelines API response.
Examples
successfailedrunningcanceled
|
|||
|
Processing Time
ProcessingTime
|
The duration of a single activity, calculated as the difference between its end and start time. | ||
|
Description
Processing time measures the active work time for a specific activity, distinct from the waiting time between activities. It is calculated as EndTime minus StartTime for a single event record. For instantaneous events, the processing time is zero. This metric is crucial for Stage-Specific Bottleneck Analysis. By aggregating the processing times of activities within a stage, such as Code Review, analysts can determine exactly how much time is spent actively performing work, helping to pinpoint inefficient process steps.
Why it matters
Measures the duration of individual activities, helping to distinguish active work time from idle wait time for precise bottleneck analysis.
Where to get
Calculated by the process mining tool as the difference between the EndTime and StartTime of an activity.
Examples
2 hours 30 minutes0 minutes3 days 8 hours
|
|||
|
Release Version
ReleaseVersion
|
The planned or actual software version tag associated with the deployment. | ||
|
Description
This attribute identifies the specific software release a development item is part of. In GitLab, this can be associated via a Milestone, a protected tag, or an entry in the Releases feature. This is essential for the 'Release Schedule Adherence Tracking' dashboard. By comparing the actual deployment date to a planned date associated with the release version, organizations can measure their ability to meet schedules and diagnose the causes of release delays.
Why it matters
Connects development items to a specific software release, which is crucial for tracking release progress and schedule adherence.
Where to get
This can be sourced from GitLab Releases, the name of a git tag, or the title of a milestone used for release planning.
Examples
v1.2.0v3.0.0-beta2023.4.1
|
|||
|
Source System
SourceSystem
|
Identifies the system from which the data was sourced. | ||
|
Description
This attribute specifies the origin of the process data. For this data model, the value will consistently be 'GitLab'. Including this attribute is crucial in environments where process data may be combined from multiple systems, such as Jira for planning and GitLab for execution. It allows for filtering, segmentation, and helps maintain data lineage.
Why it matters
Ensures clarity on data origin, which is critical for data governance and when integrating data from multiple enterprise systems.
Where to get
This is a static value, 'GitLab', added during the data transformation process.
Examples
GitLab
|
|||
|
Target Branch
TargetBranch
|
The name of the destination branch for a merge request. | ||
|
Description
The Target Branch is the branch that changes are intended to be merged into, for example, 'main', 'develop', or a release branch like 'release/1.5'. This is a core piece of information for any Merge Request. Analyzing by Target Branch can reveal different process behaviors for code being merged into different destinations. For example, merges into 'main' may have a more rigorous approval process and longer cycle times than merges into a feature branch. It can also help distinguish production deployments from other types of code integration.
Why it matters
Helps differentiate between various development and release workflows, as processes can vary significantly depending on the destination branch.
Where to get
Retrieved from the 'target_branch' field in the GitLab Merge Requests API response.
Examples
maindeveloprelease/v2.1.0hotfix/user-auth-bug
|
|||
|
Team Name
TeamName
|
The development team associated with the project or assignee. | ||
|
Description
Team Name represents the group or squad responsible for the development item. This information is typically not a standard field in GitLab and is often derived from project naming conventions, group structures, or by mapping assignees to their respective teams using an external reference table. This attribute is used to analyze process performance at a team level. It helps compare efficiency, workload, and adherence to process across different teams, supporting dashboards like 'Stage-Specific Bottleneck Analysis' from a team-based view.
Why it matters
Allows for performance analysis and process comparison across different teams, helping to identify team-specific bottlenecks or best practices.
Where to get
Often derived by mapping the Project Name or Assignee to a team structure defined outside of GitLab, or inferred from GitLab group hierarchies.
Examples
Frontend-AlphaBackend-ServicesPlatform-Infra
|
|||
Software Development Lifecycle Activities
| Activity | Description | ||
|---|---|---|---|
|
Deployed To Production
|
This activity marks the successful deployment of the code to the live production environment, making it available to end-users. This is captured when a specific 'deploy to production' job in a GitLab CI/CD pipeline completes successfully. | ||
|
Why it matters
This is the primary end event for the process, signifying that value has been delivered. It is essential for measuring the total end-to-end SDLC cycle time and release frequency.
Where to get
Captured from the 'finished_at' timestamp of a successful CI/CD job specifically designated for production deployment. GitLab's Environments feature tracks this explicitly.
Capture
Use 'finished_at' timestamp from the successful production deployment CI job.
Event type
explicit
|
|||
|
Issue Created
|
This activity marks the beginning of the development lifecycle, representing the creation of a new work item, such as a feature, bug, or task. It is captured explicitly when a user creates a new issue in GitLab, which records the creation timestamp. | ||
|
Why it matters
This is the primary start event for the end-to-end process. Analyzing the time from issue creation to deployment provides a complete picture of the SDLC cycle time.
Where to get
This is an explicit event captured from the 'created_at' timestamp in the 'issues' table or via the Issues API. System notes also record the creation event.
Capture
Use the 'created_at' timestamp of the issue.
Event type
explicit
|
|||
|
Merge Request Created
|
Indicates that the initial development work is complete and the code is ready for review and integration. This is an explicit, core event in the GitLab workflow, captured when a developer opens a new merge request (MR). | ||
|
Why it matters
This is a critical milestone that marks the handoff from development to review and testing. It is the entry point for analyzing the entire code review and CI/CD pipeline cycle.
Where to get
This is an explicit event captured from the 'created_at' timestamp in the 'merge_requests' table or via the Merge Requests API.
Capture
Use the 'created_at' timestamp of the merge request.
Event type
explicit
|
|||
|
Merge Request Merged
|
This activity signifies the successful completion of the code review and integration process. It is an explicit event that occurs when a user merges the merge request's branch into the target branch. | ||
|
Why it matters
This is a major milestone indicating that development and review are complete. It serves as the end point for measuring development cycle time and the start point for measuring deployment lead time.
Where to get
This is an explicit event captured from the 'merged_at' timestamp in the 'merge_requests' table. A system note is also generated upon merging.
Capture
Use the 'merged_at' timestamp of the merge request.
Event type
explicit
|
|||
|
Approval Added
|
Represents a formal approval of the code changes in a merge request by a reviewer. This is an explicit event captured by GitLab when a user clicks the 'Approve' button. | ||
|
Why it matters
Approvals are key quality gates. Tracking them helps analyze the time it takes to get required sign-offs and ensures compliance with review policies.
Where to get
Captured from merge request approval events. These are available via the Approvals API or can be seen in the MR's history.
Capture
Use the timestamp from the merge request approval event log.
Event type
explicit
|
|||
|
Code Review Started
|
Marks the beginning of the peer review process for a merge request. This event is inferred from the first review-related action, such as the first comment or thread posted by someone other than the author. | ||
|
Why it matters
Measuring the time from MR creation to the start of review highlights queueing delays. Reducing this wait time is key to shortening the overall code review cycle.
Where to get
Inferred from the timestamp of the first comment or review thread on the merge request that is not from the MR author. This data is available via system notes or the Notes API.
Capture
Find the timestamp of the first user comment on an MR from a non-author.
Event type
inferred
|
|||
|
Deployment Started
|
Represents the beginning of the process to release code to a specific environment, such as staging or production. In GitLab, this corresponds to the start of a 'deploy' job within a CI/CD pipeline. | ||
|
Why it matters
Tracking the start of deployment helps isolate the deployment phase's duration. It is crucial for measuring and optimizing the deployment lead time.
Where to get
Captured from the 'started_at' timestamp of a CI/CD job that is configured as a deployment job. This is part of GitLab's Environments and Deployments feature.
Capture
Use the 'started_at' timestamp from the CI job log for a deployment task.
Event type
explicit
|
|||
|
Development Started
|
This activity signifies the start of active coding work on the issue. This is typically inferred from the first code commit pushed to a branch associated with the issue, as GitLab does not have an explicit 'start development' button. | ||
|
Why it matters
Pinpoints the exact start of value-adding development work, allowing for accurate measurement of the pure coding phase and separating it from planning or queue time.
Where to get
Inferred by finding the timestamp of the first commit on a feature branch linked to the issue. This requires linking issues to branches, often done via naming conventions or metadata.
Capture
Find first commit timestamp on a branch associated with the issue ID.
Event type
inferred
|
|||
|
Issue Assigned
|
Represents the assignment of an issue to a specific developer or team, indicating that ownership for the work has been established. This is an explicit event logged by GitLab whenever the assignee field of an issue is populated or changed. | ||
|
Why it matters
Tracking assignments is crucial for analyzing resource allocation, team workload, and handoff times. It helps identify delays between when work is created and when it is picked up.
Where to get
Captured from GitLab's system notes for the issue, which log when an 'assignee' is added or changed. The event timestamp is recorded in the note.
Capture
Extract 'assignee changed' events from the issue's system notes.
Event type
explicit
|
|||
|
Issue Closed
|
Represents the final administrative closure of the work item, typically after its changes have been deployed and verified. This is an explicit event captured when a user closes the issue in GitLab. | ||
|
Why it matters
Closing an issue often signifies the final end of all related work. Comparing this to the deployment time can reveal delays in post-deployment validation or administrative processes.
Where to get
This is an explicit event captured from the 'closed_at' timestamp in the 'issues' table or from the corresponding system note.
Capture
Use the 'closed_at' timestamp of the issue.
Event type
explicit
|
|||
|
Pipeline Failed
|
This activity occurs when a CI/CD pipeline execution fails at any stage, such as a build error or a failed test. GitLab explicitly records the final status of every pipeline, making failures easy to identify. | ||
|
Why it matters
Pipeline failures are a primary driver of rework. Analyzing their frequency, duration, and cause helps identify quality issues, flaky tests, and bottlenecks in the feedback loop to developers.
Where to get
Identified by a 'failed' status on a pipeline record in the 'ci_pipelines' table. The 'finished_at' timestamp indicates when the failure occurred.
Capture
Filter for pipeline records with a 'failed' status and use the 'finished_at' timestamp.
Event type
explicit
|
|||
|
Pipeline Started
|
Represents the initiation of an automated CI/CD pipeline, which typically runs builds, tests, and security scans. GitLab explicitly creates a pipeline record with a start timestamp whenever a pipeline is triggered, for example by a commit or MR creation. | ||
|
Why it matters
Tracking pipeline executions is essential for monitoring the health and efficiency of automated testing and integration processes. It helps identify how much time is spent in automated validation.
Where to get
Captured from the 'created_at' or 'started_at' timestamp of a pipeline record in the 'ci_pipelines' table or via the Pipelines API.
Capture
Use the timestamp from the pipeline execution record associated with the MR's branch.
Event type
explicit
|
|||