home | products | solutions | support | resources | company | blog

home > resources > build-pain-relief > Best Practices: Good Communication

Good Communication

Good communication of build failures is a critical practice. It can reduce the duration a project stays in a failing state, support working around breakages, and limit the number of people impacted by a failure. In other words, communication is a key factor in supporting three pillars of pain free building.

Rarely, developers will willingly check out the latest version of the code if it doesn't build and their local workspace does. A stale, but building, workspace allows developers to work more efficiently than an up-to-date broken workspace. This sort of voluntary freeze on updating their workspaces keeps the team working well; but if workspaces are frozen for long, the developers' work will tend to diverge. This often leads to painful and ugly integration processes. Again, short build breakages may be easy to work around, while long breakages cause additional headaches.

To support developers, notify the team when the code base starts to fail and again when the code base is healthy. Typically, a Continuous Integration server (such as AnthillPro) monitors the source repository and performs a build whenever new changes arrive. If there are problems, the entire team is notified so that they postpone updating.

Indicate Severity and Assign Blame

Notification should also indicate what kind of build failure just occurred. Does the code compile but the tests don't run? Do the tests run, but a minor test failure occurred in a distant part of the code, away from any changes? Clearly, showing where the failures are can give developers confidence that they can update their workspace despite a slightly broken build.

In order to prevent the wrong people from spending time diagnosing the cause of the failure, the notification should also do its best to identify who broke the build. If builds are done on every source commit, the build that is broken will usually only deviate from the previous functional build by the changes made by a single developer on a handful of files. Highlighting that developer lets the rest of the team focus on their own work.

Alert the Guilty

Many teams also notify the guilty developers in a louder format, like instant messages. This makes it clear who is responsible, and who needs to either hustle to fix the mistake or yank the change out of source control while investigating the problem.

Be Creative

Additionally, a creative notifications approach can be helpful. Build success and failure noises are great. Very visible evidence of the build status, like large TVs, lava lamps and the like, make it difficult to ignore a broken build. Any creative notification scheme that helps developers know when the build is good, when it needs to be fixed quickly, and who is responsible is always a good thing.