headers
Ron Jeffries | 1 Jan 2005 12:08
Favicon

Re: Asynchronous versus synchronous continuous integration


On Friday, December 31, 2004, at 5:32:26 PM, Jason Yip wrote:

>> > - The team is responsible for broken builds, not any particular
>> > individual or pair.  Particular individuals or pairs involved in the
>> > latest change will be most capable in helping fix a broken build.
>> 
>> In the manual build case, if the build breaks, you know you did it.
>> The pair who need the learning are the pair presented with the
>> opportunity.

> Yes.  This is the advantage of the purely sequential CI style.  I
> would say however, that it is not always *just* the pair that needs
> the learning.

True, but I wouldn't send the whole tribe out after every rabbit
that runs by the village. I'd trust the hunters to bring back
anything of interest.

Ron Jeffries
www.XProgramming.com
Fatalism is born of the fear of failure, for we all believe that we carry
success in our own hands, and we suspect that our hands are weak. -- Conrad

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron Jeffries | 1 Jan 2005 12:18
Favicon

Re: Asynchronous versus synchronous continuous integration


On Friday, December 31, 2004, at 6:38:20 PM, Steve Berczuk wrote:

> On Fri, 31 Dec 2004 18:16:05 -0500, Ron Jeffries
> <ronjeffries <at> xprogramming.com> wrote:
>> I was still talking about Jason's proposal to run the tests
>> automatically and not commit the stuff that doesn't build, bouncing
>> it back to the devs. Have I missed a turn somewhere?
>> 

> I think so. Jason (and please correct me if I misunderstand!) was
> talking about DEVELOPER pre-commit tests followed by MORE EXTENSIVE
> post-commit tests in the integration environment. The Post Commit
> build and test happens asynch, but only after there is a synch
> developer step to be somewhat sure that the build is not broken...
> Maybe it was a fork in the road rather than a turn (a la Yogi Berra:
> If you see a fork in the road, take it -- you'll end up in the same
> place!)

Running all the tests in one's sandbox before any kind of commit
seems to me to be basic, but perhaps it needs saying.

I think we're talking about what happens after that: whether one
does as Beck and Jeffries et al. recommend, and builds on the build
machine, or whether one throws one's code at the asynch process
Jason describes.

When you and I walk over to the build machine and build, we are
focused on that, and yet have an opportunity to decompress, to talk
over what has happened, and to look out the window if any.
(Continue reading)

Permalink | Reply | 19 comments |
headers
Steve Berczuk | 1 Jan 2005 16:50
Picon

Re: Asynchronous versus synchronous continuous integration


On Sat, 1 Jan 2005 06:18:04 -0500, Ron Jeffries
<ronjeffries <at> xprogramming.com> wrote:
> Running all the tests in one's sandbox before any kind of commit
> seems to me to be basic, but perhaps it needs saying.
> 
> I think we're talking about what happens after that: whether one
> does as Beck and Jeffries et al. recommend, and builds on the build
> machine, or whether one throws one's code at the asynch process
> Jason describes.

OK. I think I understand where the disconnect was... What started this
thread was the idea of doing all of the "pre commit" testing in an
asynch process. (I guess, establishing that doing a build and test
before check-in is NOT basic to everyone...) You, Jason and I agree
that this is a "not good' thing.

The other fork was doing the integration build by hand and waiting for
the results vs checking code in and having an automated integration
build happen. I think that whether you wait for the results or move on
is a matter of convention, and in many cases, the integration build
and test may well happen before you have a chance to start something
new.

But what if you have a "complete" set of tests that takes, say, an
hour.... would you want to wait for that to finish before moving on,
or, having done some sanity checks before checking is, is it better to
move on and then go back to fix things if the build happens to fail
(which may not be likely)?
(Continue reading)

Permalink | Reply | 18 comments |
headers
Ron Jeffries | 1 Jan 2005 12:29
Favicon

Re: Asynchronous versus synchronous continuous integration


On Friday, December 31, 2004, at 2:45:45 PM, Steve Berczuk wrote:

>> XP 2nd Edition has a similar comment about "the inherent reflection
>> time build into the synchronous style".  My first thought was, if
>> reflection is important, why do I need an excuse to take time to do it?

> This was my point... Rituals are nice, and you can argue that 'low
> tech' can force you to think about what you are doing more than 'high
> tech/ behind the scenes' processes. But the right answer is often that
> you should not use 'the need for reflection' (for example) as a reason
> to not do things better/faster.  If they are, in fact, better and
> faster!

Very slippery slope here. We are strongly affected by our tools.

Those of us who have gone all the way to working with cards have
reason to think that one should start that way rather than with one
of the excellent tools that are available.

Those of us who pair program side by side have reason to think that
it is very much better than pairing over high speed VPN with web
cams and instant messaging.

Those of us who have had the whole team in the room ...

Those of us who have focused on conversation rather than paper ...

I would not start a team with an over-the-wall build. Faster and
better is often not what we think.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ron Jeffries | 1 Jan 2005 17:07
Favicon

Re: Asynchronous versus synchronous continuous integration


On Saturday, January 1, 2005, at 10:50:09 AM, Steve Berczuk wrote:

> Three questions about your expeciences:
>  - Can only one team integrate/build at a time?

Generally, yes, that's the model. A couple of pairs might decide,
for some reason, to combine their stuff.

>  - How long does the Integration Build take?

As little time as possible. Ten minutes.

>  - How often does the integration build fail when people check in
> changes only after a successful Private System Build/Test in their
> workspace?

Occasionally. Each time is an "occasion" to reduce the chance of it
happening again. Common causes that I recall are:

  - someone integrated improperly before, left the system in an
  unknown broken state. (yes, I know that Jason's approach, or
  Cruise Control "fixes" this.)

  - something important on the local system wasn't transferred to
  the build system.

  - some conversion or migration code wasn't robust enough.

  - hardware differences weren't correctly accomodated.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ron Jeffries | 1 Jan 2005 17:03
Favicon

Re: Asynchronous versus synchronous continuous integration


On Saturday, January 1, 2005, at 10:50:09 AM, Steve Berczuk wrote:

> But what if you have a "complete" set of tests that takes, say, an
> hour....

This is the bug. We should fix it.

> would you want to wait for that to finish before moving on,
> or, having done some sanity checks before checking is, is it better to
> move on and then go back to fix things if the build happens to fail
> (which may not be likely)?

Of course, move on. But is the right way to move on to automate the
hour-long build? Perhaps not.

Ron Jeffries
www.XProgramming.com
You can observe a lot by watching. --Yogi Berra

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/
(Continue reading)

Permalink | Reply | 15 comments |
headers
Steve Berczuk | 1 Jan 2005 17:39
Picon

Re: Asynchronous versus synchronous continuous integration


On Sat, 1 Jan 2005 11:03:09 -0500, Ron Jeffries
<ronjeffries <at> xprogramming.com> wrote:
> 
> On Saturday, January 1, 2005, at 10:50:09 AM, Steve Berczuk wrote:
> 
> > But what if you have a "complete" set of tests that takes, say, an
> > hour....
> 
> This is the bug. We should fix it.

Hmm, Why isn't there a place in the process for a set of exhaustive
tests that use many resources to ensure that the application works
correctly? If you had such tests it is plausable that they may take a
long time. I agree that the tests that developers run to ensure that
the build works shoud be quick. But I think that you would want to run
more exhaustive tests. And run these asynchronously.

I'm trying to describe a layered approach:
1.  While coding: Incremental builds and Unit Tests for code you are working on.
 2.  Before Check in: Update from Codeline, Full Build (when possible)
but perhaps not from a clean checkout, and the reasonable set of tests
that run quickly.
  3.  After check in: Automated FULL BUILD (from a clean checkout),
FULL set of COMPLETE tests.

Perhaps what differs between what I am saying and what Ron is saying
is that there is also
a 3(-) step where we run a full build from a clean checkout, but the
quick set of tests, on the integration machine? (and wait for the
(Continue reading)

Permalink | Reply | 14 comments |
headers
Ron Jeffries | 1 Jan 2005 18:48
Favicon

Re: Asynchronous versus synchronous continuous integration


On Saturday, January 1, 2005, at 11:39:50 AM, Steve Berczuk wrote:

> Hmm, Why isn't there a place in the process for a set of exhaustive
> tests that use many resources to ensure that the application works
> correctly? If you had such tests it is plausable that they may take a
> long time. I agree that the tests that developers run to ensure that
> the build works shoud be quick. But I think that you would want to run
> more exhaustive tests. And run these asynchronously.

Use of "many resources" will not make the tests better.

Running them asynchronously is done because they take a long time.
The fact that it takes a long time to know if you've done good work
is the bug. Fix it.

Ron Jeffries
www.XProgramming.com
Think!  -- Aretha Franklin

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/
(Continue reading)

Permalink | Reply | 13 comments |
headers
Steve Berczuk | 1 Jan 2005 19:10
Picon

Re: Asynchronous versus synchronous continuous integration


On Sat, 1 Jan 2005 12:48:55 -0500, Ron Jeffries
<ronjeffries <at> xprogramming.com> wrote:
> Use of "many resources" will not make the tests better.
> 
> Running them asynchronously is done because they take a long time.
> The fact that it takes a long time to know if you've done good work
> is the bug. Fix it.

Not to beat this to death, but...

Some of the ways that you simplify tests and make them run quicker are:
  simplify use of external resources... Test without databases, Mock
out server resources, use smaller data sets.

Doesn't it make sense to have some automated tests that test as much
as possible under reasonable circumstances?

I am NOT saying that you need to run the long tests before/after
checkin; you should have quick tests that give you a reasonable level
of confidence that things work. But I also don't think that you can
say that running more tests is ever bad (or that it  is worthless) as
long as the testing does not slow down the team. (hence, adding
another layer of testing post checkin...)

 The reality is that if I have a good testable system, using Mock
Objects (or other isolation mechanisms), I can run a few tests quickly
and be very sure that everything works. But there are always unforseen
problems...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Yip | 1 Jan 2005 20:28
Picon
Favicon

Re: Asynchronous versus synchronous continuous integration


--- In extremeprogramming <at> yahoogroups.com, Ron Jeffries
<ronjeffries <at> X...> wrote:
> On Saturday, January 1, 2005, at 11:39:50 AM, Steve Berczuk wrote:
> 
> > Hmm, Why isn't there a place in the process for a set of exhaustive
> > tests that use many resources to ensure that the application works
> > correctly? If you had such tests it is plausable that they may take a
> > long time. I agree that the tests that developers run to ensure that
> > the build works shoud be quick. But I think that you would want to run
> > more exhaustive tests. And run these asynchronously.
> 
> Use of "many resources" will not make the tests better.
> 
> Running them asynchronously is done because they take a long time.
> The fact that it takes a long time to know if you've done good work
> is the bug. Fix it.

I think the distinction is more clear if we exchange "know if" with
"be confident that"... and then ask how confident?

Running them asynchronously is done because they take a long time and
the additional confidence they provide is not enough to justify
waiting, though it is enough to justify running them.

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com
(Continue reading)

Permalink | Reply | 0 comments |

Gmane