Skip to main content

Module delivery_metrics

Module delivery_metrics 

Expand description

delivery-metrics analysis — repo-level delivery flow distributions.

Computes six percentile distributions that describe how code moves from branch to mainline, sliced as percentile-first (p50/p75/p90) summaries (DORA 2025 convention). The analysis requires the commit_parents table (schema v4) which records parent revisions and their position; merge commits are identified as those with a position=1 row.

§Metrics

  • batch_size_files — distinct paths touched by the branch-side commits bundled into each merge unit. A proxy for PR size.
  • batch_size_loc — total loc_added + loc_deleted across the branch-side commits. Complements the file count with raw churn size.
  • branch_duration_hours — wall-clock hours between the earliest branch-side commit’s author-date and the merge commit’s date. Measures how long branches stay open before integration.
  • rework_pct — percentage of added lines that were subsequently deleted or overwritten within opts.rework_window_days on the same path. Window is anchored to MAX(date) across all commits so only recent activity is examined. Computed via hunk-pair overlap (approximate — line drift between commits is not tracked). Both sides of the self-join are pre-filtered to the window (bounds the cross-product); the denominator is the total lines added in the window, independent of the pair join.
  • lead_proxy_hours — per-commit date_diff('hour', author_date, committer_date), positive values only, over non-merge commits. Uses the same author/committer semantics as crate::analyses::lead_time: commits.date is the author date; commits.committer_date is when the commit entered mainline. On squash-merge workflows the delta is small; on merge-via-merge-commit + review workflows it reflects the in-review time.
  • landed_by_other_pct — percentage of non-merge commits where committer_email (case-normalized) differs from author_email: a validated proxy for “someone other than the author landed this” — peer-applied patch, rebase-merge, or bot landing (Rigby & German 2008; later pull-based-development gatekeeper studies). Single-aggregate row (p50 == p75 == p90), mirroring rework_pct’s shape. Caveat: commits carries author_name but no committer_name, so unlike canonical_author the committer side cannot be mailmap-resolved — a person authoring and landing under two emails they both own registers as a false “gatekept” commit. Not ownership-grade signal; see the row’s caveat field.

§Squash detection

If the number of merge commits is fewer than 3 AND the total number of non-merge commits exceeds 50, the repo is likely using a squash or rebase workflow. The analysis emits a tracing::warn! and still produces rows with n as-is (branch metrics will be noisy in that case).

§Relationship to existing analyses

  • crate::analyses::lead_time — per-commit row; this analysis summarises the same signal as percentile distributions.
  • crate::analyses::delivery_friction — per-FILE composite metric (churn × lead-time × cognitive). Complementary, not overlapping: this analysis is repo-level distributions, not per-file scores.

Structs§

DeliveryMetricsRow
One row in the delivery-metrics output.

Functions§

run_delivery_metrics
Run the delivery-metrics analysis against the already-ingested fact store.