This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

title
Analysis 2: Delivery metrics plan

DORA metrics in brief

• Deployment frequency: How often changes are released to production.
• Lead time for changes: How long a change takes from its first commit to production.
• Change failure rate: The percentage of production changes that cause a failure, rollback, hotfix, or incident.
• Time to restore service: How long it takes to recover after a production failure.

Metric	Proxy event in phase 1	Where the data comes from	How the proxy differs from the real metric	Phase 2 definition
Deployment frequency	A merge request is merged into main. For per week- Count all merged requests and divide by project age in weeks, using created_at.	Using GitLab's API, loop pagination on this GET request: https://gitlab.cs.ut.ee/api/v4 /projects/{id}/merge_requests? state=merged&scope=all& target_branch=main& per_page=100&page=1 Where: {id}: numeric project ID (discourse: 6766, frontend: 6765, backend: 6763)	This measures code integration, not a production deployment. It can count changes that are merged but never released, and one merge can contain several changes.
Lead time for changes	Measure from the earliest commit to the merge. For time in hours- Collect commit created_at values and the merge request timestamp merged_at; average the non-negative differences in hours.	Using Gitlab's API, loop pagination on this GET request: https://gitlab.cs.ut.ee/api/v4 /projects/{id}/merge_requests /{iid}/commits?per_page=100& page=1 Where: {id}: numeric project ID (discourse: 6766, frontend: 6765, backend: 6763) {iid}: the merge request number within that repository. For merge request !42, use 42 in the URL. (you get this from the Deployment frequency request results)	This captures coding and review time up to the merge, but ends at repository integration rather than production. It excludes deployment, release, and operational time after the merge.
Change failure rate	Collect pipeline status and created_at, and merge request merged_at. Check passed/failed runs for the merged commit on main at or after the merge. Failure rate = changes with any failed run / changes with a passed or failed run × 100. Count each change once.	Using Gitlab API, loop pagination on this GET request: https://gitlab.cs.ut.ee/api/v4 /projects/{id}/pipelines? ref=main&sha={sha}& per_page=100&page=1 Where: {id}: numeric project ID (discourse: 6766, frontend: 6765, backend: 6763) {sha}: the unique identifier of the merged commit, used to find its pipelines. (you get this from the Deployment frequency request results)	This counts post-merge CI failures; it cannot detect production failures because no production deployment exists yet. It may also count a broken pipeline or infrastructure problem as an application change failure. Feature-branch failures are deliberately excluded.
Time to restore service	Not measurable in phase 1.	No GitLab deployment, incident, or monitoring record currently identifies both an outage start and a restoration event; pipeline and job pages provide CI timestamps only.	Without a production outage start and a service-restored event, any duration would be invented and would not represent recovery time.