Deployment frequency

Decide which events count

A deployment moves a version into a production environment. That is not always the same event as exposing a feature to users. A team can deploy code behind a flag and release the feature later.

Pipeline runs, deployment attempts, and completed deployments may also differ. If a pipeline retries after a temporary failure, agree on whether the records describe one intended deployment or several separate events. Keep the rule stable across reporting periods.

An illustrative calculation

Suppose one service completes 24 production deployments during a 12-day observation period. Its frequency over that period is two deployments per day.

That average does not mean it deployed twice on each day. All 24 deployments could have occurred during a small number of busy days. The underlying timeline helps distinguish a steady release practice from bursts around deadlines.

Interpret frequency with other evidence

More frequent deployments can accompany smaller changes, but a count does not reveal their size or usefulness. A series of urgent patches also increases deployment activity.

Inspect change failure rate, the nature of the releases, and the time changes spend waiting. Compare the same service with its own relevant history. Summing every microservice's deployments and comparing the total with a single mobile application's release count creates a misleading impression of relative performance.