GitLab adds fourth DORA Metric API to CI/CD platform
The latest update to GitLab’s continuous integration/continuous delivery (CI/CD) platform of the same name added application programming interface (API) support for measuring data rates. changes failed. This addition supports the fourth metric as defined in the DevOps Research and Evaluation Framework (DORA).
GitLab version 14.10 also extends the GitLab Runner Operator for Kubernetes to any distribution of the open source platform in addition to allowing manual incident responses to be triggered when needed.
Finally, a compliance report showing each individual merge request violation has been added, along with a tool to configure continuous audit events.
Brendan O’Leary, Staff Developer Evangelist for GitLab, said that as DevOps processes continue to mature, DORA metrics make it easy for IT managers to measure overall progress. While it’s unlikely that a single set of DevOps practices will be universally implemented across an enterprise, O’Leary noted that it’s important for DevOps teams to track key performance indicators. (KPIs) that allow teams to identify areas for continuous improvement. For example, it’s not uncommon for technical debt to pile up in the absence of metrics that track build progress, he added.
In general, a transition to microservices-based applications increases the need for CI/CD platforms that simplify building them. Each of these applications is built using microservices that are usually built independently of each other. The challenge is that each microservice depends on other microservices, so the need for DevOps workflows to optimally manage this development process is becoming more prevalent, O’Leary noted.
In some cases, organizations are deploying a CI/CD platform for the first time to build these applications. In other cases, they seek to replace a CI/CD platform that has been adopted to build monolithic legacy applications. Regardless of the type of application, there is a need to continually refine and improve software engineering practices to increase developer productivity.
It’s unclear to what extent developers vote with their feet to work for one organization versus another based on the overall quality of developer experience. However, organizations that have a consistent approach to software engineering allow developers to spend more time writing code rather than managing the build process. The challenge is to ensure that the DevOps platform itself doesn’t become a bottleneck that hampers the speed at which developers can create code. It’s also unclear if organizations are building apps faster than they can secure them and ensure overall quality. The only way to know for sure is, of course, to track the metrics.
Of course, not every developer is a fan of metrics. App development is still as much an art as it is a science. There is, however, a general appreciation that the amount of code that needs to be written far exceeds the talent available to write it; any effort to make software engineering more efficient benefits everyone involved. So, with all the code to write, a software engineer is often the best friend a developer can have today.