Change lead time: join committed work to its first live artifact

Last updated: 5 Oct 20266 min read

tutorial

Change lead time connects a source change to the first successful production deployment that contains it. A reliable calculation needs artifact lineage: commits included in the built artifact, the artifact digest promoted, and the production activation time. Rebuilding the same commit may create another artifact; redeploying an old artifact should not create a new first-live time for its commits. Commit timestamps can be backdated or affected by clock error, so record the version-control event and any timestamp correction policy. For a large batch, each included change has its own elapsed time even though all share one activation. Report a distribution rather than reducing every change to the last commit in the batch.

Operational decision

Three changes enter the mainline at 09:00, 11:30, and 15:00 UTC. The tested artifact containing all three first becomes active at 17:00. Their lead times are 8 hours, 5 hours 30 minutes, and 2 hours. The median is 5 hours 30 minutes; quoting only the 2-hour figure would hide the oldest change. If a later rollback reactivates an earlier artifact, it does not rewrite the first-live timestamp of those original commits. A correction deployed the next day is a new change with its own clock. Join the release receipt to the artifact manifest before calculating, and flag a missing commit-to-artifact edge instead of guessing.

Artifact A84 first live: 17:00 UTC
Commit 91a entered: 09:00; lead time: 8 h
Commit 72b entered: 11:30; lead time: 5 h 30 min
Commit 47c entered: 15:00; lead time: 2 h
Median of three changes: 5 h 30 min
Missing lineage: exclude with an explicit data-quality count

Cost and verification

Joining C commits to D deployment manifests can be expensive if every report recomputes artifact ancestry; persist a deduplicated commit-to-artifact relation and index it by commit and deployment. Measure ingestion gaps and impossible negative durations. Median and tail values explain the workflow better than an average alone, because one old change can dominate a batch. Keep queue, review, build, and waiting time as diagnostic sub-intervals, while the headline clock remains commit to first live activation.

Common Mistakes

Do not use merge time as a substitute for first production activation.
Do not assign a whole batch the lead time of its newest commit.
Do not silently turn a missing lineage edge into a zero-duration change.

Connected lessons

Practice and check

devops

delivery-measurement