Steve Berczuk writes:
> I don't think that Michael and I disagree really. but I
> would like to suggest that "frequent" is important, and
> sufficient, as long as you have a thorough post-check-in
> testing system,
I have to agree with my co-author here :-)
A couple years ago a colleague of mine who teaches part-time at a University
asked me to review a students proposal for an allegedly "agile development"
research project. They student wanted to develop a system that assisted
continuous integration by basically doing what Massol suggests - ensuring
"unbreakable builds" - albeit via a different mechanism (semantic analysis of
the changes and dependency computation to guarantee "consistent configuration"
before allowing a checkin).
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 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.
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.
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.
--
Brad Appleton <[EMAIL PROTECTED]> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost
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/
