This is an automated email from the ASF dual-hosted git repository. yumeng pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/incubator-devlake-website.git
commit 56741dc3924d9d41126a555857e33ef3f92fb261 Author: Startrekzky <[email protected]> AuthorDate: Fri Oct 14 17:59:57 2022 +0800 docs: update lead time for changes --- docs/Metrics/LeadTimeForChanges.md | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/docs/Metrics/LeadTimeForChanges.md b/docs/Metrics/LeadTimeForChanges.md index 6183ac975..7f6140f8e 100644 --- a/docs/Metrics/LeadTimeForChanges.md +++ b/docs/Metrics/LeadTimeForChanges.md @@ -16,16 +16,24 @@ DORA dashboard. See [live demo](https://grafana-lake.demo.devlake.io/grafana/d/q ## How is it calculated? -This metric can be calculated in two ways: -- If a deployment can be linked to PRs, then the lead time for changes of a deployment is the average cycle time of its associated PRs. For instance, - - Compared to the previous deployment `deploy-1`, `deploy-2` deployed three new commits `commit-1`, `commit-2` and `commit-3`. - - `commit-1` is linked to `pr-1`, `commit-2` is linked to `pr-2` and `pr-3`, `commit-3` is not linked to any PR. Then, `deploy-2` is associated with `pr-1`, `pr-2` and `pr-3`. - - `Deploy-2`'s lead time for changes = average cycle time of `pr-1`, `pr-2` and `pr-3`. -- If a deployment can't be linked to PRs, then the lead time for changes is computed based on its associated commits. For instance, - - Compared to the previous deployment `deploy-1`, `deploy-2` deployed three new commits `commit-1`, `commit-2` and `commit-3`. - - None of `commit-1`, `commit-2` and `commit-3` is linked to any PR. - - Calculate each commit's lead time for changes, which equals to `deploy-2`'s deployed_at - commit's authored_date - - `Deploy-2`'s Lead time for changes = average lead time for changes of `commit-1`, `commit-2` and `commit-3`. +This metric is calculated by the median cycle time of the PRs deployed in a time range. A PR's cycle time is equal to the time a PR was deployed minus the PR's first commit's authored_date. + + + +See the picture above, there were three deployments in the last month: Deploy-1, Deploy-2 and Deploy-3. Six PRs were deployed during the same period. + + Median Lead Time for Changes = The median cycle time of PR-1, PR-2, PR-3, PR-4, PR-5, PR-6 + +The way to calculate PR cycle time: +- PR-1 cycle time = Deploy-1's finished_date - PR-1's first commit's authored_date +- PR-2 cycle time = Deploy-2's finished_date - PR-2's first commit's authored_date +- PR-3 cycle time = Deploy-2's finished_date - PR-3's first commit's authored_date +- PR-4 cycle time = Deploy-3's finished_date - PR-4's first commit's authored_date +- PR-5 cycle time = Deploy-3's finished_date - PR-5's first commit's authored_date +- PR-6 cycle time = Deploy-3's finished_date - PR-6's first commit's authored_date + +PR cycle time is pre-calculated when dora plugin is triggered. You can connect to DevLake's database and find it in the field `change_timespan` in [table.pull_requests](https://devlake.apache.org/docs/DataModels/DevLakeDomainLayerSchema/#pull_requests). + Below are the benchmarks for different development teams from Google's report. However, it's difficult to tell which group a team falls into when the team's median lead time for changes is `between one week and one month`. Therefore, DevLake provides its own benchmarks to address this problem:
