Software Delivery Performance Metrics: A Solution for Faster, Safer, and Better Software Delivery
In 2023, Radya Digital, especially the Engineering team, has goals to improve processes and productivity. To measure and help achieve these goals, we use a metric called Software Delivery Performance.
Get to know Software Delivery Performance (SDP)
Software Delivery Performance is the ability of a company/organization to produce software products and services to customers quickly, stably, and efficiently. Because software development is a complex matter, a clear framework is needed to define, measure, and improve Software Delivery Performance.
One of these frameworks is the 4 key metrics proposed by the DevOps Research and Assessment (DORA) team based on research and analysis of thousands of software development organizations.
The four metrics are:
- Lead Time
How long does it take from development to deployment to production? - Deployment Frequency
How often an organization deploys - Change Failure Rate
How often does a deployment result in an error or failure in production that requires a rollback or hotfix? - Mean Time to Restore (MTTR)
How long does it take to resolve problems in production
Target Time: Hitting the Bullseye with Purpose
To achieve the goals above, Radya Digital sets targets for Software Delivery Performance based on the four metrics above. The targets set by Radya Digital for the Engineering team are as follows:
- Lead Time → 150%
- Deployment Frequency → Minimum 1 deployment per day per project
- Change Failure Rate → 16-30%
- Mean Time to Restore (MTTR) - Less than one hour
Mission Possible: Achieving the Impossible, One Small Step at a Time
So, what steps does the Engineering team, especially the Frontend division, take to achieve the targets above?
The Engineering team designs programs which will then be developed by the Frontend division. Mapping the programs against the metrics they are trying to achieve is as follows:
Mapping Frontend Programs to Metrics
The Base Project: Your Launchpad to Greatness!
First of all, Base Project. To achieve a fast Lead Time, a project base is needed that accommodates the needs that usually exist in each project. So it is necessary to develop a Base Project that is flexible, efficient, and easy to implement.
The current Next.js Project base features are as follows:
- Components
- There are many ready-to-use base components, which can be directly implemented into the project along with documentation so that developers can easily adapt.
UI component documentation
- CMS Layout, to speed up the layout process at the start of the project. Developers only need to customize several aspects of the existing layout.
CMS Layout
- Script to transform SVG icons into React components, so developers don't need to create components manually.
Script Icon Builder
- And several other additional UI components such as Datatable which is used on almost all pages in every project.
Other UI Components
- Eslint config adjusted to conventions and other rules to standardize and reduce the occurrence of bugs
- Docker config for various environments
- Custom hooks for HTTP Client along with global error handling, authorization handling, and global config based on TanStack Query
- Examples of CRUD features along with examples of validation forms as a guide for developers when working on projects
One of the Radya Digital products that has used this base project is the Radya OCR Receipt Reader. Radya OCR Receipt Reader is a solution that makes it easier for users to handle and process receipts.
Radya OCR Receipt
Radya Digital's OCR technology automates the extraction of critical information from receipts, eliminating manual data entry and reducing the risk of errors. With high-accuracy Optical Character Recognition capabilities, it ensures correct data retrieval such as date, quantity, and vendor information.
Text generated from the receipt
From Chaos to Cohesive: The Design System to Rule Them All!
The Frontend Division also carries out research and development of Design System/UI kits to help achieve Lead Time targets. This program will continue until next year because in the process developers are working on many other projects.
UI Kit Documentation
Code Crusaders: Keeping the Quality Bug-Free!
For the Maintain Quality of Code program, the Frontend division has 2 programs: Code Review and Branch Deployment.
Code Review is an Engineering program that has been around for years, where when a developer wants to merge into the main or production branch, there needs to be a code check by the Senior Developer, Project Lead, or Engineering Lead on the developer's pull request.
This is done so that the code pushed by the developer is code that meets the standards of the Engineering division, which of course can help reduce unnecessary bugs when deploying to development or production environments.
The second Maintain Quality of Code program that was just implemented this year is Branch Deployment which utilizes the deployment preview feature from Vercel. Branch Deployment is a method where a feature that is being developed can be deployed without having to merge it into the main branch first.
Example of an active branch that has a deployment link
This helps developers to deploy and get feedback from QA more quickly, because usually before deploying they need to make a pull request and code review first, but with this developer can immediately push the code to get the deployment link and immediately test it by QA.
The following is a comparison of the time QA can test a feature before and after implementing branch deployment:
Time before QA able to test Feature
This program helps achieve Deployment Frequency, Change to Failure Rate, and MTTR metrics by:
- Ratio Number of Builds
Number of Build Error Ratio
- With a configuration where the developer cannot commit before the lint passes, it can reduce the error rate in deployment (Change to Failure Rate)
- From 480 builds there is a 44 (8.4%) error rate in deployment which can help achieve the maximum target of 16-30% Failure Rate - Number of Builds per Project
Number of Build per Project
- Almost every project can be deployed every day. This can speed up the development process because QA can more quickly test a feature
- Helps achieve Deployment frequency metrics where there is a minimum of 1 deployment/project/day - Instant Rollback
Instant Rollback Feature
- Can do an instant rollback to the previous build if it turns out that the build being deployed has an issue, this helps achieve MTTR metrics where we must be able to restore if there is an issue in less than 1 hour.
Beyond the Finish Line: Charting Your Course for Continuous Improvement
The programs above are programs carried out by the Frontend division team to achieve Radya Digital's goals of improving processes and productivity. Of course, these programs are still far from perfection and there is still a lot of room for improvement that can be made next year as a way to achieve other goals in 2024 and beyond.
The program above could not have been implemented without help from Engineering Manager friends and Frontend division friends. Hopefully, these programs can help improve not only the quality of the company but also our quality as Software Engineers.
If you have any feedback or suggestions, please comment, guys!
For other interesting information about technology and IT, visit: Radya Blog. And for consultation in making applications, you can contact our team at: Radya Contact.