Measure team performance with DORA metrics and implementation, 10x Engineer Part 3
The DevOps Research and Assessment (DORA) team has identified four metrics that measure DevOps performance. Using these metrics helps the performance of the team, and can measure impact for every improvement done on the team.
DORA metric consists of 4 key metrics that indicate the performance of a software development team:
Velocity Metrics :
- Deployment Frequency: Numbers of successful deployments to production at a certain time per (day/week/month).
- Lead Time For Changes: How long the code be delivered to the users?
Stability Metrics:
- Change Failure Rate: How often deployment causes incidents/issues/failures.
- Failed Deployment Recovery Time: How long it takes to solve production incidents/issues/failures.
with all of that measurement the result for your team can be, low, medium, high, and elite.
How DORA able to measure the metric?
these metrics require your team's git data and CI Tools, they can be coming from Git Hub, GitLab, Jenkins, and can be coming from Jira as well.
Let me tell you a story to explain how DORA gets the data.
There is an engineer named Malik who is working on resetting the password feature with Jira story ID(JIRA-101)
Today Malik was so happy he was updated on the daily standup meeting that his task gonna be done and would be ready for deployment, now after a few hours his pull request/merge request was ready to merge, and all CI pipeline jobs are green he made sure that before committing the code.
afternoon he asked the leader of the project, Salah to review the pull request, and what Salah did was comment “LGTM(Look good to me) “ and merge the code.
the evening it was deployment time, Salah created a branch named 1.2-Release from the latest main branch because the team is using TBD (Trunk Based Development) He made sure every feature toggle was settled. he created a Tag with the name DEPLOY 1.2.0 and deployment will be running automatically.
Deployment was successful everything seems good, it took 6 hours from the pull request into deployment which counts as Lead Time For Changes, and Deployment Frequency is 1 for a day.
after 1-hour shit happened, the system is going slow, users complaint and Malik react fast to that incident, he worked on that and fix in 30 minutes, created Jira Incident and committed the code with branch name INCIDENT-PROD-1.2 and again asked Salah to merge and deploy the changes with Tag DEPLOY 1.2.1.
re-deployment was successful everyone is waiting and monitoring the release, it took 90 minutes from the last deployment with 30 minutes incident fix by Malik, and re-deploy the changes counts as Failed Deployment Recovery Time, and the incident is 1 plus it has failed deployment 1 time (1.2.0) this record as Change Failure Rate.
Now Salah and Malik were able to sleep with ease knowing that the second deployment was a true success.
This story simplifies how DORA metric can record team git operational, it’s requires heavy use on CI/CD as well for DORA metrics to understand deployment and pull requests.
How To Implement DORA Metrics?
there are many DORA metrics solutions from open-source solutions to enterprise, but in our team it’s using Apache Dev Lake it’s free and easy to use.
I will not write how to set up Apache Dev Lake because they already told everything on the website so I’ll explain only the big picture of it.
first, you must install Apache Dev Lake using docker or helm, then connect the source data, either from GitLab or Github or anything that supports it, if connected you must create an associate scope config to create a DORA metrics dashboard this is required to put your pipeline job deployment to production name.
if everything is good you’ll be able to open the DORA dashboard.
that is all for DORA.
Thanks
