Lead time

As explained in Platform Engineering on Kubernetes

Lead time for change is the elapsed time from producing a software change to making it available to live customers.

Lead time for change measures the elapsed time between producing a software change and making it available to live customers. It is a DORA delivery-velocity metric, alongside deployment frequency, while change failure rate and time to restore service indicate recovery from failure. section 9.1

Calculating it requires joining source-code version-control events with continuous-deployment events. A standardized event model makes those signals available for metric processing across different delivery systems. section 9.2.1 section 9.2.2

A lead-time measurement pipeline typically performs these steps:

• Collect events from source-control, deployment, and other delivery systems. section 9.2.1 section 9.2.2
• Wrap non-CloudEvent data with CloudEvents SDKs before it enters the system. section 9.2.2
• Map incoming CloudEvents to CDEvents, then process the standardized data to calculate metric values. section 9.2.1 section 9.2.2
• Persist incoming data and calculations, then expose results through a dashboard. section 9.2.2

Event-based calculation

A source-code version event records when a change is produced, while a deployment event records when that change reaches a live environment. Combining the two event streams supplies the timestamps needed to calculate lead time for change. section 9.2.1

Figure 9.3 Lead time for change data sources

Use the data-source diagram to trace which delivery-system events contribute to lead time for change. section 9.1

How Platform Engineering on Kubernetes covers it

How deep it goes

Defines the interval and outlines event collection, transformation, calculation, storage, and presentation without detailing the formula.

Examples

Uses version-control events, deployment events, CDEvents mappings, PostgreSQL storage, and graphical dashboards.

What it assumes

Assumes access to source-control and deployment events, while requiring nonconforming sources to be adapted to CloudEvents.

What you can do after

Build it from CloudEvents and CDEvents by collecting, standardizing, calculating, storing, and displaying delivery data.

How it connects

Connects deployment frequency, DORA metrics, CloudEvents, CDEvents, continuous delivery, and version control.

liveBookmanning.com

Read Platform Engineering on Kubernetes on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Automating API DeliveryLead time is the elapsed time from when work becomes available to a process step until the completed work becomes available to the next step, including waiting and interruptions.
• 

  liveBookmanning.com
  Effective Platform EngineeringLead time for change is the elapsed time between initiating a software change and deploying it to production.
• 

  liveBookmanning.com
  "Looks Good to Me"The elapsed time from committing a code change until it successfully runs in production.
• 

  liveBookmanning.com
  Shipping Go: Develop, deliver, discuss, design, and go againLead time is the elapsed time from the initiation or request of work until its delivery to the customer.
• 

  liveBookmanning.com
  Architecture Modernization: Socio-technical alignment of software, strategy, and structureLead time is the elapsed time between the start of a work process and the completion or delivery of its result.

Compare how 6 books explain lead time →

Related concepts

• DORApart of · DORA is a research and measurement framework for software delivery performance, commonly using deployment frequency, lead time for changes, change failure rate, and time to restore service.
• cycle timecontrasts with · Cycle time is the elapsed time required for a work item, process, or production cycle to move from a defined start point to completion.
• queue timeused by · Queue time is the duration an entity or work item waits before receiving service or beginning processing.

This explainer was generated by Manning's knowledge graph from the text of Platform Engineering on Kubernetes. The section links point to the parts of the book it draws on.