Hi Brad, Thanks for this interesting post. See below.
> -----Original Message----- > From: Appleton Brad-BRADAPP1 [mailto:[EMAIL PROTECTED] > Sent: vendredi 31 d�cembre 2004 09:32 > To: '[EMAIL PROTECTED]' > Subject: RE: [XP] Seen on Massol's blog: Unbreakable builds [snip] > I understood how it could be viewed as getting instant feedback (which is > certainly agile), and yet something about it smelled decidely non-agile to > me: it seemed very BDUF, trying to get everything right/perfect up-front > instead of allowing a "safe haven" to fail, frequently, on a really small > scale, and then apply corrective feedback. I suppose one could argue that > is still what is happening, but to me, not allowing the checkin/commit is > what violated that principle. I can understand what you're saying but I'm still unsure about it. Look around you at the numbers of automated tools that you use everyday. They allow you to do whatever you do faster and you can concentrate on higher level things. Look at compilation for example. In the old times, people were using punch cards to code their program. Then they would bring them to the main computer and stack them alongside others waiting to be processed. I'm sure this created a good social activity and there were lots of exchange between developers sharing tips and tricks in order to not make the compilation fail. Still, I'm pretty sure everyone is happy with having personal computers that can compile their code... Who would question this today? Is it bad? All that said, I agree there's a fine line that we should not cross, i.e. when automation is telling too much the developer what he should be doing. Your stance (and other XPers on this list) is that this is crossing the line. I think it is below that line because the developer still need to build his projects as before. He still needs to care and pay attention. What would be real bad is that this system is *forced* on a team. Then I agree that it would cross the line. But, if collectively, all developers like the idea and want it applied, then I don't think it creates a "social issue". > > I suggested that a more genuinely agile application for such a project > might be instead some kind of self-healing (autonomic) build. Use existing > mechanisms like AntHill, CruiseControl, or BuildForge to automate the > running of the build+smoke plus automated tests ... and in the case of > failure, perhaps that would be the appropriate time/place to do some kind > of semantic analysis to try and diagnose (or possibly even remedy) the > failure, and determine the most relevant information to auto-notify about. Sure. CruiseControl is kind of doing this for example, by reporting the diffs between the last build that passed and the current build that breaks. If CC is run often, the list of diffs you get is quite small and you get to know easily what broke the build. BTW, this is exactly what the unbreakable build solution would do for you: show you exactly what broke the build. I still don't understand why you would want to voluntarily let the continuous build break. The individual builds will still break as before. I'm really talking about the continuous one. > > So rather than "Unbreakable Builds" I'd be more interested in "Autonomic > Builds" -- at least on an agile project. > > For a really large system tho with hundreds of developers, what Massol is > suggesting is basically automation of what is already a manual process in > some large shops: these shops use an "integrator pull" model of > integration when, rather than letting the developer merge/commit their own > changes to the codeline (a.k.a. "developer-pull" integration), they > instead use one or more dedicated integrators who receive notification > that a change has been submitted for integration, and then the integrator > does the merging (basically a human integration token) and fails the > commit if it doesn't pass the tests. > > In this, very common (and not very agile IMHO) case for large projects, > what Massol suggests would be a VAST IMPROVEMENT for such large projects, > and could certainly help them be decidely more agile. I do completely agree that the proposed solution makes more sense for big teams. In a team of 10 persons collocated it's easy to build a common sense of build awareness and even make it a challenge to not let the build break. Even if it does for a few minutes, it only affects everyone and every one can relax for a while, think about something else, laugh, etc. So it creates a good diversion from work. With a bigger team, possibly distributed, the feeling is quite the opposite: you'll have several complaining why someone has made their local build break (because in the meantime they'll have checked out breaking code from the SCM), and they'll become wary of the build system and of continuous integration. In order to compensate for this, you would need a good build coach in each team. But I've not seem that many good build coaches and it's hard to scale. > > What Steve and I suggested in our SCM Patterns book is to instead allow > developer-push and integrator-pull to co-exist by having an "Active > Development Line" that serves as a "Change Docking" area for developers > use and commit/merge changes to, and then a separate Release-Line can be > used by the integrators, who may decide to look at individual changes or > else bundles of changes on the active development line and merge them to > the release-line at their own pace: > * Development gets to use the active development line for their > development > * Integration/build/CM gets to use the release-line for their own policy- > levels regarding "speed+safety" > * Each gets to peacefully co-exist on their own branch, and the > integrators assume the burden of the additional merging since they are the > ones insisting on slower merge-cycles for the sake of safety. We do use this practice. But the issue I am trying to solve is not the coexistence of developers and integrators. It's the coexistence of developers. We've not succeeded in stabilizing the build for lots of reason (one reason is that we've not been working hard enough to reduce the build breakage reasons. One reason is that management is not willing to replace existing tools that do not help - Example: StarTeam (SCM) does not show you the file you have added to a new directory. Thus when you commit, developers systematically forget those files as they do not appear in the StarTeam's view). FWIW, here's a list of typical build breaks: http://tinyurl.com/5br42 Thanks -Vincent 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/
