Deployment frequency is one of the four key DORA metrics, and serves as a quick yet accurate way to measure throughput. Tracking deployment frequency helps your team benchmark their current performance, and set attainable, incremental velocity goals.
What is deployment frequency?
Deployment frequency is a measure of how often your org pushes code to production. DORA usually counts deployment frequency as the length of time between deployments, e.g. one hour, one day, etc.
Both deployment frequency and lead time for changes measure engineering velocity. These two metrics assess the level and quality of DevOps automation in your org: as more CI/CD tasks are automated, deployment frequency goes up, and lead time goes down. This is because human intervention/review tends to be the biggest blocker during the deployment process.
Inner loop development work will also have an impact on deployment frequency: if features trend towards longer cycle times, you're pushing fewer features. However, by improving your DevOps automation, your cycle time will also go down. Getting more feedback or running tests during feature development cuts down on unnecessary wait time, so updates/fixes can happen sooner.
How to measure deployment frequency
Deployment frequency is the easiest DORA metric to measure: simply average the number of pushes to production over the most appropriate time interval.
Your resulting metric will be along the lines of:
- twice per week
- three times per day
- once per month
And that’s it — measuring deployment frequency, at least formulaically, ends up being as simple as it sounds. The lift here is actually aggregating all the relevant data.
The best way to start measuring deployment frequency is by recording your deployment data over a span of several months. Many teams benefit from tracking deployment frequency changes over time — how does it improve/plateau/regress on a monthly or quarterly basis? Did onboarding five new team members hinder your frequency? Is your DevOps automation not able to keep up with a higher volume of throughput?
While you can do these calculations by hand, automating this is straightforward with most source code management (SCM) providers.
With GitHub
If you’re using GitHub’s Deployment feature for production releases, you can use GitHub’s REST API to collect deployment events. At minimum, you’ll want to record timestamps for when each deployment was created and/or modified, and filter for successful deployments only.
GET /repos/my-username/my-project/deployments
With GitLab
GitLab offers a designated Deployment API. A simple call returns all deployments for a given project, along with their timestamps. Results can be filtered to include only successful deployments.
GET /projects/:id/deployments
For Ultimate subscribers, GitLab offers a DORA metrics API, where you can directly request DORA deployment frequency.
GET /projects/:id/dora/metrics
What is a good deployment frequency?
DORA classifies Elite-performing teams as having a deployment frequency of multiple times per day, or “on demand”. About 19% of teams have Elite DORA deployment frequency. Many of these orgs have successfully implemented enough automated checks to make this possible — there’s enough trust in their pipelines that they can deploy with confidence (and on-demand) once something passes all stages. High performers have a deployment frequency between once per day and once per week, and they constitute 22% of respondents.
Like with all DORA metrics, your team’s optimal deployment frequency might not mirror that of other orgs. For example, if security is extremely critical to your application, a deployment frequency of less than a day might be hard to achieve: your ideal deployment pipeline might require too many reviews and processes for you to realistically ship PRs that often.
As DORA’s 2024 report explains:
“Improving should be more important to a team than reaching a particular performance level. The best teams are those that achieve elite improvement, not necessarily elite performance.”
Trying to improve deployment frequency?
Staging bottlenecks are one of the biggest inconveniences to smooth deployments. When there are only a few staging environments, it becomes harder to test and review features in a timely manner. That’s where ephemeral environments come in — they boost your deployment frequency since they give you the infrastructure you need to E2E test every single feature on the spot. That’s why teams that use Shipyard see 3.2x more developer velocity. If you’re trying to improve your DORA metrics without too much engineering lift, ephemeral environments might be the perfect starting point.
Top comments (0)