diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-04-21 02:50:22 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-04-21 02:50:22 +0300 |
commit | 9dc93a4519d9d5d7be48ff274127136236a3adb3 (patch) | |
tree | 70467ae3692a0e35e5ea56bcb803eb512a10bedb /doc/user/analytics | |
parent | 4b0f34b6d759d6299322b3a54453e930c6121ff0 (diff) |
Add latest changes from gitlab-org/gitlab@13-11-stable-eev13.11.0-rc43
Diffstat (limited to 'doc/user/analytics')
-rw-r--r-- | doc/user/analytics/ci_cd_analytics.md | 37 | ||||
-rw-r--r-- | doc/user/analytics/code_review_analytics.md | 4 | ||||
-rw-r--r-- | doc/user/analytics/img/code_review_analytics_v12_8.png | bin | 40082 -> 0 bytes | |||
-rw-r--r-- | doc/user/analytics/img/code_review_analytics_v13_11.png | bin | 0 -> 107184 bytes | |||
-rw-r--r-- | doc/user/analytics/img/issues_created_per_month_v12_8.png | bin | 26718 -> 0 bytes | |||
-rw-r--r-- | doc/user/analytics/img/issues_created_per_month_v13_11.png | bin | 0 -> 57729 bytes | |||
-rw-r--r-- | doc/user/analytics/img/lead_time_chart_v13_11.png | bin | 0 -> 52168 bytes | |||
-rw-r--r-- | doc/user/analytics/index.md | 15 | ||||
-rw-r--r-- | doc/user/analytics/issue_analytics.md | 4 | ||||
-rw-r--r-- | doc/user/analytics/value_stream_analytics.md | 24 |
10 files changed, 54 insertions, 30 deletions
diff --git a/doc/user/analytics/ci_cd_analytics.md b/doc/user/analytics/ci_cd_analytics.md index 0f19998749d..397f311adae 100644 --- a/doc/user/analytics/ci_cd_analytics.md +++ b/doc/user/analytics/ci_cd_analytics.md @@ -22,7 +22,10 @@ View pipeline duration history: ![Pipeline duration](img/pipelines_duration_chart.png) -## DORA4 Metrics +## DevOps Research and Assessment (DORA) key metrics **(ULTIMATE)** + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/275991) in GitLab 13.7. +> - Added support for [lead time for changes](https://gitlab.com/gitlab-org/gitlab/-/issues/291746) in GitLab 13.10. Customer experience is a key metric. Users want to measure platform stability and other post-deployment performance KPIs, and set targets for customer behavior, experience, and financial @@ -41,11 +44,20 @@ performance indicators for software development teams: - Time to restore service: How long it takes an organization to recover from a failure in production. -GitLab plans to add support for all the DORA4 metrics at the project and group levels. GitLab added -the first metric, deployment frequency, at the project and group scopes for [CI/CD charts](ci_cd_analytics.md#deployment-frequency-charts), -the [Project API]( ../../api/dora4_project_analytics.md), and the [Group API]( ../../api/dora4_group_analytics.md). +### Supported metrics in GitLab + +The following table shows the supported metrics, at which level they are supported, and which GitLab version (API and UI) they were introduced: + +| Metric | Level | API version | Chart (UI) version | Comments | +| --------------- | ----------- | --------------- | ---------- | ------- | +| `deployment_frequency` | Project-level | [13.7+](../../api/dora/metrics.md) | [13.8+](#deployment-frequency-charts) | The [old API endopint](../../api/dora4_project_analytics.md) was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/323713) in 13.10. | +| `deployment_frequency` | Group-level | [13.10+](../../api/dora/metrics.md) | To be supported | | +| `lead_time_for_changes` | Project-level | [13.10+](../../api/dora/metrics.md) | To be supported | Unit in seconds. Aggregation method is median. | +| `lead_time_for_changes` | Group-level | [13.10+](../../api/dora/metrics.md) | To be supported | Unit in seconds. Aggregation method is median. | +| `change_failure_rate` | Project/Group-level | To be supported | To be supported | | +| `time_to_restore_service` | Project/Group-level | To be supported | To be supported | | -## Deployment frequency charts **(ULTIMATE)** +### Deployment frequency charts **(ULTIMATE)** > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/275991) in GitLab 13.8. @@ -54,3 +66,18 @@ The **Analytics > CI/CD Analytics** page shows information about the deployment information to appear on the graphs. ![Deployment frequency](img/deployment_frequency_chart_v13_8.png) + +### Lead time charts **(ULTIMATE)** + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/250329) in GitLab 13.11. + +The charts in the **Lead Time** tab show information about how long it takes +merge requests to be deployed to a production environment. + +![Lead time](img/lead_time_chart_v13_11.png) + +Smaller values are better. Small lead times indicate fast, efficient deployment +processes. + +For time periods in which no merge requests were deployed, the charts render a +red, dashed line. diff --git a/doc/user/analytics/code_review_analytics.md b/doc/user/analytics/code_review_analytics.md index 19016c3aa26..fe091fc9899 100644 --- a/doc/user/analytics/code_review_analytics.md +++ b/doc/user/analytics/code_review_analytics.md @@ -24,11 +24,11 @@ Initially, no data appears. Data is populated as users comment on open merge req Code Review Analytics is available to users with Reporter access and above, and displays a table of open merge requests that have at least one non-author comment. The review time is measured from the time the first non-author comment was submitted. -To access Code Review Analytics, from your project's menu, go to **Project Analytics > Code Review**. +To access Code Review Analytics, from your project's menu, go to **Analytics > Code Review**. You can filter the list of merge requests by milestone and label. -![Code Review Analytics](img/code_review_analytics_v12_8.png "List of code reviews; oldest review first.") +![Code Review Analytics](img/code_review_analytics_v13_11.png "List of code reviews; oldest review first.") The table is sorted by: diff --git a/doc/user/analytics/img/code_review_analytics_v12_8.png b/doc/user/analytics/img/code_review_analytics_v12_8.png Binary files differdeleted file mode 100644 index 3b23e74130a..00000000000 --- a/doc/user/analytics/img/code_review_analytics_v12_8.png +++ /dev/null diff --git a/doc/user/analytics/img/code_review_analytics_v13_11.png b/doc/user/analytics/img/code_review_analytics_v13_11.png Binary files differnew file mode 100644 index 00000000000..e337afa3ace --- /dev/null +++ b/doc/user/analytics/img/code_review_analytics_v13_11.png diff --git a/doc/user/analytics/img/issues_created_per_month_v12_8.png b/doc/user/analytics/img/issues_created_per_month_v12_8.png Binary files differdeleted file mode 100644 index fccfa949779..00000000000 --- a/doc/user/analytics/img/issues_created_per_month_v12_8.png +++ /dev/null diff --git a/doc/user/analytics/img/issues_created_per_month_v13_11.png b/doc/user/analytics/img/issues_created_per_month_v13_11.png Binary files differnew file mode 100644 index 00000000000..01ebde5a54d --- /dev/null +++ b/doc/user/analytics/img/issues_created_per_month_v13_11.png diff --git a/doc/user/analytics/img/lead_time_chart_v13_11.png b/doc/user/analytics/img/lead_time_chart_v13_11.png Binary files differnew file mode 100644 index 00000000000..5577e215711 --- /dev/null +++ b/doc/user/analytics/img/lead_time_chart_v13_11.png diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md index fe35d575373..6e3c9cf7a5f 100644 --- a/doc/user/analytics/index.md +++ b/doc/user/analytics/index.md @@ -23,7 +23,7 @@ as described in ([Measuring DevOps Performance](https://devops.com/measuring-dev - MTTD (Mean Time to Detect): The average duration that a bug goes undetected in production. GitLab measures MTTD from deployment of bug to issue creation. - MTTM (Mean Time To Merge): The average lifespan of a merge request. GitLab measures MTTM from merge request creation to merge request merge (and closed/un-merged merge requests are excluded). For more information, see [Merge Request Analytics](merge_request_analytics.md). - MTTR (Mean Time to Recover/Repair/Resolution/Resolve/Restore): The average duration that a bug is not fixed in production. GitLab measures MTTR from deployment of bug to deployment of fix. -- Lead time: The duration of the work itself. Often displayed in combination with "cycle time." GitLab measures from issue first merge request creation to issue close. Note: Obviously work started before the creation of the first merge request. We plan to start measuring from "issue first commit" as a better proxy, although still imperfect. GitLab displays lead time in [Value Stream Analytics](value_stream_analytics.md). +- Lead time: The duration of the work itself. Often displayed in combination with "cycle time." GitLab measures from issue first merge request creation to issue close. Note: Work started before the creation of the first merge request. We plan to start measuring from "issue first commit" as a better proxy, although still imperfect. GitLab displays lead time in [Value Stream Analytics](value_stream_analytics.md). - Throughput: The number of issues closed or merge requests merged (not closed) in some period of time. Often measured per sprint. GitLab displays merge request throughput in [Merge Request Analytics](merge_request_analytics.md). - Value Stream: The entire work process that is followed to deliver value to customers. For example, the [DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/) is a value stream that starts with "plan" and ends with "monitor". GitLab helps you track your value stream using [Value Stream Analytics](value_stream_analytics.md). - Velocity: The total issue burden completed in some period of time. The burden is usually measured in points or weight, often per sprint. For example, your velocity may be "30 points per sprint". GitLab measures velocity as the total points/weight of issues closed in a given period of time. @@ -46,11 +46,13 @@ in one place. The following analytics features are available at the group level: - [Contribution](../group/contribution_analytics/index.md). **(PREMIUM)** +- [DevOps Adoption](../group/devops_adoption/index.md). **(ULTIMATE)** - [Insights](../group/insights/index.md). **(ULTIMATE)** - [Issue](../group/issues_analytics/index.md). **(PREMIUM)** -- [Productivity](productivity_analytics.md) **(PREMIUM)** -- [Repositories](../group/repositories_analytics/index.md) **(PREMIUM)** +- [Productivity](productivity_analytics.md). **(PREMIUM)** +- [Repositories](../group/repositories_analytics/index.md). **(PREMIUM)** - [Value Stream](../group/value_stream_analytics/index.md). **(PREMIUM)** +- [Application Security](../application_security/security_dashboard/#group-security-dashboard). **(ULTIMATE)** ## Project-level analytics @@ -64,3 +66,10 @@ The following analytics features are available at the project level: [feature flag](../../development/feature_flags/index.md#enabling-a-feature-flag-locally-in-development). **(PREMIUM)** - [Repository](repository_analytics.md). **(FREE)** - [Value Stream](value_stream_analytics.md). **(FREE)** +- [Application Security](../application_security/security_dashboard/#project-security-dashboard). **(ULTIMATE)** + +## User-configurable analytics + +The following analytics features are available for users to create personalized views: + +- [Application Security](../application_security/security_dashboard/#security-center). **(ULTIMATE)** diff --git a/doc/user/analytics/issue_analytics.md b/doc/user/analytics/issue_analytics.md index 6c6911ff4f4..b77a25a9d62 100644 --- a/doc/user/analytics/issue_analytics.md +++ b/doc/user/analytics/issue_analytics.md @@ -13,7 +13,7 @@ Issue Analytics is a bar graph which illustrates the number of issues created ea The default time span is 13 months, which includes the current month, and the 12 months prior. -To access the chart, navigate to your project sidebar and select **{chart}** **Analytics > Issue Analytics**. +To access the chart, navigate to your project sidebar and select **Analytics > Issue**. Hover over each bar to see the total number of issues. @@ -31,7 +31,7 @@ You can change the total number of months displayed by setting a URL parameter. For example, `https://gitlab.com/groups/gitlab-org/-/issues_analytics?months_back=15` shows a total of 15 months for the chart in the GitLab.org group. -![Issues created per month](img/issues_created_per_month_v12_8.png) +![Issues created per month](img/issues_created_per_month_v13_11.png) ## Drill into the information diff --git a/doc/user/analytics/value_stream_analytics.md b/doc/user/analytics/value_stream_analytics.md index 6c41d93d51f..2af98492ee7 100644 --- a/doc/user/analytics/value_stream_analytics.md +++ b/doc/user/analytics/value_stream_analytics.md @@ -58,19 +58,13 @@ GitLab provides the ability to filter analytics based on a date range. To filter The "Time" metrics near the top of the page are measured as follows: - **Lead time**: median time from issue created to issue closed. -- **Cycle time**: median time from first commit to issue closed. - -NOTE: -A commit is associated with an issue by [crosslinking](../project/issues/crosslinking_issues.md) in the commit message or by manually linking the merge request containing the commit. +- **Cycle time**: median time from first commit to issue closed. (You can associate a commit with an issue by [crosslinking in the commit message](../project/issues/crosslinking_issues.md#from-commit-messages).) ## How the stages are measured -Value Stream Analytics records stage time and data based on the project issues with the -exception of the staging stage, where only data deployed to -production are measured. - -Specifically, if your CI is not set up and you have not defined a [production environment](#how-the-production-environment-is-identified), then you will not have any -data for this stage. +Value Stream Analytics uses start events and stop events to measure the time that an Issue or MR spends in each stage. +For example, a stage might start when one label is added to an issue, and end when another label is added. +Items are not included in the stage time calculation if they have not reached the stop event. Each stage of Value Stream Analytics is further described in the table below. @@ -103,14 +97,8 @@ In short, the Value Stream Analytics dashboard tracks data related to [GitLab fl ## How the production environment is identified -Value Stream Analytics identifies production environments by looking for project [environments](../../ci/yaml/README.md#environment) with a name matching any of these patterns: - -- `prod` or `prod/*` -- `production` or `production/*` - -These patterns are not case-sensitive. - -You can change the name of a project environment in your GitLab CI/CD configuration. +Value Stream Analytics identifies production environments based on +[the deployment tier of environments](../../ci/environments/index.md#deployment-tier-of-environments). ## Example workflow |