DORA Metrics — Deep Dive

Deployments in last 30 days / 30

Today:
  - 1 deployment per month
  - Large batch: 50+ commits
  - Manual smoke tests

Target (6 months):
  - 3 deployments per week
  - Batch: 5–10 commits per deploy
  - Automated E2E tests in pipeline

Tools:
  - GitHub Actions / GitLab CI for automation
  - ArgoCD / Flux for GitOps sync
  - Helm for repeatable deployments
  - Feature flags (LaunchDarkly, Split.io)

Sum of (deployment_date - commit_date) for all commits in period / number of commits

Current state:
  - Code review: 8 hours (reviewer capacity)
  - Build + test: 45 min
  - Deploy to staging: 30 min (manual approval)
  - Staging validation: 4 hours (manual QA)
  - Deploy to prod: 2 hours (change advisory board approval)
  Total: ~15 hours median; outliers 2–3 days

Target state:
  - Code review: 30 min (team norm: "review within 30 min")
  - Build + test: 15 min (parallelize; cache; prune slow tests)
  - Deploy to staging: 5 min (fully automated)
  - Staging validation: 5 min (automated smoke tests)
  - Deploy to prod: 5 min (GitOps auto-sync; no approval for low-risk changes)
  Total: ~60 minutes

(Incidents caused by deployments + Rollbacks) / Total deployments × 100

Root causes of failures:
  - 50% API contract breaking changes → add contract tests
  - 25% Database migration issues → test schema changes in staging; use feature flags for gradual rollout
  - 15% Configuration mistakes → store config in GitOps; review diffs
  - 10% Concurrency bugs → add chaos tests; load testing

Actions:
  1. Add contract tests (Pact) to CI/CD
  2. Implement canary deployments (ship to 10% of traffic first)
  3. Set up automated monitoring → trigger rollback if error rate > 2%
  4. Use feature flags for data migration rollouts

Sum of (incident_resolved_time - incident_detected_time) / number of incidents

Current incident flow:
  - Issue occurs (02:00 AM)
  - Customer reports problem (02:15)
  - On-call paged (02:30)
  - On-call diagnoses via logs (02:45–03:15) — 30 min troubleshooting
  - Root cause: database connection pool exhausted
  - Manual fix: scale DB, restart app (03:15–03:45)
  - Verify fix; customer impacted 1.75 hours
  - Post-mortem: "We need better alerting"
  MTTR: 1.75 hours

Target incident flow:
  - Issue occurs (02:00 AM)
  - Monitoring detects elevated error rate (02:01)
  - Alert sent; on-call paged (02:02)
  - Observability dashboard shows: "DB connection pool utilization 95%"
  - Automated response: HPA scales replicas (02:03)
  - Issue resolved; customer impact < 2 minutes
  - Runbook auto-triggers: scale DB (02:04)
  - Post-mortem: "HPA needs to account for connection pool; increase pool size"
  MTTR: 2–4 minutes

Current State (Month 1):
  Deployment Frequency: 0.5/week (2–3 per month)
  Lead Time: 7 days average
  Change Failure Rate: 35%
  MTTR: 4 hours

Targets (12 months):
  Deployment Frequency: 1–2/week (High)
  Lead Time: < 24 hours (High)
  Change Failure Rate: < 30% (High)
  MTTR: 2 hours (High)

Stretch (18 months):
  Deployment Frequency: 3+/week (Elite)
  Lead Time: 1–4 hours (Elite)
  Change Failure Rate: < 15% (Elite)
  MTTR: 30 min (Elite)

graph TD
    DF[High Deployment Frequency] --> V["Fast Value Delivery"]
    LT[Low Lead Time] --> V
    CFR[Low Change Failure Rate] --> Q["High Quality"]
    MTTR[Low MTTR] --> R["High Resilience"]

    V --> B["Revenue Growth<br/>Customer Satisfaction"]
    Q --> B
    R --> B

    B --> E["Employee Satisfaction<br/>Retention"]