Kent Beck wrote:
> My concerns with the integration process are efficiency and learning. When I
> am notified of a build breakage after the fact, I have to interrupt my
> current task, take a while to remember what I was working on, and then take
> a while to get back to my task. That seems inefficient to me. It's worth ten
> minutes of waiting to avoid eleven minutes of task switching (YMMV). When I
> find a problem right away, not only do I fix it faster but I have a better
> chance of learning not to make that kind of problem in the future.
Kent,
Why would you assume that integration is finished when you release your
code? It is certainly feasible to say that integration is not finished
until you get the build success notice.
I encourage people to run builds locally to get confidence levels to a high
point, like the high 90s. They can then release the changes, and the build
server goes to town. Integration is finished when the build server says its
done. The idea here is that if it will take me an extra two minutes to get
100% confidence, but I've already got 95%, then it's not worth it for me to
spend those two minutes now.
In the local vs remote build scenarios, the local build should focus on the
most common reasons for failed integrations - the compile & test phase. The
remote build should focus on other things, predominately QA activities.
> I don't see this as "manual" integration. I find the Eclipse three-way
> synchronization to be very efficient in the normal case where there are no
> conflicts and very helpful when there are conflicts.
The Eclipse synchronisation view is absolutely fantastic. Being able to
easily see the changes you're going to pull down solves one of the biggest
limitations of using CVS.
> I very much like your point about failures at later stages turning into
> tests/steps in earlier stages. Ideally I'd like to avoid staging altogether,
> but while learning to make this safe the adaptive strategy you suggest seems
> both efficient and effective.
Every build failure is a learning opportunity. Being able to analyse
patterns of build failures is an even better learning opportunity.
Robert.
--
"Software is too expensive to build cheaply"
Robert Watkins http://twasink.net/ [EMAIL PROTECTED]
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/
