Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Deployment frequency: count activated production changes from an event ledger

Last updated: 5 Oct 20266 min read
tutorial
AdvancedBy AITrove Editorial

A deployment-frequency measure needs a durable record of when a service change became active in production. A CI job can pass without publishing anything; a preview can deploy without serving users; and a failed production attempt may leave the old version active. Define the service boundary and count successful activations inside a fixed reporting window. Keep deployment identity, source revision, artifact digest, target environment, activation time, and result in one ledger. If a rollback activates an earlier artifact, record that as a distinct production action under the stated counting policy. Do not silently change the policy when delivery architecture moves from server releases to edge or flag-based promotion.

Operational decision

A claims portal runs 43 pipeline jobs during September. Twenty-nine attempts target production, but only 26 new states become active. Three attempts fail before traffic moves. The frequency numerator is 26 under this portal's definition; the failed attempts remain in the operational ledger for reliability analysis. A content-only release counts if it changes the production site under the same service boundary. The team records the activation timestamp from hosting control-plane evidence, not the commit time or the command invocation. It reviews the first and last day of the month in one timezone and confirms that a retry with the same deployment ID did not create a second event.

sql
SELECT COUNT(DISTINCT deployment_id) AS active_production_deployments
FROM deployment_events
WHERE service_id = 'claims-portal'
  AND environment = 'production'
  AND result = 'active'
  AND activated_at >= '2026-09-01T00:00:00Z'
  AND activated_at < '2026-10-01T00:00:00Z';

Cost and verification

With an index on service, environment, and activation time, a window query scans the matching events rather than the full ledger; DISTINCT adds work when duplicate IDs remain. A unique deployment ID at ingestion is preferable. Reporting one monthly count hides long pauses and release bursts, so inspect the timeline as well. Count user-serving activations consistently and publish the exclusions. The number should not rise merely because a pipeline retried, a preview was created, or a failed attempt produced another log row.

Common Mistakes

  • Do not count every CI run as a production deployment.
  • Do not omit failed attempts from the evidence ledger even when the frequency numerator excludes them.
  • Do not compare services with different production and activation definitions as if they share one measure.

Connected lessons

Practice and check

devops
delivery-measurement
Storage details