Build

Understand your build bottlenecks and reliability.

Purpose

Team productivity can be severely impacted buy the infrastructure they rely on. This includes the build times, reliability, and recovery times. This report provides insights into critical build metrics across pipelines and teams to pinpoint areas of improvement.

Improvement Actions: Once overall build performance is tracked, it is helpful to tackle those build pipelines that have:

• low reliability,

• a high number of developers depend on them, and

• each individual build might take a long time.

A combination of the above might block contributors in their productivity and also hamper fast, reliable releases. Improving infrastructure speed and reliability leads to higher levels of team happiness and productivity.

Explanations

The build report provides a number of insights, including:

Total number of builds: This helps to observe the overall build frequency trend.

Reliability: The overall reliability of corresponding pipelines of all selected teams and repositories. Low reliability is known to reduce productivity significantly.

Build speed: The time it takes on average for a build. Builds are potential blockers for teams to get their work done, and long build times might slow teams down significantly.

Recovery time: The average time it takes for a broken build to recover. Long recovery times potentially block teams for a similar time and might stall releases.

Build result breakdown: The success rate and breakdown of builds over time. It shows the trend of improvements or degradation and sometimes the causes for unsuccessful builds.

Build pipeline table: The table breaks down each build pipeline into criteria similar to the above. This is a good starting point to identify bottlenecks and unreliable builds.

Good to Know

You can drill down into each pipeline individually to examine the history of the build, its success rate and the stages at which the build has failed.

By default, Logilica imports a history of the last 1000 build runs per repository at the initial onboarding time. Future build runs will be added to the stored history.