Living with Data – Measure and Improve 4 Key Metrics
Living with Data, one of our cultures in Trendyol is very important to us. As a team, we attach great importance to this value together with our other values. So what have we done as a technology team and we continue to do so?
If you want to see the project instead of reading it, you can access it below.
It is really exciting to have many books on this topic. As the Trendyol team, we have recently taken the step to improve our processes by reading the book Accelerate, which is one of the most popular and lecture books.
Accelerate measures software delivery performance — and what drives it — using four years of groundbreaking research and rigorous statistical methods.
The Accelerate book has appeared as a book summarizing the research of the State of DevOps Report over the past few years. In fact, the result of these studies is to observe your development metrics and get an idea of how you can improve them. As a team, read this book and tried to apply it within the company. During this application process, we learned a lot and eventually we measured our metrics and managed to visualize this.
So what are these metrics?
Accelerate says us that we have 4 key metrics. These;
- Lead Time
- Deployment Frequency
- Mean Time to Restore (MTTR)
- Change Fail Percentage
1. Lead Time
According to Accelerate book, DevOps experts Nicole Forsgren, Jez Humble and Gene Kim describe lead time for change as “the time it takes to go from code committed to code successfully running in production”.
The most important part here is the Pull Request and Code Review frequency. The faster the development made comes to production, the better it means.
2. Deployment Frequency
It is important for you to deploy production or to end user according to this method. In more understandable terms, it explains your frequency of release. The more often deploy to production, the better it means.
3. Mean Time to Restore (MTTR)
It is very important to frequently deploy to production, but sometimes incident can be happen because of minor mistakes. MTTR tells us how long the success deployments have been done right after this incident occurred. The important part here is, as always, to fix this incident in production in a short time.
4. Change Fail Percentage
Finally with this metric, the ratio of the error you get after deploying to production is the ratio of your total deploy to. For example, if you deployed to production 5 times that day and 3 of them are fix, hotfix, etc. your change fail percentage will be 60%.
You can also review the graph below which describes these explanations.
So what did we do?
After understanding these metrics as a team, we transformed them into practice and created our own metrics and visualized them. As soon as we did our first MVP project, we used it in the company. When we realized that the result we saw was good, we decided to share it with the world.
Our project is a tool that helps you to measure your metrics from cli. You can measure your metrics with this cli tool, but you should pay attention to the following;
- You can add as many repository as you want on a team based. Separate metrics will be created for each repository.
- All releases must be tagged with a specific prefix and version number [prefix][versionNumber] like release-v15 or v-[commitSha] or rel12.
- Your fix commit pattern must be specific for your repository (such as fix, hot-fix, hotfix). Because this is important, we will measure your fail metrics with this. Remember, you should create your commit message according to this pattern.
And the result!
Now you can see this and other metrics. You can also make decisions by looking at the daily, monthly and average values.
You can access the following address to use the project, to get more information and to contribute. The project is still under development. If you want to contribute, please do not hesitate.
We look forward to your support, thank you!
If you want to take part in such great works like this, join to trendyol from here :)
Resources;
