Published February 28, 2021
by Doug Klugh

Keep the Build Healthy

Limit the amount of time spent fixing broken builds.  Revert to the previous version if you are unable to fix the build within a predetermined amount of time (i.e. 10 minutes).  One of the many advantages of checking code into source control frequently is having the ability to quickly revert to a working version where all the tests pass.  Always fix a broken build as quickly as possible to prevent the error from progressing downstream.

As hard as we may try not to break the build, everyone does from time to time.  And even more so on large projects.  In most cases, we can identify and fix the problem within a few minutes.  But there are times when we cannot figure out where the problem lies, or we somehow changed the fundamental logic of the code.

In these cases, it is critical that the problems be resolved as quickly as possible to prohibit the same failures from arising in future changes and to prevent new failures from being introduced.  Quick resolutions also prevent the errors from progressing downstream where the cost and effort to resolve the issues are much greater — not to mention the addition of Technical Debt.

Avoid major problems by resolving smaller problems early in the development lifecycle.