Comments on: Continuous Integration: Be Annoyed http://www.alittlemadness.com/2006/05/31/continuous-integration-be-annoyed/ A man needs a little madness, or else he never dares cut the rope and be free. -Nikos Kazantzakis Tue, 06 Jan 2009 21:28:13 +0000 http://wordpress.org/?v=2.2.1 By: Jason http://www.alittlemadness.com/2006/05/31/continuous-integration-be-annoyed/#comment-12730 Jason Thu, 25 Jan 2007 14:46:18 +0000 http://www.alittlemadness.com/2006/05/31/continuous-integration-be-annoyed/#comment-12730 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. 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.

]]> By: Jon http://www.alittlemadness.com/2006/05/31/continuous-integration-be-annoyed/#comment-12728 Jon Thu, 25 Jan 2007 14:37:31 +0000 http://www.alittlemadness.com/2006/05/31/continuous-integration-be-annoyed/#comment-12728 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 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

]]> By: Elizaveta Revyakina http://www.alittlemadness.com/2006/05/31/continuous-integration-be-annoyed/#comment-108 Elizaveta Revyakina Mon, 05 Jun 2006 08:55:25 +0000 http://www.alittlemadness.com/2006/05/31/continuous-integration-be-annoyed/#comment-108 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. 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.

]]>