DORA, or DevOps Research and Assessment, is a research group formed by Nicole Forsgren, Gene Kim, and Jez Humble. Acquired by Google Cloud in 2019, the DORA team established four key metrics to measure critical areas of engineering team performance. The framework also offers benchmarks for different stages of production, so that teams can check their performance against others in the industry.
DORA metrics are one tool engineering leaders can use to gain a high level understanding of outcomes, and hone in on areas of their software delivery process that need improvement. With these insights, leaders can stay up to date on SDLC (software development lifecycle) best practices, which can have a significant impact on the success of the business.
One of the four DORA metrics is Deployment Frequency, a measure of throughput that can be a starting point for examining one aspect of your engineering practices.
What is the Deployment Frequency metric?
Deployment Frequency is a measure of how often engineering teams successfully deploy code to production. As with all DORA metrics, Deployment Frequency can help leaders understand their team’s throughput and quantify how much value is being delivered to customers.
TIP: For Velocity users: use Velocity’s Deploy API to ingest data from your CI/CD tool to automate the calculation of Deployment Frequency.
Velocity uses your actual deployment data, rather than proxy data which can be error-prone, for a more accurate measurement of how often your team is successfully deploying code.
Why is Deployment Frequency important?
Deployment Frequency tracks how quickly teams can release new features or fixes, helping engineering leadership benchmark how often the team is able to get work out and receive actionable feedback from end-users.
Innovating quickly is the key to maintaining a competitive edge over other organizations. Deployment Frequency gives engineering leaders a clearer understanding of how often their customers are receiving updates to the products on offer.
Tip: For Velocity users: Use our Application functionality to associate repositories and teams to an Application. This allows users to filter and group deploys by Application and Team, making it easier to identify areas of improvement within your organization.
How to improve Deployment Frequency
If your team is deploying less than multiple times per day, it’s time to focus on improving your Deployment Frequency metric. Look for opportunities to release smaller changes or new components in isolation. An ideal time to identify this is during refinement sessions or planning sessions for a sprint. You can even set the goal of a sprint to be a smaller unit of the overall functionality.
Low Deployment Frequency can indicate that PRs, or units of work, are too large. To improve this, leaders can look at the PR Size metric. If PR Size is too large, leaders can coach teams to practice good coding hygiene and break work into smaller units. Top performing engineering organizations keep PRs to less than 140 lines of code.
Low Deployment Frequency could also indicate unnecessary or complex barriers to releasing to a production environment, like inefficiencies in the CI/CD pipeline, or requiring sign-off from a team member who’s unavailable. To attempt to remove these blockers, start by running focused retrospectives with the engineering teams to identify areas that could be improved or blockers that could be removed entirely. Improvements to automatic testing and validation of new code can also help to increase Deployment Frequency.
Lack of confidence in the stability of the functionality being produced could also be a barrier to deployment. To build confidence in new deliveries, engineering leaders can push for higher test coverage and improve Mean Time to Recovery, a DORA metric that focuses on the team’s ability to recover from incidents in production environments.
What is a good Deployment Frequency?
According to benchmarks determined by DORA through surveys of over 35,000 organizations (varying in size and industry) high-performing teams are able to deploy on-demand, meaning they deploy multiple times per day. The higher your Deployment Frequency, the more often code is going out to end users. Teams are considered medium-performing if they deploy between 1 week and one month.
Using this rubric, engineering leaders can determine where they fall among competitors. Engineering leaders can use Deployment Frequency to figure out which software teams are excelling within the organization, and apply their best practices across other teams. You can also benchmark your team against itself to measure progress over time, and see whether changes you’re implementing have the desired effect on your Deployment Frequency.
Putting Deployment Frequency into Context
As with all metrics, Deployment Frequency should be considered in the context of other data. Other DORA metrics, like Change Failure Rate, can tell you about the quality of your team’s deployments, while Mean Lead Time for Changes offers insight into your team’s efficiency. It’s important not to optimize for a single metric, but instead to strike a balance between speed metrics and stability metrics.
With Velocity’s Analytics module, engineering leaders can view multiple metrics in tandem to see how they affect one another in real time. To gain even more actionable insights, you can view DORA metrics with key, non-DORA engineering metrics.
For example, if your Deployment Frequency is low, you might want to start by viewing it alongside PR Size, which is the number of lines of code added, changed, or removed.
You might notice that the larger the PR Size, the lower a team’s Deployment Frequency, which offers concrete reasoning for developers to submit smaller PRs. While a correlation between these metrics is not diagnostic, it does offer engineering leaders a starting point to investigate a low Deployment Frequency, and identify necessary changes to processes.
If an engineering team demonstrates a favorable correlation between Deployment Frequency and PR Size, or another metric, engineering leaders have incentive to scale that team’s best practices across the organization.
Communication is Key
Engineering leaders should use objective data like DORA metrics as a starting point to identify opportunities for improvement. Only by talking with developers and looking at data holistically can you make lasting improvements to your delivery and processes.
DORA metrics can also be shared to communicate progress towards goals with broader leadership; they are great introductory metrics to share with technical and non-technical executives.
To learn more about how DORA metrics can help your team streamline and enhance delivery, speak with a Velocity Product Specialist.
Get articles like this in your inbox.
Trending from Code Climate
Engineering Leaders Share Thoughts on Leadership in Disrupted Times in a New Survey
For engineering teams, disruption to the business can have a significant impact on the ability to deliver and meet goals. These disruptions are often a result of reprioritization and budget changes on an organizational level, and are amplified during times of transition or economic instability.
Built In’s 2023 Best Places to Work — Why Code Climate Made the List
At Code Climate, we value collaboration and growth, and strive for greatness within our product and workplace. For us, this means fostering a supportive, challenging, people-first culture. Thanks to an emphasis on these values, we’ve earned spots on three of Built In’s 2023 Best Places to Work awards lists, including New York City Best Startups to Work For, New York City Best Places to Work, and U.S. Best Startups to Work For.
Turnkey Deployment Delivers Day-One Value for Yottaa
Learn how Yottaa gained immediate value from Code Climate Velocity right out of the box.