A tool for capturing and reporting DORA metrics
This app is used to capture and display DORA metrics. It requires a Postgres
database to persist metrics that are reported to it. DORAmeter captures data through a RESTful POST request on its
/events endpoint, with a payload described below in the Running Locally section. It uses GraphQL
to query data for its frontend.
Like a spinning top, the DORA metrics find the balance between speed and accuracy. It's speed metrics are Deployment Frequency and Lead Time. It's accuracy metrics are Mean Time to Restore and Change Failure. Too much focus on speed or accuracy and your app will degrade in performance. A good balance will keep the top spinning.
Deployment frequency (DF) is a measure of how often code gets deployed to production. It indirectly measures the size of the change being delivered. It has been proven that smaller code changes accelerate feedback, and reduces risk and overhead.
DF is measured by the difference between the current time and the last time the app was deployed, in hours. The choice to measure between the current time and last deployment was made because it's rare that an app runs in complete isolation with no dependencies. It's more likely that your app, like every app, will suffer from software rot from these dependencies if not continuously updated. In a later update, I may add the option to measure the time between the two last deployments. Below are rankings for the difference measured:
| Ranking | Time (in hours) |
|---|---|
| ELITE | < 24 |
| HIGH | < 168 (1 week) |
| MEDIUM | < 672 (1 4 week month) |
| LOW | < 4032 (6 months) |
| NONE | Not enough data |
Lead time (LT) is a measure of time it takes the app to go from code committed to code deployed. Shorter LT's is significant because they enable faster feedback on what is being built and allows for more rapid course correction.
Rankings TBD.
Mean time to restore (MTTR) is a measure of the time it takes to restore a failed service. Shorter MTTR means higher reliability for systems.
Rankings TBD.
Change failure (CF) is a measure of the rate of changes to production that fail. A low CF rate is a representation for the accuracy of the change being made.
(number of failed changes)/(number of successful changes) x 100
Rankings TBD.
- Start with
yarnandyarn dev(Uses Docker to start up app and dependencies) yarn devautomatically runsyarn migrate-seed-datato add data. You can add more data making the following HTTP request:
POST localhost:4444/event
JSON Request Body:
{
"appName": "App J",
"eventType": "DEPLOYMENT" (To be implemented: "CODE_COMMITTED", "SUCCESSFUL_TEST", "UNSUCCESSFUL_TEST")
}
- Visit
http://localhost/on a browser to view the frontend for DORAmeter
There's still some work left:
- Lead Time
- Mean Time To Restore
- Change Failure
- Add auth
- Upload Docker to Docker hub
- Swagger for Next API