Question

time taken to fix a broken build is measured using

Answer 1

 answer is that measuring and rewarding MTTF above all else absolutely does not support a more agile organization. That fear of "breaking the build" and "keep the system stable" is one of the reasons many organizations fail at adopting agile processes. They try to force "release often" down the throat of an organization that is measured and rewarded when everything stays stable instead of being rewarded and measured on how often can you change and how fast can you recover if a failure occurs.

MTTR is a very interesting case of Devops Culture taking something well established, and turing it on its head. If DevOps is about build, measure learn, and fast feedback cycles, then it should become an undeniable truth that "whatever can go wrong, will go wrong". if you embrace that mantra, you can start measuring "mean time to recovery" instead.

The MTTR incentive can drive the following behaviors:

Build resilience into the operations system as well as the code.

Build faster feedback mechanisms into the pipeline so that a fix can go through the pipeline faster

Creating a system and code architecture that minimizes dependencies between teams, systems and products so failures do not propagate easily and deployment can be faster and partial

Add and start using better logging and monitoring systems

Create a pipeline to drivers a deployment of an application fix into product as quickly as possible.

Making it just as easy and fast to deploy a fix as it is to roll back a version

With mean time to reco

Answer 2

Answer:

The answer to the question is-

Time taken to fix a broken build is measured using build repair rate.  It is  according to Continuous Integration Build Metrics.

Explanation:

Build repair rate

Build repair rate indicates the time taken to repair a failed build. It can be measured in Hours/Minutes/Seconds. According to Richard Brown's book, Repair duration and Repair rate is inversely related.