Metrics and queries for delivery

Frequency and failure rate together

Deployment frequency alone is gameable — deploy more often, achieve nothing. Paired with change failure rate it becomes meaningful: rising frequency with flat failure rate is genuine improvement; rising frequency with rising failure rate is recklessness.

The pairing exists because the two are in tension, and reporting either alone invites optimising it at the other's expense.

Small batches

Frequent deployment tends to reduce risk rather than increase it, because each release contains less change. A smaller change is easier to review, easier to attribute when something breaks, and easier to reverse. That is the counter-intuitive result worth carrying into a scenario question: the team deploying monthly is usually taking more risk per deployment than the team deploying daily.

Recovery over prevention

Time to recovery is often the more actionable target. Failures will happen; halving recovery time is usually cheaper and more reliable than trying to halve failure rate, and the two combine — frequent small deployments with fast rollback produce short outages.

Primary sources

• https://learn.microsoft.com/en-us/azure/devops/report/dashboards/dashboards
• https://learn.microsoft.com/en-us/azure/azure-monitor/overview