What is Deployment Frequency & How is It Measured?

What is deployment frequency?

Deployment frequency is how often code changes are deployed to production. These changes can include bug fixes, new versions, enhanced capabilities and new features. By better understanding how often changes are shipped, the organization can better predict future delivery timelines for new or enhanced features. By tracking deployment frequency, organizations can gauge a team’s speed and agility. It’s important because it shows how much value teams can deliver to the end users.

Deployment frequency is a metric that has been long used in the software development space - first coming into prominence with the emergence of DevOps, and then being included as a key metric in the DevOps Research and Assessment (DORA) team’s framework, which aimed to help DevOps and engineering leaders improve the way they measured software delivery efficiency - deployment frequency is a ‘velocity’ metric. DORA also raised the bar on what it deemed was acceptable deployment frequency.

Now, with many teams shifting to platform engineering, deployment frequency is still considered a reliable metric to use, with slowdowns in deployment frequency often correlating with issues in developer experience, developer productivity, and developer tools, all of which are front of mind in the platform engineering space.

Organizations’ deployment frequency will vary; with some teams deploying code monthly, weekly or even multiple times every day.

How to measure deployment frequency?

Simply counting the number of deployments - no matter how small (a new feature) or big (a quick bug fix) - made in a particular time frame. This can be measured on a per week or per day basis. That means that if in any given month you had weeks where you deployed 3 times, 7 times, 6 times, and 8 times, then the average per week would be 6. There isn’t a hard or fast rule for calculating deployment frequency, but companies can use analytics tools to measure it.

What is a good deployment frequency?

The DORA team had studied thousands of software engineering companies in a six-year program to better understand what metrics engineering teams should evaluate themselves with, and to get to grips with the differences between high-performing and low-performing teams.

The latest benchmarks are as follows:

Elite performers: On-demand or multiple deploys per day

High performers: Once per day to one per week

Medium performers: Once per day to once per month

Low performers: Once per day to once per month

High performers will make multiple deployments per day or be able to do so ‘on-demand’, while lower performing teams may only deploy once per month.

However, it’s worth noting that different organizations will have their own benchmarks based on their own operational goals, the complexity of projects they work on, and the maturity of their engineering teams. Teams should have a baseline from which to compare with.

Importance of deployment frequency

Deployment frequency is an easy metric to measure and yet it can provide teams with a lot of power.

Deployment frequency can be a metric you use to evaluate your team’s strength in being agile and responsive to feedback. It can also ensure continuous delivery; keeping your engineering team on track to deliver frequent deployments, and ultimately provide end users with the features, fixes and updates that they need.

Perhaps most importantly, deployment frequency can indicate whether there are issues with existing systems, processes or even personnel. In contrast, it can indicate when the environment is highly functional. Either way, it provides a basis for engineering leaders to investigate further, and try to either fix issues or ensure that certain methods or systems are always used because they provide good results.

Strategies to improve deployment frequency

Create an end-to-end experience for your developers to improve deployment frequency. For example, you could consider how your team currently brings a feature to production and break the process down into smaller steps, optimizing each step.
In this example, you could enable a user to ‘scaffold a new service’ as a self-service as a start. Then, in order to streamline the entire process, you could provide self-service actions to spin up a developer environment, send a reminder to review a PR, or rollback to a previous version.
Set goals for teams on the deployment frequency per week. This goal should be a realistic target that the team can achieve.
Make small changes by reducing the deployment size. This reduces the likelihood of deploying bugs. Developers are more likely to understand the issue at hand and can roll back any changes.
Establish a clear environment - a software catalog can enable developers to quickly access the information they need about any given service including versions, owners, dependencies and permissions. This means they can get to work without needing to switch between different tools to find what they need, enabling them to deploy more often.

Deployment frequency pitfalls

‍

There are some instances where you may see high deploy counts which don’t actually reflect a highly functional team or environment, but are because of other reasons. These could be:

Gaming the system
Developers that believe they’re under pressure and are being measured by their deployment frequency, may want to ‘game’ the system’. That means they may more frequently push code.
Inconsistent processes
Inconsistencies through siloed teams using different practices to break up their code, and therefore in some instances, some teams are shipping an unusually large number of small changes.
Complexity dictates frequency
Complex projects may require many bug fixes and deploys, but this doesn’t necessarily mean that the code quality is good, and therefore, it doesn’t guarantee that the deployment frequency is down to a well-functioning team.

Deployment frequency is an important metric that many engineering teams currently use to help them to measure developer productivity. But it is just one metric, and engineering teams ought to be using a range of metrics to determine developer productivity and developer experience. Depending on the organization, there may be other objectives that the team wants to accomplish such as better compliance and security, standardization and meeting SLAs/SLOs. These objectives would require measuring and monitoring other types of metrics.

Find out more about developer experience metrics here.

Book a demo right now to check out Port's developer portal yourself

Book a demo

It's a Trap - Jenkins as Self service UI

How do GitOps affect developer experience?

It's a Trap - Jenkins as Self service UI. Click her to download the eBook

Download eBook

Learning from CyberArk - building an internal developer platform in-house

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}

Microservices SDLC

Scaffold a new microservice
Deploy (canary or blue-green)
Feature flagging
Revert
Lock deployments
Add Secret
Force merge pull request (skip tests on crises)
Add environment variable to service
Add IaC to the service
Upgrade package version

Development environments

Spin up a developer environment for 5 days
ETL mock data to environment
Invite developer to the environment
Extend TTL by 3 days

Cloud resources

Provision a cloud resource
Modify a cloud resource
Get permissions to access cloud resource

SRE actions

Update pod count
Update auto-scaling group
Execute incident response runbook automation

Data Engineering

Add / Remove / Update Column to table
Run Airflow DAG
Duplicate table

Backoffice

Change customer configuration
Update customer software version
Upgrade - Downgrade plan tier
Create - Delete customer

Machine learning actions

Train model
Pre-process dataset
Deploy
A/B testing traffic route
Revert
Spin up remote Jupyter notebook

Engineering tools

Observability
Tasks management
CI/CD
On-Call management
Troubleshooting tools
DevSecOps
Runbooks

Infrastructure

Cloud Resources
K8S
Containers & Serverless
IaC
Databases
Environments
Regions

Software and more

Microservices
Docker Images
Docs
APIs
3rd parties
Runbooks
Cron jobs

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start

What is deployment frequency and how is it measured?