Skip to content

GitLab Next

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 43,035
    • Issues 43,035
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,359
    • Merge requests 1,359
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #328459
Closed
Open
Created Apr 20, 2021 by Dan Jensen@djensenContributor

[DORA] Improve "lead time for changes" calculation to use commit time

Problem to solve

Currently GitLab measures "lead time time for changes" (a DORA metric) as: "The median number of seconds between the merge of the merge request (MR) and the deployment of the MR’s commits for all MRs deployed during the time period." (source) That was probably the best minimal viable change, however it under-measures compared to the "official" definition, which is: "The median amount of time for a commit to be deployed into production." Commits are always made before, and sometimes long before, a merge request is merged. That means GitLab's measurement will always look better than it should.

Proposal

DORA "lead time for changes" should be measured from the individual commit time (not the commit-aggregated merge time). (Don't forget to update the documentation.)

It probably wouldn't be performant to measure this dynamically (by looking up all deployments in the time period, then looking up all commits associated with each deployment to calculate how long it took for them to be deployed). Instead, we should probably add an attribute to the MergeRequests::Metrics model. With this attribute we would track the median commit timestamp for all commits in a merge request, and update it whenever a commit is pushed to the merge request branch.

Related links

  • Google Cloud Platform's detailed measurement approach.
Edited Apr 30, 2021 by Dan Jensen
Assignee
Assign to
Time tracking