Unreliable builds hurt every developer.
First, there’s the obvious: time spent re-running and debugging flaky builds is time lost for other activities.
Second, time spent waiting has to be filled. And team members who switch contexts to progress another strand of work while waiting suffer reduced focus.
Third, delayed feedback on the effect of changes to an application inhibits learning and causes waste.
In this post, we follow the real-world experiences of some of development teams as they overcome flaky builds and transform their productivity.
Note that flaky tests are a related issue which warrant a separate discussion.
The issue is more common than you think
It’s not uncommon for a build system to get into a state where, upon seeing a failed pipeline, the team’s first action is to check if it failed for reasons unrelated to the codebase. Perhaps it’s a problem with a build agent running one of the jobs in the pipeline. For example, the…