Extend DORA metrics to calculate environment and deployment_tier beyond 'Production' or 'Prod' labels

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Problem to solve

In current (16.5) behavior DORA Deployment Frequency is calculated using an environment name or environment:deployment_tier labelled only 'Production' or 'Prod'. There isn't any support for customizations, wildcards or CI variables.

Many current customers have deployment definitions that go beyond a simple 'Production/Prod' and thus cannot make use of the offering as it stands today.

If the metric of Lead Time for Changes is taking into account only Production/Prod environment labelling, we would want its calculation to be extended to be flexible as well.

Customer scenario current implementation cannot address

• Customer has a production environment that is distributed and segregated in different cloud providers and VPCs. In their deployment jobs, they have already defined their environments to use a naming standard involving pre-fixes and wildcards

Pseudo code of what a Production deploy job could look like, as defined in the local Project .yml:

local_deploy_job:
  stage: deploy
  extends: .a_template_job
  environment:  
     name: gcp-*

• Their deployment jobs are defined in a series of include templates. Individuals Projects then define jobs which extends from their includes.
  • They cannot simply add environment:deployment_tier: production at the template level, as the job where that would be logically defined, is used for more than just production jobs
• If they created a new templated job, just for the purpose of production "extension", they would still be forced to go into each of those Project .gitlab-ci.yml files and update where the extends is referencing from, and then test to ensure they have not broken anything.
• Customer has 1000s of repositories. The people hours that would be required to retrofit their environments to support DORA as it is today, is not possible.

Proposal

• Allow customers to self-define what environments DORA is using to calculate their deployment frequency, including custom regex prefix support

  • What resolution would look like:
    • Customer would have customization options at either Group or Project level, such that they could indicate that jobs deploying to "environment:name: gcp-*" should be calculated in DORA deployment frequency
    • Customer would have the ability to set multiple options for complex environments

• Add CI variable support for environment:deployment_tier, such that it can be set at runtime and does not need to be explicitly defined in the local YML. Adding the CI variable would control Pipeline behavior the same as if a user had hardcoded 'environment:deployment_tier: production' into jobs where an environment had already been defined.

  • What resolution would look like:
    • Customer could set "DEPLOYMENT_TIER = Production" as a Pipeline CI variable at runtime. All deployment jobs in that pipeline are included in the calculation for DORA deployment frequency. When they do not set DEPLOYMENT_TIER at runtime, the value is null/not set.

Intended users

Priyanka

Feature Usage Metrics

Does this feature require an audit event?

No

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.