diff options
Diffstat (limited to 'doc/user/analytics')
| -rw-r--r-- | doc/user/analytics/ci_cd_analytics.md | 37 | ||||
| -rw-r--r-- | doc/user/analytics/img/time_to_restore_service_charts_v15_1.png | bin | 0 -> 86137 bytes | |||
| -rw-r--r-- | doc/user/analytics/index.md | 12 | ||||
| -rw-r--r-- | doc/user/analytics/value_stream_analytics.md | 7 |
4 files changed, 41 insertions, 15 deletions
diff --git a/doc/user/analytics/ci_cd_analytics.md b/doc/user/analytics/ci_cd_analytics.md index f0de1e58891..920b651c094 100644 --- a/doc/user/analytics/ci_cd_analytics.md +++ b/doc/user/analytics/ci_cd_analytics.md @@ -6,13 +6,20 @@ info: To determine the technical writer assigned to the Stage/Group associated w # CI/CD analytics **(FREE)** -## Pipeline success and duration charts +Use the CI/CD analytics page to view pipeline success rates and duration, and the history of [DORA metrics](index.md#devops-research-and-assessment-dora-key-metrics) over time. -> [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/38318) to CI/CD Analytics in GitLab 12.8. +## Pipeline success and duration charts CI/CD analytics shows the history of your pipeline successes and failures, as well as how long each pipeline ran. +Pipeline statistics are gathered by collecting all available pipelines for the +project, regardless of status. The data available for each individual day is based +on when the pipeline was created. + +The total pipeline calculation includes child +pipelines and pipelines that failed with an invalid YAML. To filter pipelines based on other attributes, use the [Pipelines API](../../api/pipelines.md#list-project-pipelines). + View successful pipelines:  @@ -21,12 +28,6 @@ View pipeline duration history:  -Pipeline statistics are gathered by collecting all available pipelines for the -project regardless of status. The data available for each individual day is based -on when the pipeline was created. The total pipeline calculation includes child -pipelines and pipelines that failed with invalid YAML. If you are interested in -filtering pipelines based on other attributes, consider using the [Pipelines API](../../api/pipelines.md#list-project-pipelines). - ## View CI/CD analytics To view CI/CD analytics: @@ -43,6 +44,8 @@ frequency to the `production` environment. The environment must be part of the [production deployment tier](../../ci/environments/index.md#deployment-tier-of-environments) for its deployment information to appear on the graphs. + Deployment frequency is one of the four [DORA metrics](index.md#devops-research-and-assessment-dora-key-metrics) that DevOps teams use for measuring excellence in software delivery. + The deployment frequency chart is available for groups and projects. To view the deployment frequency chart: @@ -65,6 +68,8 @@ merge requests to be deployed to a production environment. This chart is availab - For time periods in which no merge requests were deployed, the charts render a red, dashed line. + lead time for changes is one of the four [DORA metrics](index.md#devops-research-and-assessment-dora-key-metrics) that DevOps teams use for measuring excellence in software delivery. + To view the lead time for changes chart: 1. On the top bar, select **Menu > Projects** and find your project. @@ -72,3 +77,19 @@ To view the lead time for changes chart: 1. Select the **Lead time** tab.  + +## View time to restore service chart **(PREMIUM)** + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/356959) in GitLab 15.1 + +The time to restore service chart shows information about the median time an incident was open in a production environment. This chart is available for groups and projects. + +Time to restore service is one of the four [DORA metrics](index.md#devops-research-and-assessment-dora-key-metrics) that DevOps teams use for measuring excellence in software delivery. + +To view the time to restore service chart: + +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Analytics > CI/CD Analytics**. +1. Select the **Time to restore service** tab. + + diff --git a/doc/user/analytics/img/time_to_restore_service_charts_v15_1.png b/doc/user/analytics/img/time_to_restore_service_charts_v15_1.png Binary files differnew file mode 100644 index 00000000000..25aac385750 --- /dev/null +++ b/doc/user/analytics/img/time_to_restore_service_charts_v15_1.png diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md index 017a0c46570..91d9bd918b6 100644 --- a/doc/user/analytics/index.md +++ b/doc/user/analytics/index.md @@ -81,7 +81,7 @@ Deployment frequency displays in several charts: Lead time for changes measures the time to deliver a feature once it has been developed, as described in [Measuring DevOps Performance](https://devops.com/measuring-devops-performance/). -Lead time for changes displays in several charts: +Lead time for changes displays in several charts: - [Group-level value stream analytics](../group/value_stream_analytics/index.md) - [Project-level value stream analytics](value_stream_analytics.md) @@ -89,7 +89,7 @@ Lead time for changes displays in several charts: ### Time to restore service -Time to restore service measures how long it takes an organization to recover from a failure in production. +Time to restore service measures how long it takes an organization to recover from a failure in production. GitLab measures this as the average time required to close the incidents in the given time period. This assumes: @@ -97,9 +97,15 @@ in the given time period. This assumes: - Incidents and deployments have a strictly one-to-one relationship. An incident is related to only one production deployment, and any production deployment is related to no more than one incident). +Time to restore service displays in several charts: + +- [Group-level value stream analytics](../group/value_stream_analytics/index.md) +- [Project-level value stream analytics](value_stream_analytics.md) +- [CI/CD analytics](ci_cd_analytics.md) + To retrieve metrics for time to restore service, use the [GraphQL](../../api/graphql/reference/index.md) or the [REST](../../api/dora/metrics.md) APIs. -### Change failure rate +### Change failure rate Change failure rate measures the percentage of deployments that cause a failure in production. GitLab measures this as the number of incidents divided by the number of deployments to a diff --git a/doc/user/analytics/value_stream_analytics.md b/doc/user/analytics/value_stream_analytics.md index 039d33a1ad8..c0f97369740 100644 --- a/doc/user/analytics/value_stream_analytics.md +++ b/doc/user/analytics/value_stream_analytics.md @@ -43,9 +43,8 @@ To view value stream analytics for your project: - In the **From** field, select a start date. - In the **To** field, select an end date. 1. Optional. Sort results by ascending or descending: - - To sort by most recent or oldest workflow item, select the **Merge requests** or **Issues** - header. The header name differs based on the stage you select. - - To sort by most or least amount of time spent in each stage, select the **Time** header. + - To sort by most recent or oldest workflow item, select the **Last event** header. + - To sort by most or least amount of time spent in each stage, select the **Duration** header. The table shows a list of related workflow items for the selected stage. Based on the stage you choose, this can be: @@ -119,7 +118,7 @@ The **Lead Time for Changes** metrics display below the **Filter results** text To view deployment metrics, you must have a [production environment configured](../../ci/environments/index.md#deployment-tier-of-environments). -Value stream analytics shows the following deployment metrics for your project: +Value stream analytics shows the following deployment metrics for your project: - Deploys: The number of successful deployments in the date range. - Deployment Frequency: The average number of successful deployments per day in the date range. |
