--- title: "DevOps Metric: Frequency of Releases Definition" url: "https://pipelinedriven.org/article/devops-metric-frequency-of-releases-definition.md" canonical: "https://pipelinedriven.org/article/devops-metric-frequency-of-releases-definition" published: "2016-10-29T08:59:27.165000+00:00" updated: "2016-10-29T08:59:27.243000+00:00" tags: [] author: "Roy Osherove" description: "Important to : Release Manager, CIO Definition : How often an official release is deployed to production, in paying customer's hands How to measure : If no…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # DevOps Metric: Frequency of Releases Definition 29 October 2016 · 2 min read · Roy Osherove - **Important to**: Release Manager, CIO - **Definition**: How often an official release is deployed to production, in paying customer's hands - **How to measure**: If no pipeline: release schedule. Otherwise, history data for Pipeline Production deploy step. - **Expected outcome**: The time between releases should become shorter and shorter (in some cases an order of magnitude shorter) as DeOps maturity grows. It's one thing for the IT of an organization to create pipelines so fast that they can release at will. The other side of that coin is that of the business.  ``` If IT is no longer a bottleneck, it is the business' responsibility to decide *when* to release new versions. ``` In traditional organizations IT is usually too slow to supply and deploy the release as fast as the business requires, so the business is forced to operate at the speed of IT , which might mean 4 release a month, 4 releases a year or even less frequent.  In a DevOps culture, every code check in (A 'commit') is a potentially releasable product version, assuming it has passed the whole continuous delivery pipeline all the way up to the staging servers.  We can use the "Frequency of release metric to decide "how many releases do we want to do per year, month, week?" We can then measure our progress.  As IT becomes faster, we can cut down our scheduled release time. As the pipeline supports more and more automated policy and compliance checks as feedback cycles, more time is removed from manual processes and potential releases become easier to achieve. The question "_How often should we pull the trigger to deploy the latest potential release that has passed through the pipeline?_" shifts from becoming IT's problem to being owned solely by business stakeholders. As the schedules become more frequent, the competitiveness in the marketplace becomes better. In some organizations (Netflix, or Amazon are a good example), the decision on a release schedule is removed completely and only the pipeline's "flow" of releases that automatically get deployed determines the release frequency, which might happen as often as every minute or even less. --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/