Deployment Frequency

A product team ships a large update every few months while another releases small changes several times a week, and deployment frequency describes that cadence. It does not by itself say which team serves users better or which releases are safe.

DORA lists deployment frequency as either the number of deployments in a period or time between deployments, and Google Cloud's Four Keys guidance explains that its frequency bands are not simply a count of daily releases and discusses what qualifies as a successful production deployment. The definition should match the team's delivery process, so choose the production service or application, because a company-wide aggregate can hide one service that releases rarely.

Define a qualifying production deployment, since a staging test or code merge is not necessarily a release used by customers, and decide whether a small canary counts, stating the threshold if the team releases to only a fraction of traffic. A feature flag can decouple code deployment from customer exposure, so decide whether the measure tracks production code or feature activation.

For a simple count, 20 qualifying releases over four weeks average five deployments per week, which is not the same as deploying on five separate days. A frequency-band approach can use the interval between release days, as in some DORA implementations.

Define how redeploying the same version is handled, since a retry due to a failed pipeline may not represent a new change for users, document the timestamp convention because deployments near midnight can fall in different reporting days across regions, and use a period long enough to see a pattern, since a holiday freeze can lower a weekly count without a lasting change. Automated pipelines can make releases easier, but automation alone does not guarantee correctness, and small, frequent changes may be easier to diagnose and reverse only when testing, observability and disciplined rollout are in place.

A low rate may indicate long approval queues, technical coupling or deliberate caution for a high-risk service, whereas a high rate may include repeated hotfixes and should not be celebrated if users are repeatedly disrupted. Distinguish a planned release from an emergency repair, and report both if the mix affects interpretation.

Pair deployment frequency with change failure rate and recovery time, since throughput and stability belong in the same review, and check lead time from code to production where useful, because a team can deploy often but still leave individual changes waiting for weeks. Avoid counting only successful releases in one month and all attempts in another, and track failed or rolled-back deployments separately, even if they are excluded from a success-based frequency metric.

Segment by service maturity, since a new prototype and a regulated payment system may have different risk controls, and consider release size, because ten tiny configuration changes are not directly comparable with ten major migrations. A manager should ask what blocks safe delivery: tests, approvals, integration dependencies or capacity, rather than pressuring teams to split changes merely to increase the metric, and should annotate the metric when the release process changes, because a new automated counter can make historic values incomparable.

Continuous delivery can reduce long-lived branches but requires clear ownership of production quality, and user outcomes such as incidents, performance, support contacts and adoption of shipped improvements show whether the changes helped. The measure is a conversation starter about release capability, not a target to maximise at any cost.