On Sat, 01 Jan 2005 09:01:36 +1000, Robert Watkins <[EMAIL PROTECTED]> wrote: > An interesting aspect to a continual build server in a mature team is that > you should expect the occasional build failure; the server exists to be a > time saver, by taking some work off your hands. That work doesn't have a > guaranteed success rate, so it _should_ break occasionally. If it never > breaks, then your team isn't letting the server take enough work away from > them. The point of the continual build server isn't to ensure that the > build is always good; it's to let you know wether the build is good or not. > Ensuring that it's always good is the team's responsibility, and that can > not be abdicted to a set of silicon chips.
Robert said this a bit more clearly that I did in this thread. (But as Jason pointed out, I think that Brad and I say something similar in our book ... and hopefully the book makes the point better that I did today on this list ;) ) The key idea is to balance stability and progress, and one way to get at that is with teh right Codeline Policy. If you are working on a Release Line (ie, something that needs to be shippable ALWAYS (really!)) then you'd want be be sure that nothing ever breaks the build, If you are doing new Developemnt on an Active Development Line, then you might accept some failed builds (that you fix quickly) to allow people to check in changes frequently. (ie, only run a subset of tests pre check in, etc).... -Steve -- Steve Berczuk | [EMAIL PROTECTED] | http://www.berczuk.com SCM Patterns: Effective Teamwork, Practical Integration www.scmpatterns.com To Post a message, send it to: [EMAIL PROTECTED] To Unsubscribe, send a blank message to: [EMAIL PROTECTED] ad-free courtesy of objectmentor.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
