DORA Metrics Configuration#

DevLake computes the four DORA metrics — Deployment Frequency, Lead Time for Changes, Change Failure Rate (CFR), and Mean Time to Restore (MTTR) — by combining data from three plugins: a CI/CD source (GitHub, GitLab, or Azure DevOps), refdiff, and dora. Configuration is set per-repository in the plugin's Scope Config, then flows through a multi-stage pipeline. 1

Scope Config: Deployment Classification Patterns#

The GithubScopeConfig (stored in _tool_github_scope_configs) holds three regex fields that classify CI/CD runs and jobs: 1

The same three fields exist in GitlabScopeConfig and (without EnvNamePattern) in AzuredevopsScopeConfig. 2

The scope config also holds a Refdiff field (datatypes.JSONMap) passed directly to the refdiff plugin (see below). 1

How patterns are compiled: At task start, PrepareTaskData compiles all three patterns into a RegexEnricher. Extractors call two methods on it: 1

• ReturnNameIfMatched — returns the label only when the regex matches (DeploymentPattern).
• ReturnNameIfOmittedOrMatched — returns the label unconditionally if no pattern is set (ProductionPattern).

Run vs. job-level matching: Workflow run extraction tests ProductionPattern against both run.Name and run.HeadBranch, so you can scope production to a branch (e.g., main) without renaming workflows. Job extraction tests job name only. 2

Refdiff Configuration#

The Refdiff JSONMap in GithubScopeConfig is injected as a separate pipeline stage after GitHub collection by blueprint_v200.go. The repoId key is auto-injected using the domain-layer repo ID. 1

Refdiff's RefdiffOptions recognises: 1

CalculateTagPattern queries all refs, applies the regex, sorts, and trims to tagsLimit. CalculateCommitPairs resolves both explicit pairs and tag-derived pairs to commit SHAs. The output — the commits_diffs table — is the join surface the DORA plugin uses to trace which commits reached production. 1

DORA Plugin Pipeline#

The DORA plugin is project-scoped and orchestrates a three-stage pipeline: 1

Stage 1 — Deployment generation

• generateDeployments — builds cicd_deployments from pipelines classified as DEPLOYMENT.
• generateDeploymentCommits — creates cicd_deployment_commits linking commits to deployments.
• enrichPrevSuccessDeploymentCommits — links each deployment commit to the previous successful one (bounds the diff range for lead time).

Stage 2 — Diff calculation

• refdiff's calculateDeploymentCommitsDiff fills commits_diffs with all commits between consecutive production deployments.

Stage 3 — Metric calculation

• calculateChangeLeadTime — joins commits_diffs with PRs to compute the lead time breakdown. Filters for PRODUCTION environment and successful result. 1
• ConvertIssuesToIncidents + ConnectIncidentToDeployment — link incidents to the nearest prior production deployment for CFR/MTTR.

Change Lead Time Decomposition#

calculateChangeLeadTime breaks the metric into four segments stored in project_pr_metrics: 3

Configuration Checklist#

To enable full DORA metrics for a GitHub repo: 1

1. DeploymentPattern — set a regex matching workflow/job names that represent deployments (e.g., (?i)deploy|release). Required; without it, no deployments are generated.
2. ProductionPattern — set to filter non-production environments (e.g., (?i)prod|main). Leave empty to treat all deployments as production.
3. Refdiff — add JSON with tagsPattern/tagsLimit/tagsOrder or explicit pairs to enable commit-diff calculation between releases.
4. CICD entities — ensure the CICD domain type is included in Scope Config entities so GitHub Actions data is collected.
5. DevLake Project — associate the repo with a project (ProjectName in DORA options); calculateChangeLeadTime filters PRs by project.

Key Source Files#