Skip to content

Add PoC DORA configuration for Lead Time for Changes

What does this MR do and why?

It adds PoC models that allow to configure an alter behaviour of DORA metrics calculations for specific projects.

All the changes are behind a feature flag dora_configuration

Migration output

main: == 20220830114228 CreateDoraConfigurationTable: reverting =====================
main: -- drop_table(:dora_configurations)
main:    -> 0.0083s
main: == 20220830114228 CreateDoraConfigurationTable: reverted (0.0099s) ============

main: == 20220830114228 CreateDoraConfigurationTable: migrating =====================
main: -- create_table(:dora_configurations, {})
main:    -> 0.0046s
main: == 20220830114228 CreateDoraConfigurationTable: migrated (0.0046s) ============

Query explains

https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/11820/commands/41932

Steps to check on localhost

In rails console:

  1. Find a project with valid environment and deployment and MRs. Environment.last should work for default setup.
  2. Change target branch for 1 of MRs to something custom. E.g. Environment.last.deployments.last.merge_requests.last.update!(target_branch: 'custom')
  3. Use Dora::DailyMetrics.refresh!(Environment.last, Environment.last.deployments.last.finished_at.to_date) to refresh DORA data for given date. Verify Lead Time for Changes value for the date.
  4. Enable feature flag: Feature.enable!(:dora_configuration, Environment.last.project)
  5. Add custom configuration: Dora::Configuration.create!(project: Environment.last.project, ltfc_target_branches: ['master', 'main'])
  6. Redo step 3. Verify that Lead time for changes value doesn't include MR with target_branch custom.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #371029 (closed)

Edited by Pavel Shutsin

Merge request reports