Deployment Frequency (Custom)

1 Context
2 Description
3 Configuration
4 Code
5 RAG Thresholds
6 Drill-down
7 Aggregation
8 How to increase Deployment frequency

Context

In a nutshell, Deployment frequency measures how often code is deployed to production. This metric correlates with both the speed and the quality of your engineering team.

“Reducing batch size is another central element of the Lean paradigm - indeed, it was one of the keys to the success of the Toyota production system. Reducing batch sizes reduces cycle times and variability in flow, accelerates feedback, reduces risk and overhead, improves efficiency, increases motivation and urgency, and reduces costs and schedule growth. However, in software, batch size is hard to measure and communicate across contexts as there is no visible inventory. Therefore, we settled on deployment frequency as a proxy for batch size, since it is easy to measure and typically has low variability.”

Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations

Description

This metric will show how many releases are completed within a month.
This metric is based on Jira/Azure Boards/Rally data. The main pre-requisite is to have actual fix versions with correct release dates.
The current interval starts from today - interval duration (1 month/quarter). It's done to make a smooth transition from previous interval to the current one (especially when month/quarter just started). Example: Today is 5 Jan. If release interval is a month, then Jan bar will contain releases from 5 Dec up till now.

Configuration

We have 4 variables in the code of this metric:

Number of intervals to show. Basically, how many bars do you want to see on the chart? Default is 9
Interval type. If you don't release too often you probably don't want to see gaps for some months - so it's better to set interval type to quarters. As an example, if there was 1 release in Jan, none in Feb and 2 in Mar - you will get 1 release per month in Q1. Default: month.
Include hotfixes. If you don't want to include hotfix releases in this metric, please set 0 here. The default is 1.
Hotfix criteria. The criteria to distinguish hotfixes from regular releases. Default: there are "hot" and "fix" strings in either name or description of the release OR the patch version (if release name is in MAJOR.MINOR.PATCH format) is not equal to 0. Please set your own hotfix criteria for release used on your project.

Code

Here is the code of the metric:

with number_of_intervals_to_show as
(
select 9 --how many time intervals to show on the chart
as show
),

interval_type as
(
select 1 --1=month, 2=quarters
as i_type
),

include_hotfixes as
(
select 1 --1=hotfix releases included in calculation, 0=hotfix releases removed
as hf_included
),

hotfix_criteria as --criteria for hotfix releases
(
select id from release
where (lower(name) like '%hot%' and lower(name) like '%fix%')
or (lower(description) like '%hot%' and lower(description) like '%fix%')
or (name like '%.%.%' and name not like '%.%.0%')
),

interval as --preparing intervals (months or quarters)
(
select * from
(
select now() as i_finish, now()-interval '3 month' as i_start, 2 as type
union
select
(date_trunc('quarter', now()) - interval '3' month* generate_series(0,(select show from number_of_intervals_to_show)-2))-interval '1 second' as i_finish,
(date_trunc('quarter', now()) - interval '3' month* generate_series(0,(select show from number_of_intervals_to_show)-2))-interval '3 month' as i_start,
2 as type
union
select now() as i_finish, now()-interval '1 month' as i_start, 1 as type
union
select
(date_trunc('month', now()) - interval '1' month* generate_series(0,(select show from number_of_intervals_to_show)-2))-interval '1 second' as i_finish,
(date_trunc('month', now()) - interval '1' month* generate_series(0,(select show from number_of_intervals_to_show)-2))-interval '1 month' as i_start,
1 as type
) as temp
where type=(select i_type from interval_type)
),


releases as --selecting releases for each interval
(
select case when (select i_type from interval_type)=1 then to_char(i_finish, 'YYYY MM')
else to_char(i_finish, 'YYYY "Q"Q') end as timeline,
a.*
from interval
left join release a on a.finish_date>=i_start and a.finish_date<=i_finish
and ((select hf_included from include_hotfixes)=1 or a.id not in (select id from hotfix_criteria))
)

select
timeline::varchar as timeline,
case when (select i_type from interval_type)=1 then count(id)
else count(id)/3.0 end as deployment_frequency
from releases
group by timeline
order by timeline asc

RAG Thresholds

RAG thresholds:

RED: 0 releases per month
AMBER: 1-4 releases per month
GREEN: 5+ releases per month

That corresponds to 2022 Google's State of DevOps Report: https://services.google.com/fh/files/misc/2022_state_of_devops_report.pdf

Drill-down

Drill-down query to show Release Name, Release Date & Description:

select
name as "Release Name",
finish_date as "Release Date",
description as "Description"
from releases
where timeline=clicked_x_value
order by finish_date desc

Aggregation

If you have several teams and you want to see the Deployment Frequency across all your teams, here is an example of how to do that.

Aggregation dataset:

Aggregation metric's code:

select timeline, avg(deployment_frequency) as "Average Deployment Frequency (per month)"
from DORA_Deployment_Frequency
group by timeline
order by timeline asc

As a result, you will see the average deployment frequency for all your teams.

In the drill-down you will have the deployment frequency values for each team. Here is the code:

How to increase Deployment frequency

If you're not in a GREEN zone for this metric, please consider the following ways to increase your deployment frequency:

Implement CI/CD best practices: continuous integration and continuous delivery allow you to increase your software delivery speed.
Work on small and self-contained changes: working with smaller versions of changes makes it easier for developers to get feedback faster and resolve issues sooner.
Work on reducing your technical debt: an effort to reduce technical debt and remove bugs can help you increase subsequent deployments.
Use test automation: incorporating automated tests at every stage of the CI/CD pipeline can help you reduce delivery times since it helps catch issues earlier.
Use release trains if you are working on larger monoliths: multiple changes are batched together, coordinating changes to be released at the same time.