Internal developer portal

How to improve DORA metrics with an internal developer portal

September 12, 2024

Jenna Danoy
Jenna Danoy
How to improve DORA metrics with an internal developer portal
Example H2

Ready to start?

DORA metrics help you gauge the performance and efficiency of your teams and build a strong, productive work environment.

Internal developer portals allow you to track DORA metrics and drive continuous change using working agreements to build good engineering habits.

In this post, we’ll discuss how an internal developer portal can improve DORA metrics by:

  • Using working agreements
  • Using developer self-service and an improved developer experience
  • Driving better standards to improve software quality and compliance 

Using working agreements in an internal developer portal

What are working agreements?

Working agreements are like rules of engagement for engineering teams. You likely already have expectations of your teams about the speed and quality of their work — working agreements help developers build better habits around working as a team. 

Outside of supporting the speed of development and quality of code, you can use working agreements as examples of how developers should work together to be most efficient and mindful of other developers. 

Create working agreements

Working agreements can improve developer satisfaction or speed up the deployment process, but they won’t mean anything if your teams aren’t involved in the process of creating them. You and your teams will need to work together to determine what needs to be improved, and how exactly this gets reflected in your portal. 

These are some typical issues that working agreements address:

  • Average or recommended pull request size, in lines of code
  • Long wait times for PR review
  • Code quality and formatting rules, such as using specific linters

Start by surveying your teams about their expectations and pain points. Pull any common themes from the relevant developer survey results (if you do them) and use them as a guide to draft your working agreements. 

Use developer self-service actions to improve DORA metrics 

Developer self-service actions are a cornerstone of every internal developer portal. Without them, it’s impossible to abstract away the complexity of cloud technologies, provide guardrails for development, or build golden paths for developers.

Self-service actions abstract away the nitty-gritty of interacting with complex deployment environments, cloud technology, and more. They are essentially a UI for developers built by platform engineers according to engineering standards and the golden paths required by the organization.

Let’s consider the path through which developers must go to deploy a new microservice:

Steps to deploying a new microservice

As you can see, each step is complex enough to have developers get stuck, or need to guess what they should do. This slows them down. 

This leaves developers frequently needing to submit tickets to DevOps for support, which affects DORA metrics by increasing time to deployment.

The solution for this is developer self-service actions — they are the golden paths and have baked-in standards. After platform engineers integrate all of their services into the portal, they can create a UI similar to a submission form with fields for a developer to fill out:

An example self-service action for creating a new developer environment

Each self-service action is completely customizable — you can build forms or wizards, use steps, require different inputs, and validate them. In the context of our earlier example, self-service actions boost DORA metrics by providing developers autonomy. No waiting, no confusing environments, just code and deploy. 

Drive standards compliance to reduce MTTR and improve reliability

Scorecards, like self-service actions, are a key part of an internal developer portal. Without them, it would be difficult to grade the health and standards compliance of each service or element of your software catalog.

Scorecards can ensure developers know that PRs must be reviewed on time as part of meeting DORA metrics, or outline the proper configuration for a service to be production-ready. 

There are two specific DORA metrics that scorecards address: reducing mean time to recovery and improving reliability of the software.

Reducing mean time to recovery

For every service in the software catalog, platform engineers can set up scorecards to alert asset owners if rules aren’t met and generate tasks to bring a service back on track. The alert can describe the issue that needs to be addressed and set a deadline for the task to be completed. 

This reduces lag time and removes the need for a manager to manually address the problem. If an incident occurs or a step in configuration is missed, scorecards also help SREs quickly identify where or why an issue may be happening. Portals also support automated incident management, through dynamic permissions, alerting and more.

Improving software reliability

Without scorecards, developers may not be aware of  production-readiness or software reliability issues. Using scorecards, any metric can be tracked and easily dealt with using automated notifications.

Wrapping up

Using an internal developer portal, previously nebulous DORA metrics can actually be tracked and measured, and working agreements can be implemented to improve the developer experience.  Standards become just that: standard for all software entities, so that MTTR is reduced. Finally, developer self-service makes for a better developer experience and faster cycle times.

Since everything is trackable or easily extrapolated upon from within the portal, it’s easier and faster to identify problems, iterate on solutions, forecast goals, and make improvements achievable. 

To learn more about scorecards, experiences, and self-service actions, visit our blog at getport.io/blog or poke around our live open demo.

Previous article

Next article

{{cta_1}}

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

Check live demo

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}

Open a free Port account. No credit card required

Let’s start
{{cta_4}}

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

Let’s start
{{cta_5}}

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

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

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

Let’s start
{{cta-demo-baner}}

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

{{port-for-backstage}}

Apply to join the Beta for Port's new Backstage plugin

Apply for beta
{{jenkins}}

It's a Trap - Jenkins as Self service UI

Read more
{{gitops}}

How do GitOps affect developer experience?

Read more
{{ebook}}

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

Download eBook
{{cyberark}}

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

Read more
{{cta-demo}}
{{reading-box-backstage-vs-port}}

Further reading:

Read: What are the technical disadvantages of Backstage?

Compare: Backstage vs. Port

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
   }
 }
}
{{tabel-1}}

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

{{tabel-2}}

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

You may also be interested in

Building the perfect internal developer platform

Building the perfect internal developer platform

Read more
How to use JQ commands to speed developer workflows

How to use JQ commands to speed developer workflows

Read more
Debugging K8s with K8sGPT in your internal developer portal

Debugging K8s with K8sGPT in your internal developer portal

Read more

Starting with Port is simple, fast and free.

Let’s start