Continuous Integration: Be Annoyed
Every good continuous integration server provides some form of notification of build results. The most basic (and one of the best) forms of notification is via email. Email is ubiquitous, and thus there is nothing extra to set up or teach before you can use email notifications. The better continuous integration servers also allow filtering of notifications based on the build result. This is simply about increasing the signal/noise ratio: if you get emails after every build, and a large percentage of builds are successful, it is easy to lose the useful notifications in the deluge.
Given this flexibility to choose when to receive notifications, it is tempting to start filtering out aggresively. It is a matter of personal preference, but there are many people who want to keep their email traffic to an absolute minimum. This is fair enough, but in my opinion there is a minimum level of notification that every developer should subscribe to: all failed builds. I don’t care who caused it, if a build of a project you are working on fails, you should know about it. I can imagine some complaints already:
- But that’s too many emails, it’s annoying!: Well, then your project spends too much of its time broken, and you deserve to be annoyed :). Failed builds should be the exception, not the rule. Receiving the deluge of emails will hopefully motivate your team to keep things working.
- But it’s not my fault, somebody else broke the build!: You are all one big happy team, remember?
In this case, it is still useful for you (and other team members) to know something is broken. You may help fix the build, or hold off on other changes. Further, the threat of public shame will make your teammates more careful ;). - But once it fails, it keeps failing, and the emails are piling up!: Then fix it faster! Seriously! OK, in some cases where you know the fix will take a while, you may want to pause the server. But often the fix is quick, and should be applied ASAP.
Of course, this is all just one developer’s opinion, and no continuous integration server should enforce this. However, I believe that if all developers receive notifications of all failures (at least), failures will become less frequent as a matter of course. Otherwise that pile of emails will just get too annoying!
—
Into continuous integration? Want to be? Try pulse. You can choose when you want to be notified using arbitrary boolean expressions.
This entry was posted on Wednesday, May 31st, 2006 at 7:19 pm and is filed under Continuous Integration, Project Automation, Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
June 5th, 2006 at 7:55 pm
Elizaveta Revyakina says:Indeed being annoyed both about the failed and successful builds is good, and in some points makes the team stronger and the work faster.
Notification by e-mail should probably be used to provide an extensive information on the build results and failed tests, but instant notifications via Jabber for example, well, they are just instant…
But I believe that many developers would prefer to receive instant notifications on the build status and track their changes integration right from within the IDE (like we do it in IntelliJ IDEA and Team Server plugin integrated in it), so that they stay tuned to the effective work and don’t need to switch between programs.
January 26th, 2007 at 1:37 am
Jon says:I implemented a CI Build on our R&D group, and started to send emails to all the developers on the group on each failure.
In two days – half of the developers made an outlook rule to move those notifications to a folder they will never see again…
So my solution was to the develop smart application which will send those notifications only to the developers who actually checked-in since the last successful build.
This way you don’t annoy to much…
See my blog for details
January 26th, 2007 at 1:46 am
Hi Jon,
Thanks for stopping by. Yes, this is the danger. I think that it is best approached in two ways:
1) Keeping the build green almost all of the time. Sure it will break now and again, but it should not be frequent enough to be annoying. With features like personal builds in Pulse (where you can get Pulse to test your changes before you commit them), this is quite feasible. But still, in the real world, we don’t always reach this goal, which leads to …
2) Flexible subscription to CI notifications, similar to what you have implemented. In Pulse, every developer can set their own subscription condition, based on the build state, whether the state changed, whether there were any code changes (by anyone or just by themselves) and so on. I do not know of another build server that gives more flexibility in this regard.