Immediately solving build errors is another important team habit to develop. Tests that fail should not be ignored or postponed but fixed as soon as possible. Builds that fail often and are not taken good care of decrease the productivity of all team members. A failing test that makes the project unable to be built, for example, prevents other developers from integrating and verifying their features. Still, failing builds due to test failures or quality violations is a sign that the validation works and is, obviously, much better than false negatives, that is, mistakenly green builds. It is, however, important to fix project builds as soon as they fail. Developers should execute basic and fast verifications, such as building the Java project and executing code level tests, on their local machines before pushing to the central repository. They should take care not to misuse the pipeline to find careless mistakes which unnecessarily disturb other team members.

As mentioned earlier, compiler or code analysis warnings should be treated as errors that break the build. This introduces a zero-warning policy that urges engineers to either fix the issue or adjust the validation. Build, compilation, or code style warnings are therefore also errors that break the build and need to be fixed as soon as possible.

The team member whose commit caused the build to break should ideally be the first to look into the root cause. It is, however, a responsibility of the whole team to keep the pipeline in a healthy state. This goes back to the whole team being responsible for the whole project. There should not be exclusive code ownership, that is, parts of the projects which are exclusively known to a single team member. It will always be the case that developers who wrote specific functionality have better knowledge about it. Still, in all cases, the team should be able to work on all areas of the project and fix potential issues.